微服务的原始动机在于解决monolithic 系统的扩展性为题，因为monolith的系统有两个问题：
- 对整个系统的一个小地方的改动，都要对整个系统重新build 和 deploy
- 做scale的时候，扩充的是整个系统，而不是整个系统中最需要扩容的那个点。
微服务可以很好的解决上面的问题，而且不通的微服务还可以使用不同的编程语言来实现。
- 通过服务化的方式来实现组件化。这个是相比传统的 通过library的方式来做组件化来说的。
- 根据业务上提供的不通能力来组织这些micro service
- 做产品而不是做项目。核心区别在于做项目的方式，做完了项目就交付给运维去运维，然而做产品意味着，开发要在产品的整个生命周期中承担一些运维职责。
- 比SOA中ESB相比更智能更轻量的服务相互调用。所谓smart endpoints and dumb pipes，这些endpoint都是解耦的，完成一个业务调用串起这些micro service就像是linux系统中通过管道串起一系列命令。
- 自治的管理。各思其政 的选择技术实现，不同的service可以根据各自的需要选择不同的技术栈来实现其业务逻辑。
- 去中心化的数据管理 意味着不同的微服务使用的不是同一个数据库，这样做的目的只要是为了实现各业务之间的松耦合，提现清晰的业务边界，对数据的更新只能通过其所属业务的service实现，而不用直接访问数据库。这样做的一个好处是可以允许各个业务使用自己喜欢的存储方式来完成存储，可以是用各种nosql的方案，单同时也使得数据一致性不能通过传统的事务方式来实现。在微服务架构中的折中方案通常是最终一致性。容忍暂时的不一致情况出现，通过补偿机制来达成最终一致性。
自动化架构，各流程的自动化
- 充分考虑故障的设计。相比monolith架构，微服务架构用service的方式替换library来实现了组件化。引入了更多的service后，与此同时也引入了更多可能发生的故障。这就要求微服务架构要建立充分的监控和响应机制来应对可能发生的故障。监控机制要包括系统级的和业务级的，同时还要配合logging来快速定位问题，从而加以解决。
- 支持持续演进的设计。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.
