大家好，我是 方圆。最近读完了《生产微服务》，它是蛮不错的一本小册子，其中列举的对微服务的评估清单可以说是大型互联网团队的血泪史了，这也让我明白了为什么当前工作的团队在日常工作中要对其中提到的内容严格遵守和践行。所以，本篇文章主要是对书中提到的 CheckList 进行记录，方便在日后维护微服务架构的系统时提供检查参考。
稳定性和可靠性
稳定性强调在开发、部署、更新技术或弃用旧服务时给整个生态系统带来的影响；可靠性强调微服务可以被其他服务和整个生态系统所信赖。
开发周期
- 是否有一个可以存放所有代码的中心代码仓库？
- 是否有代码检查、单元测试、集成测试和端到端的测试？
- 是否有代码评审流程和策略？
- 是否有自动化的测试、打包、构建和发布流程？
部署管道
- 微服务生态系统是否有一个标准化的部署管道？
- 部署管道里是否有预发环境？
- 预发环境对生产环境有怎样的访问权限？
- 部署管道里是否有灰度（金丝雀，先少量发一部分服务，验证通过后在全量发布）发布？
- 灰度阶段是否有足够的时间来捕捉所有的 Bug？
- 灰度阶段是否准确地模拟了生产环境的业务流量？
- 灰度阶段和生产环境的服务接口是一样的吗？
- 生产环境的部署是一步到位还是循序渐进的？
- 对于紧急情况，是否存在直接跳过预发和灰度阶段的情况？
服务依赖
- 微服务的依赖项都有哪些？
- 微服务的客户端都有哪些？
- 微服务如何缓解依赖失效所带来的影响？
- 对于每个依赖项，是否都有备份、替代服务、回退方案或防御性缓存？
路由和服务发现
- 微服务的健康检测可靠吗？
- 健康检查是否准确地反映微服务的健康状态？
- 健康检查是否运行在独立的通道上？
- 是否使用了回路断路器来防止不健康的微服务发出请求？
- 是否使用了回路断路器来防止生产环境的业务流量被发送到不健康的主机或服务上？
服务和接口下线
- 是否有下线微服务的相关流程？
- 是否有解除微服务接口的相关流程？
伸缩性和高性能
一个具备了伸缩性和高性能的微服务以效率作为驱动，它能高效地处理大量的并发任务和请求，并为未来任务和请求的增长做好准备。
增长规模
- 微服务的 QPS 或 TPS 增长规模是怎样的？
资源的有效利用
- 微服务是运行在专门的硬件上还是共享的硬件上？
- 是否使用了资源隔离技术？
资源感知
- 微服务的资源（CPU、内存等）需求是怎样的？
- 每个微服务实际能处理多少流量？
- 除了 CPU 和内存外，微服务还需要其他资源吗？
- 微服务的资源瓶颈在哪里？
- 微服务是否需要被横向或纵向扩展，或者两者兼顾？
资源规划
- 新硬件多久能够到位？
- 申请硬件的频率是怎样的？
- 是否根据优先级为微服务分配硬件？
- 资源规划是自动化还是手工操作的？
依赖项的伸缩
- 微服务的依赖项有哪些？
- 这些依赖项是否具备了伸缩性和高性能？
- 依赖项能否随着微服务进行伸缩？
- 依赖项的所有者是否做好随微服务进行伸缩的准备？
流量管理
- 是否很好地了解了微服务的流量模式？
- 是否根据流量模式来安排服务的变更？
- 流量模式的急剧变化是否被小心地处理了？
- 在服务失效以后，流量是否能够被恰当地重新路由到其他数据中心？
任务处理
- 微服务所使用的编程语言是否具备伸缩性和高性能？
- 微服务在处理请求或任务时是否存在伸缩性和性能方面的限制？
- 微服务团队的开发人员是否了解他们的服务是如何处理任务的，处理任务的效率是怎样的，以及当任务和请求数量增加时他们的服务将会如何应对？
可伸缩的数据存储
- 微服务是否可以可伸缩和高性能的方式处理数据？
- 微服务需要存储什么类型的数据？
- 微服务的数据需要怎样的结构？
- 每秒需要处理多少事务？
- 微服务需要更高的读写性能吗？
- 微服务是读密集型、写密集型还是两者兼顾？
- 微服务的数据库可以横向或纵向扩展吗？它是可复制或者可分区的吗？
书中提到如果只能通过把微服务部署到拥有更多 CPU 或者更大内存的服务器上来满足业务流量增长的需求，说明微服务正面临着伸缩瓶颈，遵循并发和分区原则对它们进行重构，让它们可以横向伸缩，而不是纵向伸缩。
但是在近几年的工作中，多数场景下选择的依然还是纵向伸缩。
- 微服务使用的是专门的还是共享的数据库？
- 微服务是如何存储和处理测试数据的？
容错和灾备
让生态系统中的每一个微服务都具备容错和灾备能力是减少灾难损失和避免整体系统可用性受到破坏的唯一途径。故障检测和挽救手册需要在微服务团队间进行 标准化 ，微服务需要训练有素地处理故障：处理服务中断和事故需要在整个工程团队内进行标准化。
避免故障点
- 是否存在单点故障？
- 是否存在多点故障？
- 故障点是否能够被移除，或者需要对它们进行缓解吗？
故障场景
- 是否所有可能的故障场景都已被识别出来？
- 有哪些横跨整个生态系统的常见故障？
- 硬件层有哪些故障会影响到这个微服务？
- 通信层和应用平台层有哪些故障会影响到这个微服务？
- 哪些依赖项故障会影响到这个微服务？
- 哪些内部故障会拖垮这个微服务？
弹性测试
- 这个微服务是否通过了适当的单元测试、集成测试和端到端的测试？
- 这个微服务是否经过了合格的压力测试？
压力测试梳理流量地图，压测时需要通知相关方，否则不可进行压测
- 是否通过混度测试对所有可能的故障场景进行了调试？
混沌测试包括了日常的断网演练
故障检测和修复
- 在组织里是否有标准化的事故处理流程？
- 这个微服务的故障是如何影响业务的？
- 是否对故障进行了清晰的分级？
- 是否有清晰的故障处理策略？
- 当事故发生时，事故处理是否高于了任何当前任何工作？
监控
关键性度量指标
- 这个微服务有哪些关键性的度量指标？
- 有哪些主机级别和基础设施级别的度量指标？
- 有哪些微服务级别的度量指标？
- 这些关键性度量指标都被监控起来了吗？
日志
- 这个微服务需要把哪些信息记录到日志里？
- 这个微服务是否记录了重要的请求消息？
- 日志是否准确反映了微服务在各个时间点的状态？
- 这个日志方案是否具有伸缩性和高性价比？
仪表盘
- 这个微服务是否有仪表盘？
- 仪表盘是否简单易懂？是否所有的关键性度量指标都展示在了仪表盘上？
- 是否能够从仪表盘上看出来这个微服务是否运行正常？
告警
- 是否每个度量指标都设有告警？
- 是否所有告警都设置了合适的阈值？
- 告警阈值设置是否恰当，以便在发生中断之前触发告警？告警是否具有可操作性？
- 运行手册里是否包含了用于诊断、缓解和解决问题的排查步骤？
轮班待命
- 是否有一个专门的轮班待命机制用于微服务的监控？
- 每次待命排班是否有至少两个开发人员参与
- 这个待命流程是否在整个工程组织内进行了标准化？
文档化
从前有一个自私无情的老太太。有一天，她遇到了一个乞丐，因为某些原因，她对乞丐起了怜悯之心。她想给这个乞丐一些东西，不过她只剩下一个洋葱了，于是她把洋葱给了乞丐。最后，老太太死了，因为她生前太刻薄，最终下了地狱。在经历了一番苦难之后，有个天使来救她，因为上帝想起了她生前对乞丐做出的那个善行，打算也对她仁慈一回。天使拿了一个洋葱来到老太太面前，老太太一把抓过洋葱。不过令她感到沮丧的是，她身边的鬼魂也想要她手中的洋葱。此刻，她的冷血本性显露出来，她挣扎着把他们推开，不让他们抢到洋葱。在保护洋葱的过程中，洋葱被撕成了碎片。最后，老太太和其他鬼魂又跌回了地狱。
这个故事与微服务文档化的本质非常契合：把洋葱贡献出来。一方面是关于微服务的信息，另一方面是组织对微服务的理解。
微服务文档
- 微服务的文档是否被击中放在一个公开的、人们容易访问到的地方？
- 文档是否方便搜索？
- 微服务发生重要变更时，文档是否也得到了相应的更新？
- 文档是否包含了微服务的描述？
- 文档是否包含了架构图？
- 文档是否包含了待命信息？
- 文档是否包含了重要信息的链接？
- 文档是否包含了微服务请求消息流、接口和依赖项的信息？
- 文档是否包含了运行手册？
- 文档是否包含了问答章节？
微服务理解
- 团队里的每个开发人员是否都能回答他们的微服务的生产就绪相关的问题？
- 微服务是否遵循了一系列原则和标准？
- 已有的微服务是否经常得到评审和审计？
- 是否每个微服务团队都举行架构评审？
- 是否有生产就绪的审计流程？
- 是否有生产就绪路线图用于把微服务带向生产就绪的状态？
- 生产就绪标准是否推动了组织的 OKR？
- 生产就绪流程是自动化的吗？
巨人的肩膀
- 《生产微服务》