1．自动化测试。
单元测试自动化：我们目前要求单元测试覆盖率大于 90%，通过 Jenkins 整合 Sonar。每次提交代码后自动运行单元测试，Sonar 会自动给出代码评分，如果测试覆盖率不够或代码不达标，则单元测试失败。
性能测试自动化、平台化：我们开发了自动化测试平台 DTesting，关键服务的每次变更都需要在平台上进行性能测试，并生成性能测试报告，对比历史的性能测试数据。
功能测试自动化、平台化：每个应用都有完整的功能测试用例和脚本，可自动化回归功能测试。
2．自动化部署。
我们引入了 Docker，以减少人为部署时的误操作。
10.9 日志处理
日志处理分为两部分：一部分是实时日志处理，另一部分是冷日志处理。所有的应用日志都需要写入 Kafka 和文件，Kafka 中所有的实时日志都会被 DLog 系统及时消费处理，但是实时日志的保留时间不长，一般保留一个月。写入文件的所有日志会被定时备份到 AWS S3 上永久保留，如果需要一个月前甚至更久以前的系统日志，则可以在 DLog 系统中选择需要的日志范围，DLog 会将符合条件的日志从 S3 上下载下来并重新建立日志索引。日志主要是为监控提供基础源数据，为定位问题提供依据，如图 10.10 所示。
10.10 调用链追踪
随着服务的粒度越来越小，系统的服务变得越来越多，不同的服务可能由不同的团队实现，一个服务的实现可能会依赖几个甚至十几个服务。对于出现问题后，如何快速准确地定位故障，如何追踪业务的处理顺序和结果，业内已经有了一些实践和解决方案，Google Dapper 是 Google 研发的分布式跟踪系统，Google 也为此发表论文阐述了分布式跟踪系统的理论基础，给分布式跟踪的实现提供了非常好的参考示范。对于 Java 编写的服务，我们采用 Zipkin 来做调用链跟踪，Zipkin 是 Google Dapper 系统的开源实现，采用 Scala 编写；
而对于 Go 语言实现的服务，我们目前还没有好的解决方案。一个好的调用链追踪系统能为定位和排查故障提供强有力的支持。对于微服务架构，调用链追踪是必备的基础设施。
10.11 服务健康状态
很多情况下，解决故障可能很快，难点在于发现故障和定位故障，这需要我们的系统有全方位的监控和报警能力。基于业务和技术对可用性的需求，我们开发了服务健康状态监控和报警系统，从业务层、服务层、硬件基础设施层分别进行监控和报警，如图 10.11 所示。
10.11.1 报警
报警系统定义所有报警种类、报警级别、处理流程，并提供报警接入机制，各个层次的监控都可以通过自定义报警引擎接入报警系统来触发报警。7 × 24 小时服务监控团队会根据各个报警的处理流程，依次联系最高优先级的处理人来处理故障，如果在规定时间内没有处理完毕，则系统会根据报警的种类和级别自动升级报警响应级别，提高处理优先级来保障重要的报警能得到及时处理。
10.11.2 监控
监控分为硬件基础设施层监控、服务层监控和业务层监控三大类。
硬件基础设施层监控，包括操作系统、内存、CPU、网络流量和状态、连接数等方面的监控。我们用 Zabbix 来做基础设施层的监控，通过 Zabbix 的 API 将数据整合进我们的监控系统 DMonitor。
服务层监控，包括基础组件监控、基础服务监控、常规服务监控和外部接口调用监控。其中，基础组件监控包括对 Etcd、AWS RDS、Redis、Docker、Kafka 等基础组件使用情况的监控；基础服务监控包括对配置中心服务、认证服务、安全存储服务、路由服务、API Gateway 等关键服务的监控；常规服务监控则是监控所有一般服务的状态；而外部接口调用监控是监控分析系统依赖的外部访问情况，包括访问量、错误信息、超时状况等，为快速定位问题提供依据。
业务层监控，是指从业务角度出发，收集和分析业务层的访问量，根据各个业务的历史数据和已知的影响因素预测现在和未来的业务情况，定义监控报警目标。比如，在最近半个小时内某个业务的请求量小于预期值，在最近 1 个小时内对某个客户的 API 调用次数超过预期值，在最近 3 个小时内某酒店的订单量显著下降，等等。由于业务层的监控比较多，因此我们把业务层的监控独立出了一个子系统。业务层监控报警的决策来源于历史数据和未来可能影响系统的因子，通过对历史中的海量数据进行汇总加工和分析，从各个维度给出报警的预期值。
服务层监控和业务层监控都离不开各个应用的支持，有些监控目标会对应用的实现有侵入性，比如需要写业务日志，各个应用根据监控的目标来设计和实现，为业务层监控提供必要的技术支持，因此从系统架构层面开始就需要考虑业务的可用性需求。有了服务健
康状态的监控和报警系统，再辅以调用链追踪系统和日志处理系统，发现和定位故障的时间就比较可控了，可以很快定位绝大部分故障的发生原因，为修复故障提供有力的保障。整个发现定位故障的层次如图 10.12 所示。
10.12 发布管理
最后我想说说发布管理。虽然它不属于基础设施，但是它太重要了，对服务的高可用影响很大。基础设施的工作都做到位了就万事大吉了吗？不，还差一口气——还需要确保最后一公里万无一失，那就是服务的发布管理。最后一公里主要从以下三点着手规划。
容量规划
通过测试报告评估应用的类型是 I/O 密集型、CPU 密集型还是混合型，根据应用的类型申请合理的硬件资源。单台节点最大处理能力是多少？线上有多少容量正在被使用？集群的最大处理能力是多少？这些在发布前都需要合理地评估和测试。
冗余规划
需要考虑异地多可用区部署，部署服务实例不小于 N+2，服务实例硬件配置相同，避免部署实例大小不一。为什么是 N+2 而不是 N+1 呢？这是为了防止在服务更新时挂掉一个服务节点（发布失败是高概率事件）。
发布控制
在线下进行充分测试，能在线下做的测试绝不放在线上做。就像上面所说的，发布失败是高概率事件，所以发布必须要支持回滚，必须拒绝一切没有回滚方案的更新。必须拒绝！
11.6 总结
在微服务架构下可以按功能和职责充分分解服务，解耦依赖，单个服务易于开发和维护，解锁了技术栈，实现了更短的开发迭代周期，促进敏捷开发和持续部署。但我们也要充分认识到微服务有着分布式架构固有特点带来的复杂性，大量服务之间的通信对应用的集成测试、稳定性、运维和监控提出了更高的要求，CAP 理论的约束对数据的一致性也带来了更大的挑战。微服务架构对基础设施的投入很大，简单应用采用单体架构更经济有效，大型复杂应用采用微服务架构才能体现投入的价值。
