马丁福勒 关于微服务特色的描述

微服务的原始动机在于解决monolithic 系统的扩展性为题，由于monolith的系统有两个问题：

1. 对整个系统的一个小地方的改动，都要对整个系统从新build 和 deploy
2. 作scale的时候，扩充的是整个系统，而不是整个系统中最须要扩容的那个点。

微服务能够很好的解决上面的问题，并且不通的微服务还能够使用不一样的编程语言来实现。

1. 经过服务化的方式来实现组件化。这个是相比传统的 经过library的方式来作组件化来讲的。
2. 根据业务上提供的不通能力来组织这些micro service
3. 作产品而不是作项目。核心区别在于作项目的方式，作完了项目就交付给运维去运维，然而作产品意味着，开发要在产品的整个生命周期中承担一些运维职责。
4. 比SOA中ESB相比更智能更轻量的服务相互调用。所谓smart endpoints and dumb pipes，这些endpoint都是解耦的，完成一个业务调用串起这些micro service就像是linux系统中经过管道串起一系列命令。
5. 自治的管理。各思其政 的选择技术实现，不一样的service能够根据各自的须要选择不一样的技术栈来实现其业务逻辑。
6. 去中心化的数据管理 意味着不一样的微服务使用的不是同一个数据库，这样作的目的只要是为了实现各业务之间的松耦合，提现清晰的业务边界，对数据的更新只能经过其所属业务的service实现，而不用直接访问数据库。这样作的一个好处是能够容许各个业务使用本身喜欢的存储方式来完成存储，能够是用各类nosql的方案，单同时也使得数据一致性不能经过传统的事务方式来实现。在微服务架构中的折中方案一般是最终一致性。容忍暂时的不一致状况出现，经过补偿机制来达成最终一致性。

7. 自动化架构，各流程的自动化

8. 充分考虑故障的设计。相比monolith架构，微服务架构用service的方式替换library来实现了组件化。引入了更多的service后，与此同时也引入了更多可能发生的故障。这就要求微服务架构要创建充分的监控和响应机制来应对可能发生的故障。监控机制要包括系统级的和业务级的，同时还要配合logging来快速定位问题，从而加以解决。
9. 支持持续演进的设计。The key property of a component is the notion of independent replacement and upgradeability - which implies we look for points where we can imagine rewriting a component without affecting its collaborators.