微服务架构深度解析与最佳实践 - 第六部分

七个关键问题的应对策略-续2

6.拆分过程的测试和部署如何处理



通过前面的分析，我们了解到测试、部署和运维，在微服务环境下会变得复杂。试想，原来只需要测试一个系统，现在要测试一堆系统，原来要发布一个应用，现在要发布一堆应用。原来线上排查问题，只需要从一个日志文件看日志信息，一个数据库找数据，现在都不知道去哪儿找数据，因为第一时间不知道业务处理在哪个环节出错了，需要先搞清楚一个跨多个系统的调用处理过程，在哪个环节出了错，如果是显式的错误，有日志还好点，要是没有报错，而是数据错了，那简直就是排查问题的噩梦。



特别是如果两个不同的服务系统，分别是两个小组维护，一有问题就可能会产生相互推诿扯皮，A 让 B 先去排查是不是 B 的问题，B 让 A 去排查是不是 A 的问题，出现两个和尚没水吃的尴尬境地。一个解决问题的办法就是，自动化，降低人为因素的影响，也消灭服务拆分带来的这种重复劳动的复杂性，提升测试、部署、运维效率。



1） 自动化测试



建立全功能覆盖的测试 case，并实现自动化，变更时全量自动回归。集成 Sonar 等工具，检查代码风格、单测覆盖率和成功率等，控制代码质量。我们一般要求核心业务代码，覆盖率 100%；重要业务代码，覆盖率 90%；一般的后端业务代码，覆盖率 80%；其他代码覆盖率 60%。遗留代码，维护时把本次修改设计到的代码，覆盖率提升到 60%。代码风格可以参考阿里巴巴或是 Google 的 Code Style 编码规范定制适合自己团队的标准。



2）自动化部署



借助与 Jenkins、Nexus、Ansible，Docker、K8S 等工具，实现多个应用的自动打包，编排，以及自动化部署，构建微服务项目的部署流水线。特别是基于 K8S，我们可以实现微服务的服务自愈和自动弹性伸缩，在服务失败后重新拉起，在负载高或者低时动态控制容器数量。



3）自动化运维



通过标准规范，配置管理工具，资源交付工具等手段的配合，逐步实现基础架构、应用、IT 服务和业务运营的自动化，实现日常运维处理和运维流程的自动化，降低风险、提高效率，促进组织能力和成熟度提升。

7.拆分后的运维和监控如何处理





监控与运维是生产环境运行系统的日常工作，就像是人体的免疫细胞一样，保障着整个系统的健康运行，业务的正常运转，下面我们从 5 个方面说明一些微服务下的健监控和运维工作要点。



1） 系统监控



系统监控是最基础的监控指标，是我们了解系统内部运行情况的直接手段。我们要对所有重要的状态进行度量和监控，全面实时的掌握系统健康状态。



2） 业务监控



业务监控意味着我们要从用户的角度看来待系统的监控指标，而不仅仅是技术角度，这样我们就能发现和分析业务指标的突然变化是什么原因造成的，跟系统本身有没有关系，有没有需要我们改进提升的地方，可以更好的支撑业务增长，影响和稳定业务指标。时常可能会出现，业务方说客户都在抱怨系统不稳定，卡了，延迟高了，但是我们从系统监控上看，系统的指标没有大的变化，那么一定是我们设定的监控指标不够，没有覆盖到业务的全流程。反过来，也说我们和业务方、和客户思考问题的角度有差异，为了更好的服务客户，我们需要调整自己的视角，从用户角度出发思考问题。



3） 容量规划



只了解系统的过去和现状是不够的，因为随时可能会有突发的流量袭来，导致系统被冲击，可能会超出系统处理能力导致延迟飙升，直至系统宕机崩溃。所以我们需要在平时做好容量规划，通过持续的压测，了解到系统的极限处理能力，针对瓶颈资源持续做优化，提升处理能力，做好容量预案，随时有激增流量的扩容方案，超出处理能力的限流和熔断、系统过载保护方案，保障系统的稳定运行。



4） 报警预警



做好了业务和系统指标监控，也做了容量规划，那么我们还需要通过这些指标和容量策略，在合适的时机对系统进行干预，把系统风险提前消灭掉。所以，我们需要根据经验定义预警报警的阈值，根据容量水位进行扩容缩容的后续处理动作。



特别报警预警的实时性，是我们应对线上突发异常的一个重要指标，例如对于 web 和 app 用户，如果我们在系统突发异常的 10 秒内收到预警，然后又花了 20 秒把系统重启，恢复了服务能力，那么用户可能会觉得刚才 30 秒是不是网络卡了一下，不会产生大规模的客诉。相反地，假如我们 2 分钟收到报警，又花了 10 分钟才处理完，这时候基本上大批客户都会感知到了这次故障，称为一个有大量客诉的事故了。



5） 故障处理



从我们的实际经验来看，导致系统出现非预期的不可用性故障，主要有三类原因：



• 人为的操作失误导致的宕机类不可用，没有标准的操作流程或者操作者没遵守流程；

• 遗漏的功能或性能相关的 bug 问题引起的不可用，我们的测试覆盖不足，或者对系统间的影响关系判断不准确，导致 Corner-Case 有遗漏；

• 不可预知的突发条件或状况引起故障的不可用，比如我们使用了 AWS，突然某个时间段 AWS 日本某个可用区的网络突然发生了大规模超时，某个 RDS 的底层硬盘突然损坏等；



这三类问题的应对策略是分别如下：



• 操作失误的应对策略：制定标准操作流程，并根据实际情况不断更新和调整，贯彻培训，严格执行，用流程来防止人为的不规范；

• 功能问题的应对策略：建立全功能覆盖的测试 case，并不断扩充 Corner-Case，逐步实现自动化，跟 CI/CD 集成，每次修改后都能及时的回归所有已知的 case，不留死角。完成系统和服务依赖关系分析，梳理和合理改造影响范围。建立可跟踪的性能测试基线标准和环境，每次重构或者设计调整，都通过基线环境进行性能验证，不把性能问题带到线上。

• 突发故障的应对策略：突发问题是我们真正面临的问题，一般来说不可控，超出预期，难以通过我们的努力直接解决。



故障处理的第一原则是，先解决问题，然后再去考虑分析原因，复盘过程，总结经验教训，最后才是考虑要不要追责。特别强调的是，如果一个线上的发布或者变更操作，有可能造成客户的感知事件，最好就先跟客户进行一个可以预期造成业务影响的沟通，给客户同步一下操作的时间，目的，持续时间，可能造成的影响，让客户可以从容的安排和调整自己的业务，保证不受影响或者降低损失（如果停机会给客户造成损失的话）。如果技术团队对这个操作没有十足的把握，最好考虑在一个可接受的时间窗口内停机处理。对于发布造成的故障，我们一直有个说法：



如果发布可能导致宕机这件事是提前告知了客户，那么真的发生了宕机就是一个故事。相反，如果可能导致宕机这事儿没有提前告知客户，那么操作过程导致宕机，就是一个事故。