《微服务架构设计模式》读书笔记【END】

四季度选了《微服务架构设计模式》，但是状态不怎么样，一个月过去了，才看了个开头。博客也好久没更新了，正好有小伙伴想换工作要学习，又激励了我一下，一起学习！选这本是因为公司也正在使用微服务的架构，Spring Cloud，Eureka。平时都在用，但是原理不太懂，出现点不常见的异常（百度不到的那种），就很懵*了，不知道要怎么解决，全靠猜（竟然也解决了，离谱.....）

读后感

我是一个渣渣，好多地方都没太看懂，但是第一次了解了整个微服务体系。没基础的同学读起来会很痛苦（比如我），建议不必执着于每个细节，可以放过自己往后面读。后面会再看SpringCloud等微服务相关具体实现的书。具体了解后再回头看这本，应该会学到更多吧。

历时5个月，终于读完了这本，从20年四季度读到了21年一季度，坚持就是胜利，撒花～

第1章逃离单体地狱

1.1 迈向单体地狱的漫长旅程

1.1.1 FTGO应用程序的架构

1.1.2 单体架构的好处

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

1.1.3 什么是单体地狱

单体地狱

即单体架构的局限性在业务快速发展后不断显现，并且越来越难以维护

过度复杂
开发速度缓慢（协同工作问题）
代码提交到部署周期很长，且容易出现问题
难以扩展
交付可靠性是一个挑战
需要长期依赖某个可能已经过时的技术栈

1.2 为什么本书与你有关

1.3 你会在本书学到什么

1.4 拯救之道：微服务架构

1.4.1 扩展立方体和服务

微服务架构

架构的重要性在于影响了应用的“非功能性需求”，比如影响交付速度的可维护性、可扩展性、可测试性
扩展立方体和服务

微服务的定义

把应用程序功能性分解为一组服务的架构风格。每一个服务都是由一组专注的、内聚的功能职责组成。

1.4.2 微服务架构作为模块化的一种形式

一般的大型应用会拆分为模块，而微服务架构即使用服务作为模块化的单元，服务可以进行独立部署和扩展。

1.4.3 每个服务都拥有自己的数据库

1.4.4 FTGO的微服务架构

1.4.5 微服务与SOA的异同【没太看懂】

1.5 微服务架构的好处和弊端

1.5.1 微服务架构的好处

使大型复杂应用可以持续交付和部署
每个服务都相对较小并且容易维护
服务可以独立部署和扩展
微服务架构可以实现团队的自治
更容易实验和采纳新技术
更好的容错性

1.5.2 微服务架构的弊端

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

1.6 微服务架构的模式语言

架构设计的核心是决策

1.6.1 微服务架构并不是“银弹”

光环曲线使用5个阶段描述新兴技术的发展：过热期（期望释放的顶峰，代表了对新技术的迷恋和崇拜）-> 谷底期（失望的谷，尝试之后对新技术的失望）-> 成熟期（生产高地，理解了新技术的优缺点后开始理性地使用）【果然科学的尽头是哲学】

1.6.2 模式和模式语言

没太理解，但是不影响往后看🐶

1.6.3 微服务架构的模式语言概述

主要的模式：

服务拆分的相关模式
通信相关的模式：通信风格、服务发现、可靠性、事务性消息、外部API
实现事务管理的数据一致性相关模式
在微服务架构中查询数据的相关模式
服务部署的相关模式
可观测性的相关模式
- 健康检查API
- 日志聚合
- 分布式追踪
- 异常追踪
- 应用指标
- 审计日志
实现服务自动化测试的相关模式
解决基础设施和边界问题的相关模式
安全相关的模式

1.7 微服务之上：流程和组织

1.7.1 进行软件开发和交付的组织

1.7.2 进行软件开发和交付的流程

1.7.3 采用微服务架构时的人为因素

本章小结

第2章服务的拆分策略

2.1 微服务架构到底是什么

2.2.1 软件架构是什么，为什么它如此重要

2.1.2 什么是架构的风格

分层架构
六边形架构

2.1.3 微服务架构是一种架构风格

2.2 为应用程序定义微服务架构

2.2.1 识别系统操作

创建抽象领域模型

定义系统操作：命令型、查询型

2.2.2 根据业务能力进行服务拆分

业务能力定义了一个组织的工作

识别业务能力

从业务能力到服务

2.2.3 根据子域进行服务拆分

2.2.4 拆分的指导原则

SRP：单一职责原则

设计小的、内聚的、仅含有单一职责的服务

CCP：闭包原则

把根据同样原因进行变化的服务放在一个组件内，这样可以控制服务的数量，并且更有利于变更和部署。理想情况下，一次变更，只会影响一个团队、一个服务。CPP是解决分布式单体的法宝

