前言

这是一本关于微服务架构设计方面的书，这是本人阅读的学习笔记。首先对一些符号做些说明：

（）为补充，一般是书本里的内容；
[]符号为笔者笔注；

---

1. 迈向单体地狱的漫长旅程

在书中，作者以Food to Go（下简称FTGO）业务分析单体应用程序的优缺点。

1.1 FTGO应用程序单体架构

FTGO单体

1.2 单体架构的好处

• 应用开发简单；
• 易对应用程序进行大规模修改；
• 测试相对简单直观；
• 部署简单明了；
• 横向扩展不费吹灰之力；

1.3 FTGO应用程序单体地狱

FTGO单体地狱

1.4 什么是单体地狱

• 过度复杂性会吓退开发者；
• 开发速度慢；
• 从代码提交到实际部署的周期很长，容易出问题；
• 难以扩展；
• 交付可靠的单体应用是一项挑战；
• 需要长期依赖某个可能已过时的技术栈；

2. 为什么本书与你有关

什么人适合阅读：软件开发人员、架构师、CTO或工程研发副总裁；或者所负责的应用程序超出单体架构所能支撑的范围。

2.1 阅读门槛

• 三层架构；
• Web应用程序设计；
• 使用面向对象设计来开发业务逻辑；
• 关系型数据库：SQL和ACID事务的概念；
• 使用消息代理和REST API进行进程间通信；
• 安全，包括身份验证和访问授权；
• Spring框架；

3. 你会在本书中学到什么

读完本书能理解与掌握的知识点与技术点。

3.1 需要重点关注的知识

• 微服务架构的基本特点，它的好处与弊端，以及在什么时候使用微服务架构；
• 分布式数据管理的架构模式；
• 针对微服务架构应用程序的有效测试策略；
• 微服务架构应用程序的部署方式；
• 把单体应用重构为微服务架构的策略；

3.2 其他技术

• 使用微服务的架构模式来设计应用程序的架构；
• 为服务开发业务逻辑；
• 使用Saga在进程间维护数据的一致性；
• 实现跨服务的数据查询；
• 更高效地测试服务架构应用程序；
• 开发生产环境就绪的应用程序，实现安全性、可配置性和可观测性；
• 把现有的单体应用重构为服务；

4. 拯救之道：微服务架构

主要介绍人微服务架构的一些定义与基本特性。

4.1 扩展应用程序的三个维度（扩展立方体）[微服务的定义]

扩展立方模型

• X轴扩展：在多个实例之间实现请求的负载均衡，[简单来说就是Ctrl CV]；
• Z轴扩展：根据请求的属性路由请求，（用于应用程序需要处理增加的事务和数据量时），[流量分区扩容]；
• Y轴扩展：根据功能把应用拆分为服务，（亦称为功能性分解），[一般先进行Y轴扩展，再采用X、Z轴扩展]；

4.2 微服务的基本特性

• 扩展立方体；
• 模块化，[指开发人员无法绕开服务的API访问内部组件]；
• 每个服务拥有自己的数据库；

4.3 FTGO的微服务架构

将Y轴分解应用于FTGO应用程序，将得到下图：

FTGO的微服务架构

可以看出该模型的特点有：

• 每个服务API清晰定义；
• 每个服务可以独立开发、测试、部署和扩展；
• 模块化；

4.4 微服务架构与SOA的异同

微服务架构与SOA的异同
相似点：

• 都是特定的风格架构；
• 都以一系列服务方式组织系统；

不同点：

• 完全不同的技术栈（微服务架构采用轻量级、开源技术以及哑管道通信）；
• 处理数据方式不同（微服务架构有自己的数据库）；
• 服务尺寸、规模不同（微服务架构中的服务相对较小）；

5. 微服务架构的好处与弊端

5.1 微服务架构的好处

• 使大型的复杂应用程序可以持续交付和持续部署，[支持自动化测试、独立部署、开发团队自主且松散耦合]；
• 每个服务都相对较小并容易维护；
• 服务可以独立部署；
• 服务可以独立扩展；
• 微服务架构可以实现团队的自治；
• 更容易实验和采纳新技术；
• 更好的容错性；

5.2 微服务架构的弊端

• 服务的拆分与定义是一项挑战；
• 分布式系统带来各种复杂性，使开发、测试和部署变得困难；
• 当部署跨越多个服务的功能时需要谨慎地协调更多开发团队；
• 开发者需要思考到底应该在应用的什么阶段使用微服务架构；

6. 微服务架构的模式语言

一个用来表述多种架构设计的选择方案，并且可用来改进决策的方式，就是使用模式语言。微服务架构的模式是微服务架构设计的重难点，也是后续章节的重难点。

6.1 一些概念（模式、模式语言等）

