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

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

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

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 有了上述质量防控体系,整个迭代将会变成如下流程:

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

下一篇文章将会和大家分享精准测试的技术实现方案。

欢迎关注个人技术网站:http://www.runtester.com

共收到 5 条回复 时间 点赞

请问 系统成熟度 这种要如何去衡量?

老哥 666,问一下这些都嵌入到 CI 流程了吗? 精准测试有调用链分析吗?

匿名 #3 · 2018年11月23日
hoohyou 回复

可以定一些指标:比如代码规范、自动化覆盖率、代码复杂度等,每个指标有个权重,综合起来计算分数。目前我们主要根据自动化覆盖率和代码规范计算的

匿名 #4 · 2018年11月23日
workhard 回复

现在有的部门都嵌入到了 CI 流程,有的部门没有。精准测试主要通过覆盖率来分析调用链的,前提是有强大的自动化。

仙人指路! 已关注!

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册