2.2.5 拆分单体应用为服务的难点

网络延迟

同步进程间通信导致可用性降低

在服务之间维持数据一致性

获取一致的数据视图

上帝类阻碍了拆分

2.2.6 定义服务API

把系统操作分配给服务

确定支持服务协作所需要的API

本章小结

第3章微服务架构中的进程间通信

3.1 微服务架构中的进程间通信概述

3.1.1 交互方式

3.1.2 在微服务架构中定义API

3.1.3 API的演化

3.1.4 消息的格式

基于文本的消息格式

二进制消息格式

3.2 基于同步远程过程调用模式的通信（RPI）

3.2.1 使用REST

3.2.2 使用gRPC

3.2.3 使用断路器模式处理局部故障

开发可靠的远程过程调用代理

网络超时
限制客户端向服务器发出请求的数量
断路器模式：监控请求的失败和成功比例，超过一定阀值启动断路器，让后续的调用立即失效

从服务失效故障中恢复

3.2.4 使用服务发现

因为服务的网络位置（IP和端口）是动态变化的，所以我们需要使用服务发现

什么是服务发现

应用层服务发现模式

平台层服务发现模式

3.3 基于异步消息模式的通信

3.3.1 什么是消息传递

关于消息

关于消息通道

消息通道类型：

3.3.2 使用消息机制实现交互方式

消息机制一个有价值的特性是它足够灵活

实现异步请求/响应

实现单向通知
实现发布/订阅
实现发布/异步响应

3.3.3 为基于消息机制的服务API创建API规范

3.3.4 使用消息代理

无代理消息

基于代理的消息

使用消息代理实现消息通道

基于代理消息的好处和弊端

好处

弊端

3.3.5 处理并发和消息顺序

3.3.6 处理重复消息

编写幂等消息处理程序

跟踪消息并丢弃重复项

3.3.7 事务性消息

使用数据库表作为消息队列

通过轮询模式发布事件

使用事务日志拖尾模式发布事件

3.3.8 消息相关的类库和框架

3.4 使用异步消息提高可用性

3.4.1 同步消息会降低可用性

3.4.2 消除同步交互

使用异步交互方式

复制数据

先返回响应，再完成处理

本章小结

第4章使用Saga管理事务

4.1 微服务架构下的事务管理

4.1.1 微服务架构对分布式事务的需求

4.1.2 分布式事务的挑战

4.1.3 使用Saga模式维护数据一致性

示例Saga：Create Order Saga

Saga使用补偿事务来回滚所做出的改变

4.2 Saga的协调模式

4.2.1 协同式Saga

实现协同式的Create Order Saga

Saga参与方拒绝的场景

可靠的事件通信

协同式Saga的好处和弊端

好处

弊端

4.2.2 编排式Saga

实现编排式的Create Order Saga

把Saga编排器视为一个状态机

Saga编排和事务性消息

编排式Saga的好处和弊端

好处

弊端

4.3 解决隔离问题

4.3.1 缺乏隔离导致的问题

4.3.2 Saga模式下实现隔离的对策

Saga的结构

对策

语义锁

交换式更新【没太理解？】

悲观视图

重读值

版本文件

业务风险评级

4.4 Order Service 和 Create Order Saga 的设计

4.4.1 Order Service 类

4.2.2 Create Order Saga 的实现

Create Order Saga 编排器
CreateOrderSagaState类
KitchenServiceProxy类
Eventuate Tram Saga 框架

4.4.3 OrderCommandHandlers 类

4.4.4 OrderServiceConfiguration 类

本章小结

第5章微服务架构中的业务逻辑设计

企业应用程序的核心是业务逻辑，业务逻辑实现了业务规则。

5.1 业务逻辑组织模式

5.1.1 使用事务脚本模式设计业务逻辑

5.1.2 使用领域模型模式设计业务逻辑

5.1.3 关于领域驱动设计

5.2 使用聚合模式设计领域模型

5.2.1 模糊边界所带来的问题

5.2.2 聚合拥有明确的边界

聚合代表了一致的边界

识别聚合是关键

5.2.3 聚合的规则

只引用聚合根

聚合间的引用必须使用主键

在一个事务中，只能创建或更新一个聚合

5.2.4 聚合的颗粒度

5.2.5 使用聚合设计业务逻辑

5.3 发布领域事件

5.3.1 为什么需要发布变更事件

5.3.2 什么是领域事件

5.3.3 事件增强

5.3.4 识别领域事件

5.3.5 生成和发布领域事件

生成领域事件
如何可靠地发布领域事件

5.3.6 消费领域事件

5.4 Kitchen Service 的业务逻辑

Ticket聚合
KitchenService的领域服务

