持续集成如何搭建微服务架构的质量体系

匿名 · 2018年11月22日 · 最后由白纸回复于 2018年11月23日 · 4183 次阅读

本文主要谈如何构建微服务的质量体系。在这之前，大家先简单了解下几个问题：

1.为什么用微服务

单体应用就是将应用程序的所有功能都打包成一个独立的单元，最终以一个 WAR 包或 JAR 包存在，里面包含 DAO,Service、UI 等所有的逻辑。不幸的是，这种简单的单元有很大的局限性。应用程序随着业务需求的迭代，功能的追加扩展,最终成为一个庞然大物。

复杂性高：业务规模和团队规模发展的一定阶段，模块耦合严重，代码难以理解，质量变差
交付效率低：构建和部署耗时长，难以定位问题，开发效率低，全量部署耗时长、影响范围广、风险大，发布频次低
伸缩性 (scalable) 差：单体只能按整体横向扩展，无法分模块垂直扩展
可靠性差：一个 bug 有可能引起整个应用的崩溃
阻碍技术创新：受技术栈限制，团队成员使用同一框架和语言

2.什么是微服务

微服务架构:将单体应用拆分为多个高内聚低耦合的小型服务，每个小服务运行在独立进程，由不同的团队开发和维护，服务间采用轻量级通信机制，独立自动部署，可以采用不同的语言及存储。微服务的优点：

易于开发与维护：微服务相对小，易于理解
独立部署：一个微服务的修改不需要协调其它服务
伸缩性强：每个服务都可按硬件资源的需求进行独立扩容
与组织结构相匹配：微服务架构可以更好将架构和组织相匹配，每个团队独立负责某些服务，获得更高的生产力
技术异构性：使用最适合该服务的技术，降低尝试新技术的成本

微服务的介绍有很多，可以参考：https://zhuanlan.zhihu.com/p/32945365

3.微服务带来的质量挑战

系统依赖性增加：将单体应用转成微服务，虽然增加了缩放能力和灵活性，但是引入了更多的依赖，使系统整体变的更复杂，使测试环境的搭建配置以及校验指标更加难以掌控。
并行开发障碍：系统依赖性的增加还会给微服务的并行开发工作造成影响，需要等待其他微服务测试环境部署完毕，才能实现集成、测试。微服务数量越多，需要考虑的对象就越是广泛
影响传统测试方法：传统测试方法往往通过 UI 测试进行验证，而微服务的测试方案更加复杂。不仅需要验证各独立微服务，还需要检查整体业务的执行路径

4.质量体系如何搭建

4.1 下面是比较通用的微服务架构下质量保障体系图

基础质量平台

有一套完整的好用的自动化测试框架，支撑相关人员去写各种维度（单元、接口、端到端）的自动化测试
有好用的持续集成、回归能力
有代码的质量度量方法，比如根据代码的复杂度、自动化覆盖率、代码的规范等
任何要合并到主干的代码必须经过代码门禁检测，门禁的内容可以根据实际情况定义，比如：代码规范要符合要求、自动化通过率要符合要求，通过之后才允许合并
在业务负责，成功率不高的场景下，需要具备精准测试的能力，否则排查大量失败的用例，是一件极其痛苦的事情

线下质量

所有的测试用例能实现自动化的一定要自动化，这里我建议自动化的粒度要细：单元测试、接口测试（针对系统内部的接口测试，本地启动 spring 容器，偏系统功能测试，调用第三方系统可以选择 mock，测试代码需要集成在业务系统里）、端到端测试（根据自身业务情况，可以选择从业务的中部端到端，也可以从业务最顶部端到端，测试代码相对独立）
针对业务现状，约定好研发流程
有需要的业务可以进行专项测试
大部分的同学会发现，工作中的很多时间会花在咨询上，这里尽量将所有的咨询都工具化、一键化，无法工具化的就文档化，然后通过机器人（大部门的通讯工具都支持，比如钉钉）的方式对外提供服务

线上质量

相信大部门公司应该都具备灰度、蓝绿的发布过程
线上平台功能的问题一定是技术人员第一时间发现，如果不是，请反思。这里的线上监控可以分为两类，一类是线上自动化用例监控，一类是摘要日志的监控
资金类的业务数据核对非常重要，尽量做到实时、T+M、T+H 核对
大数据测试，将线上的流量存储下来，在线下、线上回放，这里需要注意隐私数据的脱敏保护

4.2 下面是自动化测试框架设计图

核心思路：一切组件化，依靠模板串联组件，测试同学只需要关心测试场景和测试数据，不用关心代码实现，配合可视化的 idea 插件，可以快速高效的编写自动化用例

4.3 有了上述质量防控体系，整个迭代将会变成如下流程：

这里需要强调，针对目前互联网行业既要快速迭代，又要保障质量，那么一定要有强大的快速的自动化回归体系，否则上面的流程肯定无法实施。很多人会发现业务背景比较复杂的情况下，自动化耗时久，成功率低，不仅没有帮助测试人员提高效率，反而成了负担。针对这种情况，建议重接口自动化，轻端到端自动化，同时做好精准测试。