1. 什么是微服务？

是一些协同工作的小而自治的服务。

2. 为什么会有微服务架构？

传统的单体应用架构在开发大型项目时的缺点是突出且严重的：

• 一个庞大的代码库，以至于时间久了想要知道该在什么地方修改都很困难
• 相似的功能代码随处可见，修复bug难上加难
• 严重的耦合性问题，代码牵一发而动全身，代码结构的修改（重构）成本极高
• 一个小的修改就得对整个应用重新部署上线，上线成本高使得上线周期长，难以同步快速变化的需求
• 心智负担

3. 微服务的特点

- 优点

• 根据业务特点拆分多个服务进行部署，服务之间的资源操作权限(DB-Table)相互隔离，通过网络通信，保持单个服务的自治性
• 单个服务，更小的代码量，能够快速开发/上线新功能以及定位bug
• 单个服务以单个应用形式运行，通过暴露API形式提供服务
• 更好的技术异构性。可以在不同的服务中使用最适合该服务的技术，如果系统中的一部分需要做性能提升，则可以使用更好的技术栈重构该部分。比如不同的部分使用不同存储技术。

- 缺点

• 需要管理较多的服务
• 引入分布式事务

4. 弹性

一个服务的故障不应该导致整个系统故障，微服务架构自然的引入了网络这个故障因子，需要使用合理的方法来处理异常。

5. 方便的扩展

微服务架构可以轻松的针对系统中存在性能瓶颈的服务进行扩展。

6. 方便的部署

微服务架构中的各个服务的部署都是独立的， 所以部署上线的粒度从整个系统降低到一个子服务，开发和测试的成本大大降低，可以做到快速部署上线，在出错时也能快速回滚该服务。

7. 与组织结构匹配

在一个庞大的代码库上开发，这会使得团队成员的职责权限变得模糊，开发效率低下；团队是分布式的时候，问题更明显。

微服务架构可以很好的将架构与组织结构相匹配，避免出现过大的代码库，团队成员的职责变得清晰，从而更容易获得理想的团队大小及生产力。

8. 方便的重写

当使用多个小规模服务时，重写某个服务或者是直接删除该服务都是相对可操作性的。

但是在单体应用中想要在一天内删除几百行代码，而确信不出问题，这恐怕不太可能？

微服务中的多个服务大小相似，所以重写或移除一个或多个服务的阻碍也很小。

9. SOA（面向服务的架构）

SOA是一种设计方法或设计思想。它所设计的架构是由多个服务构成，服务之间通过网络调用而通信，一个服务以独立形式存在。

SOA可以用来应对臃肿的单体应用，提高软件的可重用性。

书中说到，SOA是一个很好的想法，但人们做了很多实践都无法在这件事上达成共识。实施SOA时会遇到这些问题：通信协议如何选择，服务粒度如何确定等；目前也存在一些如何划分系统的指导原则，但作者说基本都是错误的。

微服务架构就是践行SOA的一种特定架构方案。

10. 共享库

通常单体应用中会存在命名如util或common的模块，用来存放常用的代码。微服务架构中也可以通过库的形式共享代码。

11. 没有银弹

作者强调：微服务不是免费的午餐，更不是银弹，选择微服务就得面对所有分布式系统需要面对的复杂性，这包含扩展、部署、测试、监控等待，还可能经常需要处理分布式事务或者与CAP相关的问题，不要过于感到惊讶！

每个公司、组织及系统都不一样，微服务是否适合你，或者说你能够在多大程度上选择微服务，取决于多种因素，书中后面章节会给出一些指导，指出常见的陷阱，帮你制定清晰的演化路线。

本书douban链接：点击这里