5.5 Order Service的业务逻辑

5.5.1 Order聚合

Order聚合的结构

Order 聚合状态机

Order聚合的方法

5.5.2 OrderService类

本章小结

第6章使用事件溯源开发业务逻辑

6.1 使用事件溯源开发业务逻辑概述

6.1.1 传统持久化技术的问题

对象关系的“阻抗失调”
缺乏聚合历史
实施审计功能将非常繁琐且容易出错
事件发布凌驾于业务逻辑之上

6.1.2 什么是事件溯源

事件溯源通过事件来持久化聚合

本章小结

第7章在微服务架构中实现查询

7.1 使用API组合模式进行查询

7.1.2 什么是API组合模式

7.1.4 API组合模式的设计缺陷

谁来担任API组合器的角色

7.1.5 API组合模式的好处和弊端

好处

简单直观

弊端

增加了额外的开销
带来了可用性降低的风险
缺乏事务数据一致性

7.2 使用CQRS模式

7.2.1 为什么要使用CQRS

7.2.2 什么是CQRS

7.3 设计CQRS视图

7.3.1 选择视图存储库

SQL还是NoSQL数据库

支持更新操作

7.3.2 设计数据访问模块

并发处理

幂等事件处理程序

7.3.3 添加和更新CQRS视图

7.4 实现基于AWS DynamoDB的CQRS视图

本章小结

第8章外部API模式

8.1 外部API的设计难题

8.1.1 FTGO移动客户端API的设计难题

多次客户端请求导致用户体验不佳
缺乏封装导致前端开发做出的代码修改影响后端
服务可能选用对客户端不友好的进程间通信机制

8.1.2 其他类型客户端API的设计难题

8.2 API Gateway模式

8.2.1 什么是API Gateway模式

请求路由

API组合
协议转换
API Gateway能够为每一个客户端提供它们专用的API
实现边缘功能

API Gateway的架构

API Gateway的所有者模式

使用后端前置模式

8.2.2 API Gateway模式的好处和弊端

8.2.3 以Netflix为例的API Gateway

8.2.4 API Gateway的设计难题

性能和可扩展性：同步IO or 异步IO
使用响应式编程抽象编写可维护的代码

处理局部故障：多实例 + 断路器
成为应用程序架构中的好公民

8.3 实现一个API Gateway

8.3.1 使用现成的API Gateway产品或服务

8.3.2 开发自己的API Gateway

Netflix Zuul
Spring Cloud Gateway

8.3.3 使用GraphQL实现API Gateway

本章小结

第9章微服务架构中的测试策略（上）

9.1 微服务架构中的测试策略概述

9.1.1 什么是测试

编写自动化测试

测试的不同类型

使用测试象限进行分类

使用测试金字塔指导测试工作

9.1.2 微服务架构中的测试挑战

消费者驱动的契约测试

针对消息传递API的消费者契约测试

9.1.3 部署流水线

9.2 为服务编写单元测试

9.2.1 为实体编写单元测试

9.2.2 为值对象编写单元测试

9.2.3 为Saga编写单元测试

9.2.4 为领域服务编写单元测试

9.2.5 为控制器编写单元测试

9.2.6 为事件和消息处理程序编写单元测试

本章小结

第10章微服务架构中的测试策略（下）

10.1 编写集成测试

10.1.1 针对持久化层的集成测试

10.1.2 针对基于REST的请求/响应式交互的集成测试

10.1.3 针对发布/订阅式交互的集成测试

10.1.4 针对异步请求/响应式交互的集成契约测试

10.2 编写组件测试

10.2.1 定义验收测试

10.2.2 使用Gherkin编写验收测试

10.2.3 设计组件测试

进程内组件测试
进程外组件测试

10.2.4 为FTGO的Order Service编写组件测试

10.3 端到端测试

10.3.1 设计端到端测试

10.3.2 编写端到端测试

10.3.3 运行端到端测试

本章小结

第11章开发面向生产环境的微服务应用

应用程序安全性
服务可配置性
可观测性

11.1 开发安全的服务

11.1.1 传统单体应用程序的安全性

11.1.2 在微服务架构中实现安全性

由API Gateway处理身份验证

处理访问授权
使用JWT传递用户身份和角色
在微服务架构中使用OAuth2.0

11.2 设计可配置的服务

11.2.1 使用基于推送的外部化配置

11.2.2 使用基于拉取的外部化配置

11.3 设计可观测的服务

11.3.1 使用健康检查API模式

实现健康检查接口

调用健康检查接口

11.3.2 使用日志聚合模式

服务如何生成日志

日志聚合的基础设施

11.3.3 使用分布式追踪模式

使用追踪工具类库

关于分布式追踪服务器

11.3.4 使用应用程序指标模式

