许多组织尝试使用更细粒度的架构来实现更快的交付，发现其带来了更好的可扩展性，增强了团队的自治，或使团队更容易接受新技术。

第一章 微服务

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

内聚行：将相关的代码放在一起。

根据业务的边界来确定服务的边界。

Jon Eaves: 一个微服务应该可以在两周内完全重写？

足够小即可，不要太小。如果你不再感觉你的代码库过大，可能它就足够小了。

太大一个团队无法维护，太小微服务的管理成本上升。

专注做好一件事。

优点：

技术异构性：不同服务可以采用不同的技术，尝试新技术。

弹性：微服务能很好地处理服务不可用和功能降级问题。

扩展：可以只对需要扩展的服务进行扩展。

简化部署：各个服务的部署是独立的，更快的对特定部分的代码进行部署。快速迭代，降低风险。

与组织结构相匹配（康威定律）：服务架构与团队组织相匹配，小代码库上工作的小团队更高效。

可替代化优化：能轻易的重写服务，或者删除不再使用的服务。

可以认为微服务架构是SOA (Service-Oriented Architecture) 的一种特定方法。

带来的问题：

需要面对分布式系统的复杂性问题；

部署、测试、监控等；

分布式事务，CAP 相关的问题。

第二章 演化式架构师

架构师的重要职责是，确保团队有共同的技术愿景，以帮助我们向客户交付他们想要的系统。

我们的系统需要足够的灵活，有很好的适应性，并且能够根据用户的需求进行演化。

架构师必须放弃一开始就设计出完美产品的想法，而是设计出一个合理的框架，在这个框架下可以慢慢演化出正确的系统。

做系统设计方面的决定通常都是在做取舍。（很多事情都是这样的，没有绝对的好坏）

原则 VS 实践：有一些重要的原则来指导系统的演化，有一些细节来指导如何实现这些原则。

第三章 如何建模服务

如何确定服务之间的边界？

松耦合：能够独立修改及部署单个服务而不需要修改系统的其他部分。

高内聚：如果你要改变某个行为的话，最好能够只在一个地方进行修改，然后可以尽快地发布。

找到问题域的边界就可以确保相关的行为能放在同一个地方，并且他们会和其他边界以尽量松耦合的方式进行通信。

Eric Evans 领域驱动设计 (DDD) 一个重要概念：限界上下文(bounded context)。他认为一个给定的领域都包含多个限界上下文，每个限界上下文包含两部分：需要与外部通信，不需要与外部通信。通过接口决定它会暴露哪些模型给其他的上下文。

微服务应该清晰地与限界上下文保存一致，并且微服务可以很好地表示这些限界上下文。

对与一个新系统而言，可以先使用一段时间的单块系统，因为如果服务之间的边界搞错了，后面修复的代价会很大。所以最好能等到系统稳定下来之后，再确定哪些东西作为一个服务划分出去。

在思考组织内的限界上下文时，不应该从共享数据的角度来考虑，而应该从这些上下文能够提供的功能来考虑。

第四章 集成

避免破坏性修改

保证API 的技术无关性

服务易于消费房使用

隐藏内部实现细节

编排：依赖某个中心大脑来指导并驱动整个流程，同步中心化架构。

协同：告知事件系统各自处理，把具体怎么做的细节留给各个系统。异步分布式架构。需要监控。

第五章 分解单块系统

从接缝处可以抽取出相对独立的一部分代码，对这部分代码进行修改不会影响系统的其他部分。限界上下文是一个非常好的接缝。

增量式分解单块系统可以让你在进行的过程中学习微服务，同时可以限制出错所造成的影响。

跨系统跨数据库实例的事务

再试一次（最终一致性）：系统在未来某个时间达到一致。

终止整个操作（补偿事务）：

分布式事务：两阶段提交。首先投票阶段，每个参与者告诉事务管理器是否可以操作。如果都可以操作，者进行提交操作。否则回退。不是万无一失的，只是尝试捕获大部分的失败场景。

尽量避免分布式事务。如果实在不行，要避免仅仅从纯技术的角度考虑，而是显示的创建一个概念来表示这个事务。

服务一定会慢慢变大，直到大到需要拆分。我们希望的架构随着时间的推移增量地进行变化。

第十章 康威定律和系统设计

康威定律：任何组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。

“如果你有四个小组开发一个编译器，那你会得到一个四步编译器”。

两个披萨团队：如果两个披萨不够一个团队吃，那么这个团队就太大了。

微服务->团队
跨服务->跨团队
跨业务的服务->跨部门的服务

异地分布式团队的沟通成本比较高，因此协调变化的成本也比较高。

第十一章 规模化微服务

故障无处不在：规模化后故障将成为必然事件。

功能降级：理解每个故障的影响，并弄清楚如何恰当地降级功能。

设置超时

断路器

舱壁：从故障隔离的一种方式，失去了船的一部分，但是其他部分仍完好无损。比如为每个下游的连接使用不同的连接池。

隔离：

幂等：多次执行所产生的影响，与一次执行的影响相同。

CAP 定理：一致性、可用性、废弃容忍性最多保证两个。

Consistency 一致性：多个节点同样的值

Availablility 可用性：每个请求都能获得响应

Partition Tolerance 分区容忍性：部分节点失效，集群继续服务

如果系统没有P(分区容忍性)，就只是一个单体的应用。所以分布式系统不存在只有CA 的系统。

AP 系统扩展更容易，构建更简单；CP 系统由于支持分布式一致性会遇到更多的问题，需要更多的工作。