阿里微服务质量保障系列（一）：微服务知多少
年初买了一本集团巨佬联合出的书《阿里测试之道》，然后认真拜读了下，我相信看过的同学都会获益匪浅，此书分享了阿里在大促保障、移动App测试、大数据测试、AI系统测试、云计算测试、资损防控、物流类测试等领域的方法、技术和工具平台，让外界得以了解阿里在测试领域的一系列技术创新、经验和方法。但是说实话，个人感觉此书适合互联网行业的高级测试管理和技术人员阅读，对于奋斗在一线的大头兵而言，此书除了可以了解先进的测试思想外，其实可操性不太大。而奋斗在“一线”阿里的测试工程师是怎么保障微服务质量的呢？想必大家也同样感兴趣，这也是我做阿里微服务质量保障系列文章的原因。本来我是想以一篇文章概之，但一篇长篇大论的文章势必分不清重点，倒不如做成一个系列。
我会从微服务开始介绍，最后以阿里的测试基建收尾，整个系列分7篇文章，每篇文章重点如下：
- 微服务知多少
- 研发流程知多少
- 环境知多少
- 域内测试知多少
- 全链路测试知多少
- 支付系统质量保障知多少
- 测试基建知多少
本文主要介绍微服务，对比单体架构和微服务架构的特性，以及微服务架构的测试难点和测试策略。
如何理解微服务？
微服务体系结构是一种将大型应用程序分解为一组较小的服务的方法。 每个服务都在自己的进程中运行，并使用 HTTP/HTTPS、RPC 或 AMQP 等协议与其他进程进行通信。每个微服务在特定的上下文边界内实现特定的端到端域或业务功能，每个微服务都必须自主开发，并且可以独立部署。每个微服务应拥有其相关的域数据模型和域逻辑，并且可以基于不同的数据存储技术（SQL、NoSQL）和不同的编程语言。
当然概念比较抽象，我以自身的两份工作经历，让大家感受下微服务和单体架构的区别，这样有利于你理解后面的内容同时更加有代入感。
单体应用架构下的服务特性
17年第一份工作，当时测试的投顾平台就是一个单体应用，它是前后端分离的项目，前端是Vue框架实现，后端Spring+SpringMVC+MyBatis实现。当时的每天的工作内容就是集成打包、上传jar包到服务器，运行应用然后开始测试。由于开发没有沉淀单测用例，开发扩展新功能畏手畏脚，经常会牵一发动全身，完全靠测试保证质量。那段时间测试压力超级大，即便是很小的改动，也要重新重新打包部署，测试也要把端到端所有功能回归一遍，那段经历简直糟糕透了，大部分时间耗费在测试之外的事情上。
现在看起来，单体应用就像一个完整的人，身上的任何一个部位“手术”后，都要将人留院观察(回归)全部“功能”确认没问题后，医生方可建议出院。 如果微服务更像各种服务组装成的机器人。某个功能出现问题就根治某部位，再观察(回归)对应的部分功能是否OK即可，降低了测试成本。
微服务架构下的服务特性
可以用下图的股票交易系统架构为例：
其中order服务、fee服务、account transaction服务、market服务都是独立的服务，可以有自己的存储系统、特定的技术栈实现，而各个服务可以独立部署和开发。
可以看到微服务的几个关键特性。
- 微服务具有规模小、独立和松散耦合的特点。
- 每个微服务具有一个单独的代码库，可由小型开发团队进行管理。
- 微服务是独立部署的。 团队可以更新现有微服务，而无需重新生成和重新部署整个应用程序。
- 微服务负责将其数据或外部状态保存到各自的数据库中。与整体体系结构不同，微服务不共享数据库。
- 微服务使用定义完善的 API 相互通信。 每个服务的内部实现细节均对其他服务隐藏。
- 微服务无需共享相同的技术堆栈、库或框架。
微服务测试难点？
架构设计复杂度高
微服务将单体架构分解为粒度更细、更易管理的服务，但这意味着要引入更多的服务间依赖关系。
对于测试同学而言，你不能只像以前单体应用服务测试时那样只关注系统整体实现了什么，还需要关注系统架构设计、每个服务实现的功能、上下游调用关系和调用方式（同步调用、异步调用）等。
团队协作难度大
系统依赖性的增加会给团队协作带来更大的沟通成本。
康威定律想必大家都了解，
ommunication dictates design。
组织沟通方式决定系统设计。
这条定律重点是讲组织架构和沟通对系统设计的影响。组织的沟通和系统的设计之间紧密相连，特别是复杂系统，解决好人与人的沟通才能有一个更好的系统设计。
《人月神话》一书中总结出了随着人员的增加沟通成本呈指数增长的规律：沟通成本 = n(n-1)/2。
举例说明一下：
5人项目组，需要沟通成本是 5*(5–1)/2 = 10
15人项目组，需要沟通成本是15*(15–1)/2 = 105
50人项目组，需要沟通成本是50*(50–1)/2 = 1225
150人项目组，需要沟通成本是150*(150–1)/2 = 11175
此外不同团队，经常遇到同一个项目，开发频率不一致的情况，团队需要等待其他团队，以便完成相关微服务的并行开发；团队需要等待测试环境进行完整的搭建和配置后，方可实现整体联调、测试和验收。
测试成本高
微服务架构的复杂性使测试工作本身变得更加困难。测试挑战包括测试环境、测试方法。
1. 测试环境
这块后面的内容会详细介绍。因为微服务架构下，经常出现并行开发的情况，因此不同的开发同学拉自己的项目迭代，不同的迭代都有自己的联调环境。对于阿里而言，这边的环境总体上分为三大类：开发、测试、线上。其中开发环境又分为Dev环境、Stable环境；测试环境分为test环境、e2e环境。生产环境分为预发pre环境、灰度gray环境、生产环境。虽说这么多环境不用测试同学全部维护，但是不同环境因配置差异出现的问题也经常耗费测试同学额外的测试成本。
2. 测试方法
直接用单体应用架构下的测试方法来测试微服务并不可行。单体应用架构下，通常用端到端测试的方式对业务功能进行整体验证。而在微服务架构下，因为测试对象发生了变化，即从测试产品转变到测试实现产品功能的微服务，需要对测试对象进行重新分析，则需要调整新的测试策略和测试技术。
微服务测试策略？
单体架构下的金字塔测试策略显然不适用于微服务架构，微服务测试策略更像“钻石”。
- 单元测试 ：从服务中最小可测试单元视角验证代码行为符合预期，以便测试出方法、类级别的缺陷。
- 集成测试：验证当前服务内部模块之间的通信方式或者交互符合预期，以便测试出内部集成缺陷。
- 域内测试：验证微服务实现的功能以及与外部交互的异常场景(例如调用超时、服务异常、网络异常等)服务预期。
- 契约测试：验证当前服务与外部服务之间的交互，以表明它符合消费者服务所期望的契约。
- 全链路测试测试：也叫端到端测试。从用户视角验证整个系统的功能能否符合用户的预期。
- END -
关注 软件质量保障，与质量君一起学习成长、共同进步，做一个职场最贵Tester！