初识微服务第一次学习和接触SOA(面向服务的架构模式)，体会到软件工程的魅力所在，用此笔记记录自己的学习脚印。

小即是美：小的服务代码少，易测试，易维护，也更容易不断迭代完善的精致进而美妙。

单一职责：一个服务也只需要做好一件事

尽可能早地创建原型：尽可能的提供服务api，建立服务契约，达成服务间沟通的一致性约定，值与实现和完善可以慢慢再做

可移植性比效率更重要：服务间的轻量级交互协议在效率进而可移植性二者间，首要依然考虑可移植性比效率

可以理解为微服务是SOA的一种实践

围绕业务功能构建的，服务关注单一业务，服务间采用轻量级的通信机制，可以全自动独立部署，可以使用不同的编程语言和数据存储技术。微服务架构通过业务拆分实现服务组件化，通过组件组合快速开发系统，业务单一的服务组件又可以独立部署，使得整个系统变得清晰灵活

微服务是分布式系统，由此会带来固有的复杂性。开发者不得不使用RPC或者消息传递，来实现进程间通信；此外，必须要写代码来处理消息传递中速度过慢或者服务不可用等局部失效问题。

分区的数据库架构，同时更新多个业务主体的事务很普遍。这种事务对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同数据库，从而对开发者提出了更高的要求和挑战。

传统实现组件的方式是通过库（library），库是和应用一起运行在进程中，库的局部变化意味着整个应用的重新部署。通过服务来实现组件，意味着将应用拆散为一系列的服务运行在不同的进程中，那么单一服务的局部变化只需要重新部署对应的服务进程

基础设施自动化

无自动化不微服务，自动化包括测试和部署。单一进程的传统应用被拆分为一系列的多进程服务后，意味着开发、调试、测试、监控和部署的复杂度都会相应增大，必须要有合适的自动化基础设施来支持微服务架构模式、否则开发、运维成本将大大增加。

一旦采用了微服务架构模式，那么在服务需要变更时我们要特别小心，服务提供者的变更可能引发服务消费者的兼容性破坏，时刻谨记保持服务接口的兼容性。