• 模式：针对特定上下文中发生的问题的可重用解决方案；
• 模式语言：解决特定领域内问题的相关模式的集合；
• 软件模式：通过定义一组互相协作的软件元素来解决软件架构或设计问题；

6.2 常用的模式结构包括三个重要部分

• 需求（Forces）：必须解决的问题；
• 结果上下文（Resulting context）：采用模式后可能带来的后果（包含好处、弊端、问题）；
• 相关模式（Related patterns）：5种不同类型的关系（前导、后续、替代、泛化、特化）；

以可视化方式表示模式间的关系

6.3 微服务架构模式语言

微服务架构模式语言的概括性视图
上图有四个模式组：

• 应用程序架构模式组：最左边，分为单体架构模式与微服务架构模式；
• 应用相关模式组：解决开发人员面对的具体技术和架构问题；
• 应用基础设施相关模式组：解决应用层面的基础设施相关问题；
• 基础设施相关模式组：解决通常在开发环节跟基础设施有关的问题；

6.4 微服务的主要几组模式【重点】

服务拆分相关模式：

【第2章重点介绍】将系统拆分本质上是一门艺术，但可以有一定策略，如下图所示：

服务拆分相关策略

通信相关模式：

【第3与第8章介绍】进程间通信（IPC）是分布式系统的重要组成部分，其包括：

• 通信风格：使用哪类进程间通信机制；
• 服务发现：客户端如何获取服务具体实例的IP地址；
• 可靠性：在服务不可用情况下，如何确保服务间的可靠通信；
• 事务性消息：如何将消息发送、事件发布这样的动作与更新的业务数据的数据库事务集成；
• 外部API：应用程序的客户端如何与服务进行通信；

实现事务管理的数据一致性相关模式：

【第4~6章介绍】使用Saga模式确保数据一致性，而不是两步式提交（2PC）方式。下图展示数据一致性相关模式：

数据一致性相关模式

在微服务架构中查询数据的相关模式：

【第7章介绍】可以使用API组合模式，逐一调用服务的API，然后将所有的返回聚合在一起，如下图所示：

查询数据的相关模式

服务部署相关模式：

【第12章介绍】往往需要一个高度自动化部署的基础设施，一个部署平台（可以是UI图形化界面、命令行等），如下图所示：

请部署微服务的几种模式

可观测性相关模式：

【第11章介绍】指弄清应用在运行时的一些行为，同时根据错误的请求或高延迟等故障进行诊断排错。以下模式可用来设计具备可观测性的服务：

• 健康检查API：可以返回服务健康状态的API；
• 日志聚合：把服务产生的日志写入一个集中式的日志服务器，这个服务器可以提供日志搜索，也可以根据日志情况触发报警；
• 分布式追踪：为每一个外部请求分配一个唯一的ID，用于在各个服务之间追踪外部请求；
• 异常跟踪：把程序异常发送到异常跟踪服务，这个服务会排除重复异常，给开发者发送报警并且跟踪每一个异常的解决；
• 应用指标：供维护使用的指标，如计数器等，导出到指标服务器；
• 审计日志：记录用户的行为；

实现服务自动化测试的相关模式：

【第9~10章介绍】需要注意测试不同服务是否协同工作。以下通过单独测试服务简化测试的模式：

• 消费者端驱动的契约测试：验证服务满足客户端所期望的功能；
• 消费端契约测试：验证服务的客户端可以正常与服务通信；
• 服务组件测试：在隔离的环境中测试服务；

解决基础设施和边界问题的相关模式：

【第11章介绍】每个服务都必须实现许多跟基础设施相关的功能，此外必须实现外部化配置模式。在开发新服务时可以使用微服务基底模式解决一些基础设施的相关问题。

安全相关模式：

【第11章介绍】在用户身份验证工作中常用访问令牌模式，用户信息传递后的服务可以验证令牌获取用户信息。

7. 微服务之上：流程和组织

架构不是唯一需要关注的领域，还必须思考流程与组织。

7.1 架构、流程与组织间的关系

请添加图片描述

8. 本章小结

• 单体架构模式将应用程序构建为单个可部署单元；
• 微服务架构模式将系统分解为一组可独立部署的服务，每个服务都有自己的数据库；
• 单体架构是简单应用的不错选择，微服务架构通常是大型复杂应用的更好选择；
• 微服务架构使小型自治团队能够并行工作，从而加快软件开发的速度；
• 微服务架构不是银弹：它存在包括复杂性在内的诸多弊端；
• 微服务架构模式语言是一组模式，可帮助你使用微服务架构构建应用程序。它可以帮助你决定是否使用微服务架构，如果你选择微服务架构，模式语言可以帮助你有效地应用它；
• 你需要的不仅仅是通过微服务架构来加速软件交付。成功的软件开发还需要DevOps和小而自治的团队；
• 不要忘记采纳微服务过程中的人性层面。你需要考虑员工的情绪才能成功转换到微服务架构。

---

最后