收集服务层面的指标
把指标发送给指标服务

11.3.5 使用异常追踪模式

11.3.6 使用审计日志模式

向业务逻辑添加审计日志代码
使用面向切面编程
使用事件溯源

11.4 使用微服务基底模式开发服务

11.4.1 使用微服务基底

11.4.2 从微服务基底到服务网格

本章小结

第12章部署微服务应用

12.1 部署模式：编程语言特定的发布包格式

12.1.1 使用编程语言特定的发布包格式进行部署的好处

快速部署

高效的资源利用

12.1.2 使用编程语言特定的发布包格式进行部署的弊端

缺乏对技术栈的封装

无法约束服务实例消耗的资源

在同一台计算机上运行多个服务实例时缺少隔离

很难自动判定放置服务实例的位置

12.2 部署模式：将服务部署为虚拟机

12.2.1 将服务部署为虚拟机的好处

虚拟机镜像封装了技术栈

隔离的服务实例

使用成熟的云计算基础设施

12.2.2 将服务部署为虚拟机的弊端

资源利用效率较低

部署速度相对较慢

系统管理的额外开销

12.3 部署模式：将服务部署为容器

12.3.1 使用Docker部署服务

构建Docker镜像
把Docker镜像推送到镜像仓库
运行Docker容器

12.3.2 将服务部署为容器的好处

12.3.3 将服务部署为容器的弊端

12.4 使用Kubernetes部署FTGO应用程序

12.4.1 什么是Kubernetes

Kuberbetes的架构

Kubernetes的关键概念

12.4.2 在Kubernetes上部署Restaurant Service

创建一个Kubernetes服务

12.4.3 部署API Gateway

ClusterIP
NodePort
LoadBalancer

12.4.4 零停机部署

12.4.5 使用服务网格分隔部署与发布流程

Istio服务网格概述

使用Istio部署服务
创建到v1版本的路由规则
部署Consumer Service的v2版本
把测试流量路由到v2版本
把生产流量路由到v2版本

12.5 部署模式：Serverless部署

12.5.1 使用AWS Lambda进行Serverless部署

12.5.2 开发Lambda函数

12.5.3 调用Lambda函数

12.5.4 使用Lambda函数的好处

12.5.5 使用Lambda函数的弊端

12.6 使用AWS Lambda和AWS Gateway部署RESTful服务

12.6.1 AWS Lambda版本的Restaurant Service

12.6.2 把服务打包为ZIP文件

12.6.3 使用Serverless框架部署Lambda函数

本章小结

第13章微服务架构的重构策略

13.1 重构到微服务需要考虑的问题

13.1.1 为什么要重构单体应用

13.1.2 绞杀单体应用

尽早并且频繁地体现出价值

尽可能少对单体做出修改

部署基础设施：这对你来说还为时过早

13.2 将单体应用重构为微服务架构地若干策略

13.2.1 将新功能实现为服务

把新的服务与单体集成

何时把新功能实现为服务

13.2.2 隔离表现层与后端

13.2.3 提取业务能力到服务中

拆解领域模型
重构数据库
复制数据以避免更广泛的更改
确定提取何种服务以及何时提取

13.3 设计服务与单体的协作方式

13.3.1 设计集成胶水

设计集成胶水的API
选择交互方式和进程间通信机制
实现反腐层

单体如何发布和订阅领域事件

13.3.2 在服务和单体之间维持数据一致性

13.3.3 处理身份验证和访问授权

13.4 将新功能实现为服务：处理错误配送订单

13.4.1 Delayed Delivery Service的设计

13.4.2 Delayed Delivery Service设计集成胶水

13.5 从单体中提取送餐管理功能

13.5.1 现有的送餐管理功能

13.5.2 Delivery Service概览

13.5.3 设计Delivery Service的领域模型

13.5.4 Delivery Service集成胶水的设计

13.5.5 修改FTGO单体使其能够与Delivery Service交互

本章小结

王富贵儿。

关注

2
点赞
踩
7

收藏

觉得还不错? 一键收藏
1
评论
《微服务架构设计模式》读书笔记【END】

背景四季度选了《微服务架构设计模式》，但是状态不怎么样，一个月过去了，才看了个开头。博客也好久没更新了，正好有小伙伴想换工作要学习，又激励了我一下，一起学习！选这本是因为公司也正在使用微服务的架构，Spring Cloud，Eureka。平时都在用，但是原理完全不懂，出现点不常见的异常（百度不到的那种），就很懵*了，不知道要怎么解决，全靠猜（竟然也解决了，离谱.....）第1章逃离单体地狱第2章服务的拆分策略第3章微服务架构中的进程间通信第4章使用Saga管理事务第5章微服
复制链接

扫一扫