读《微服务设计》
August 10 2017

花了大概四、五个小时翻完了这本书，主要对微服务进行系统性的介绍，并且提供针对各种情况下实施微服务的指导性原则、方法来引导读者在现实系统中如何进行微服务的实践，个人认为这本书对想如何去实施微服务的一个很好的开端。

以下内容根据书中内容结合个人理解做的笔记。

微服务 vs SOA

说到微服务，不得不提到对「服务化设计」影响深远的 SOA，这也导致经常有说两者本质上没什么区别或微服务只是在 SOA 上包装的一个新名词，可见两者本身也是息息相关。

Wikipedia 对 SOA 解释提到的设计原则为：

服务封装、松耦合、服务抽象、可重用、可组合、自治、无状态、可被发现

该书中对微服务与 SOA 关系认为：

微服务架构是实现 SOA 的一种特定方法，如同 Scrum 是敏捷软件开发方法。

不难理解，微服务设计更是一种细粒度的 SOA 实现。而实施微服务不仅仅影响的是服务架构方式，而需要改变原有从系统设计、开发、打包、测试、部署/上线乃至期服务运维的整个环节。

服务边界

在系统中如何对服务进行拆分，个人认为是实现微服务的一大难点。书中强调依据领域（或业务）来划分服务边界以实现「松耦合、高内聚」的服务。而正好领域驱动设计的主要应用场景就是实现该目标，不过这一切的前提必须建立在对业务有深刻理解的基本之上。

领域驱动设计

DDD 在很早就被提起，一直被用来做为弥补传统分层设计的不足，强调将数据和行为封装在一起，将现实世界的业务与模型相映射。而随着微服务的兴起，这种设计方式重新被提起，被用来划分微服务的限界上下文（Bounded Context），主要目的划分出特定职责（即单一职责）的服务。

关于如何去做 DDD 进一步阅读：《领域驱动设计》。

CQRS

另外值的一提的是 CQRS，即将传统的 CURD Repository 层拆分为命令（Command，即改变对象操作） 和查询（Query）的行为。其主要目的大多数系统中通常都是读多写少，将两种行为进行分离之后便于单独维护（即开闭原则）、扩展和做针对性的优化（如读写分离）。如下图所示 DDD 和 CQRS 与微服务的关系：

基础设施

随着服务的拆分及业务发展至使服务增多，需要建立一套标准化、服务交付流程，以便支撑规模化后的微服务管理。因此，需要在发展微服务的同时来完善基础设施。

提供代码范例和服务模板

为了使开发人员关注点都放在业务本身上，而不必太过于关注服务如何产生和相关配置细节，最好提供相应服务范例或根据模板快速生成，开箱即用。这方面做的较好如 Spring Cloud。

集成技术选择

在对系统进行划分后，从原有的单体系统变成了由数个服务组合而成，每个服务作为独立的实体而存在，避免不了服务之间的依赖和相互通信，因此考虑的选择相应的通信方式。

对服务之间的通信模式主要分为请求/响应和异步消息方式。两者分别对应不同应用场景，且都有比较成熟的解决方案：

并且一些框架同时还提供了对应服务治理/安全/跨语言支持等多方面的功能，所以对于服务间的集成可以根据需要找到可靠的方案。

统一运行环境

运行环境通常分为本地开发、测试环境、预/线上环境等，同样应该使开发人员减少折腾环境的时间，需要能迅速出构建出不同的独立环境，避免环境的不一致性及互相影响。比如可以使用 vagrant，Docker 等，做到产出统一的构建产出和运行环境。

持续发布流水线

虽然与 CI/CD 相关的概念一直在老调重弹 ，个人认为重点的是如何做到拥有「持续」的能力 —— 能够快速的、不断的进行流水线式发布。在实际情况往往会因交付过程中自动化和标准化程度太低且需要过多的人工干预，导致难以做到持续和流程化。

大部分事情都应自动化

如上所述，要想达到「流水线式」生产，首先需要做的是先看从代码修改提交到部署到生产环境需要多长时间，然后将其中耗时环节通过某种方式（如自动化）进行缩减。另外，关于这点书中提到「除了提交代码之外的所有的事情都应具备自动化能力」，个人认为在一些情况中可能太过于「理想化」，但重点在于全员需备具这种意识并使之成为一个目标。

高度可观察

简单的说就是通过定义的监控指标，标准化收集和存储监控数据，并通过分析、聚合使数据达到可观察性的过程。关于这点在《SRE: Google运维解密》书提到一点「反馈真实的问题」，强调的是应从用户（或业务）角度出发度量服务，并从想要达到的目标反向推导出具体的指标。

相关方面可进一步阅读：《SRE: Google运维解密》

结语

个人理解微服务其最终目的是通过将复杂的事情如何进行有效的、合理的分而治之，以便将复杂的问题简单化。但同时因实施微服务会对团队组织结构、交付流程及基础设施条件等都有相应的要求，因此带来其它方面成本的增加，所以在实施前一定要根据业务、团队、基础条件等综合利弊来权衡是否需要微服务，正如大部分公司并不需要微服务这篇文章中所说，「毕竟一家公司的资源都是有限的，进了一个坑就意味着另一个坑可投入的资源少了。」

最后通过思维导图归纳了本书的大部分知识点，以便于快速了解微服务全貌。

microservices image