第一章：微服务
1.1 什么是微服务
微服务就是一些协同工作的小而自治的服务。它很小，专注做好一件事。服务越小，微服务架构的优点和缺点也就越明显。
微服务独立部署在 PAAS 上。服务之间通过网络调用进行通信。服务可以独立进行修改，而不引起服务消费方的变动。
主要好处：
- 不同的服务使用最适合该服务的技术。同时需要注意，避免技术栈过于分散。
- 弹性：系统中的一个组件不可用，不会导致级联故障，系统中的其它服务还可以正常运行。
- 扩展：可以针对单个微服务进行性能优化，扩容集群
- 简化部署：改动代码的影响范围小，可以快速高频部署
使用微服务，就需要面对所有分布式系统不可避免的复杂性。你需要在部署、测试和监控等方面做很多工作。
第二章：演化式架构师
架构师不需要从一开始就设计出完美的产品，而是提供一个合理的框架，在这个框架下慢慢演化出正确的系统。
适合开发人员在其上编程。
在系统级别进行健康监控。
保证每个服务都可以应对下游服务的错误。
在微服务架构中，存在多个自治的代码库，每个代码库都有自己独立的生命周期，这就给更多人提供了对单个服务负责的机会，当这些人在单个服务上得到足够锻炼后，可以给他们更多的责任，从而帮助他们逐步达成自己的职业目标。同时通过分担指责，也可以防止某个人负担过重。
第三章：如何建模服务
建模服务的原则，总结6个字松耦合，高内聚 。遵循这个6个字，让做的微服务能达到：
- 修改一个服务模块时不需要修改另一个（松耦合）
- 修改某一类功能时只修改一处就可以，相应的，只需发布一个服务（高内聚）
当思考服务的限界上下文时，不应从数据的角度考虑，而应该从能够提供的功能来考虑。
可以先用高内聚、低耦合的模块对服务建模，等待模块稳定后，将其拆分成独立的微服务。
第四章：集成
在讨论技术的技术细节前，需要考虑清楚微服务通信最重要的决定之一：同步 or 异步？
服务间的通信方式有多种：
- 同步：请求／响应模式，发起方阻塞等待整个操作完成。
- 异步：发起方不需要等待操作完成
- 基于请求／响应模式：注册回调，有异步非阻塞的优点
- 基于事件模式：完全异步，耦合度非常低，同时可以随意添加事件的订阅者。但是需要对业务流程做跨服务监控。
请求／响应模式的两种实现方式：RPC & REST。
4.1 基于请求／响应的同步方式
4.1.1 RPC
RPC(Remote Procedure Call) 远程过程调用，允许进行一个类本地调用，但事实上结果是由某个远程服务器提供的。RPC的实现种类繁多，如：SOAP、Thrift、protocol buffers、Java RMI、Dubbo等。
RPC 的核心思想是隐藏远程调用的复杂性，但有些时候隐藏的过头了。
RPC 会在一定程度上对性能有影响，包括网络通信时间、消息的封装和解封装
分布式计算中一个非常著名的错误观点就是“假设网络是可靠的”。
4.1.2 REST
REST 是对 RPC 的一种替换优化方案。大部分情况下，REST 是在 HTTP 底层协议的基础上构建的。
重要概念：
- 资源
- 对资源的操作（动作）
- JSON/XML 传递消息
基于 HTTP 的 REST 的缺点
- REST 无法像 RPC 那样生成客户端的桩代码
- 有些 Web 框架无法支持全部 HTTP 动词，如：PUT & DELETE
- REST 延迟相对会稍大
- 比二进制消息的尺寸要大
无论如何，REST 是比 RPC 更好的选择。
4.2 基于事件的异步方式
关键在于：发布事件机制 & 消费事件机制。
可使用的技术包括 RabbitMQ / Kafka 等消息队列中间件。这种系统通常有较好的可伸缩性和弹性，但会引入开发复杂度，同时还需要额外的监控。
4.3 other tips
尽量避免对某个服务做的修改导致该服务的消费方受到影响。
保证 API 的技术无关性。
使你的服务易于消费方使用。
隐藏内部实现细节。
在微服务内部不要违反 DRY(Don't repeat yourself) 原则，但在跨多个服务的情况下可以适当违反。
开发客户端库能简化对服务的使用难度，还能避免不同消费者之间存在重复的与服务交互的代码（DRY）。
客户端库可以处理类似服务发现、故障处理、日志等方面的工作，但一定要保证其中只包含处理底层协议的代码。
在发布一个破坏性修改时，可以使用扩展／收缩模式，首先，扩展服务能力，对新老接口都支持，然后等老的消费者升级了新的方式，再收缩 API 去掉旧的功能，平滑过渡破坏性修改。
短期内使用两个版本的服务是合理的，尤其是在做蓝绿部署／金丝雀发布时。
