《微服务设计》 读书笔记

书籍介绍

书名：《微服务设计》＆《Building Microservices》
作者：Sam Newman

本书包含的内容非常全面，覆盖了微服务架构设计涉及到的几乎所有的知识点，所以内容不可能讲得很细致。作为微服务领域的入门书籍比较好，可以让我们对整个微服务生态先有一个整体全面的认识，然后后期我们可以逐项深入了解和学习。

什么是微服务

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

单一职责原则：把因相同原因而变化的东西聚合到一起，而把因不同原因而变化的东西分离开来。

服务应该多小：
1. 当你不再觉得你的代码库过大，可能它就足够小了；
2. 服务是否能够很好地与团队结构相匹配；
3. 不应该用代码行数来衡量

自治性：服务之间通过网络调用进行通信，加强服务间的隔离性，避免紧耦合。服务可以彼此间独立进行修改。

微服务架构是SOA的一种更细粒度的特定方法。

微服务好处

• 技术异构
• 弹性扩展
• 简化部署
• 可重用可组合
• 易修改
• 与团队结构匹配，高生产力团队（康威定律）

没有银弹

• 需要面对所有分布式系统需要面对的复杂性（事务，CAP等）
• 需要在部署，测试，监控等方面有所积累
• 需要考虑如何对系统进行弹性扩展
• 需要衡量组织结构是否适合

服务建模

DDD领域驱动设计

什么是好的服务：
- 松耦合
能够独立修改及部署单个服务而不需要修改系统的其他部分
- 高内聚
把相关的行为聚集在一起，把不相关的行为放在别处

服务间集成

最大程度保证微服务之间的低耦合：
- 避免数据库集成
- 理解REST和RPC之间的取舍，总是使用REST作为请求/响应模式的起点
- 相比编排，优先选择协同
- 避免破坏性修改，理解Postel法则，使用容错性读取器
- 将用户界面视为一个组合层

同步与异步通信：请求/响应或者基于事件
事件驱动架构和异步编程使得系统耦合性降低，伸缩性更好，但是会带来复杂性（消息的发布订阅，异步思维的转换，调试难度增加等），应谨慎选用。

REST VS RPC

通信机制	优势	不足
REST	1.HTTP 2.文本消息简单可读 3.低耦合	1.延迟较高 2.序列化性能较低
RPC	1.易于使用 2.高效的二进制消息格式：Thrift / Protocol Buffers 3.协议高效：TCP / UDP	1.技术耦合 2.脆弱性（api的增加删除涉及到消费端和服务端同时修改）

单体系统拆分

通过寻找服务边界来进行系统分解，且这是一个增量的过程。

最开始需要寻找接缝，减少分割服务的代价。

拆分系统包括服务的拆分和数据库的拆分。
数据库拆分之后可能会涉及到事务。

部署

讲持续集成与微服务映射起来，每个服务对应一个代码库，每个服务对应一条CI流水线。

如果可能的话将服务部署到单独的主机或者容器中。

自动化一切。

测试

测试范围：测试金字塔，《Scrum敏捷软件开发》(Mike Cohn)，《敏捷软件测试》(Lisa Crispin and Janet Gregory)

微服务测试分为功能性测试和非功能性测试。

功能性测试包括单元测试，API测试，契约测试，集成测试，端到端测试等。
非功能性测试包括性能测试，安全性测试，探索性测试等

功能性测试

单元测试：针对函数和方法调用，面向技术而非面向业务
API测试/服务测试：针对单服务的功能测试，需要对依赖的外部服务进行打桩，数据库可使用真实的数据库或者内存数据库。
契约测试：针对服务之间的调用进行测试，避免服务的接口变更会带来不兼容，破坏新服务的消费者，使用契约测试可替代部分集成测试
端到端测试：覆盖整个系统，加入用户场景的测试，运行较慢，定位失败更加困难

测试用例比例优秀实践，顺着测试金字塔向下，下一层的测试数量比上一层多一个数量级

测试用例应该有谁来写

单元测试通常由开发人员来写，服务测试和契约测试需要开发人员和测试人员充分沟通，都可以写，端到端测试通常由测试人员来写。因此需要开发人员和测试人员都拥有一些对方的能力。

部署后测试

区别部署和上线的不同

在进行微服务的自动化部署之后需要自动运行冒烟测试验证系统是否可用。

蓝/绿发布：部署两份软件，但是只有一个接受真正的请求。在新版本软件冒烟测试通过后进行生产流量切换。

金丝雀发布：通过将部分生产流量引流到新部署的系统，来验证系统是否按预期执行。与蓝/绿发布不同之处是，新旧版本共存时间更长，经常需要动态调整流量比例。

平均修复时间比平均故障间隔时间更重要

监控

针对服务

• 跟踪请求响应时间。做好之后，可以开始跟踪错误率和应用程序级指标
• 跟踪所有下游服务的健康状态，包括下游调用的响应时间及错误率。工具：Hystrix
• 标准化如何收集指标以及存储指标
• 以标准的格式将日志聚合到一个标准的位置
• 监控底层操作系统，这样就可以跟踪流氓进程和进行容量规划

针对系统

• 聚合CPU之类的主机层级的指标及应用程序级指标
• 确保选用的指标存储工具支持在系统和服务级做聚合，同时也支持查看单台主机的情况
• 确保指标存储工具支持维护足够长时间的数据
• 使用单个可查询工具来对日志进行聚合和存储
• 考虑标准化关联标识的使用
• 设置警报阈值和构造仪表盘
• 指标聚合统一化

康威定律

强调系统架构设计与团队组织结构相匹配

服务治理

拥抱故障，想办法尽快从故障中恢复

功能降级：当系统负载过高时需要将部分重要性较低的服务进行降级，暂时设置为不可用，优先保证核心服务能够正常使用

反脆弱组织：通过在系统中引入捣蛋猴(Chaos Monkey)，主动引入故障，模仿实战演练，增强系统的稳定性

给所有跨进程调用设置超时，并选择一个默认超时时间

使用熔断器，当对下游资源的请求发生一定数量的失败后，熔断，后面的请求快速失败。客户端也会不断重试检查下游服务是否恢复，如果恢复则重置熔断器。

舱壁（bulkhead），每个下游服务使用独立的连接池，以提供服务间的隔离机制

增加缓存机制降低服务端负载

CAP定理，根据应用场景选择CP还是AP

服务注册与发现

• Zookeeper：可应用于配置管理，服务间的数据同步，leader选举，消息队列和命名服务等场景
• Consul：支持配置管理和服务注册和发现，提供HTTP RESTful接口
• Eureka：仅支持服务注册与发现，由Nerflix开源，包含了各种客户端负载均衡策略，既提供了REST接口，也提供了Java客户端。

接口文档

• Swagger：Swagger Editor, Swagger UI, Swagger Codegen
• HAL：超文本应用程序语言，用来描述公开的超媒体控制的标准

微服务设计原则

• 围绕业务概念建模
• 接受自动化文化
• 隐藏内部实现细节
• 让一切去中心化
• 可独立部署
• 隔离失败拥抱故障
• 高度可观察