| 编辑推荐: |
本文来自于网络，文章主要介绍了微服务架构下解决自动化测试、开发联调、测试环境、持续集成方面遇到的问题及解决方案等。 |
|
1 从Monolithic到Microservices
在2008年时，市场软件形式大多为CS架构。当时存在的问题在于，开发耗时1-2年且内部的解耦度低；而优点在于对测试团队十分友好。
后来软件形式又经历了从SOA分布式架构到现在的微服务架构。
对于微服务架构来说，它并非像开发者们想象中的井井有条。下图是一个微服务架构化的典型示例，从绿色的线可以看出服务之间的关系错综复杂。
由于微服务架构把系统功能细分，团队会在各个方面都碰到了挑战。那么微服务架构下工程质量面对的问题，该如何解决？接下来我们将会从四个方面讲述。
2 问题的发现与解决
自动化测试
1.存在的问题
服务数量多，以HTTP和RPC接口为主：链路长依赖多。
服务交付周期变短：从以前的大模块开发，花费几个月时间交付。到现在的一到两周交付上线，但自动化测试开发速度跟不上交付的速度。
框架使用不规范，多种方式并存。
自动化测试代码的扩展性和可维护性不够
2.解决方案
通过提供相应的自动化测试框架工具，可以实现标准化、规范化、快速交付测试代码。具体操作如下。
统一的框架archetype自动生成整个项目框架。
数据、配置、代码分离进行数据的驱动。
单接口+场景化，确保做到无参数传递。
把一些常用的Lib库打包，在POM文件里面引用。
HTTP和Thrift接口封装，提高代码的复用率。
API-Lib
下图是自动化测试框架图示。
在数据校验时，自动化设计框架会自顶层生成测试项目结构，测试环境动态配置。
在测试数据，会由数据驱动来完成，只需要维护里面的数据即可，无需改变代码；
在Testcase层，引入了Json Schema、Json Path做数据校验；
把HTPP和Thrift做了相应的封装，方便调用；
最底层使用了Thrift，封装相应的Lib库。
自动化示例
如下图，左边是之前的Test代码，右边是通过统一测试框架自动生成后的代码。
分为data和内部环境数据，子文件里是单接口和多场景，在内可以复用API接口。
如何做到无参数
对于代码而言，多一个参数含义，整体复杂度和冗余度都会提升。
团队从框架引用，生成框架，到case的编写，生成Thrift写法；在数据维护上自动生成数据格式。做到了测试框架+测试代码+测试数据，实现了自动化。
自动化之后可以做到相应的专项代码测试，大量的数据变化和验证会在文件里直接做相应的要求。
开发联调
1.存在的问题
多个服务同时开发， 联调耗时日益增长：从内部看联调的占比大概在20%-50%之间。这种情况主要有两方面。一是，联调自测环境不稳定，服务多。另一方面是，多人开发，从一开始的简单接口约定到中间PM需求改变，导致接口互相之间数据格式上有变化，双方难做同步。
联调测试环境不稳定：需要找合作方调试，浪费时间。
自测时需要部署和维护多个依赖方服务。
2.解决方案
开发未动，Mock先行，随时联调。
在开发开始时，多方定义好相应的接口，接口文件，数据格式和规则。通过Mock工具生成服务，发布到联调测试环境中。
使用Moka工具自动生成Mock Server，指定相应的Thrift定义，根据相应规则，生成Mock
Server，在内配置联调服务，指向Mock Server，再配置相应的数据规则和匹配规则。
通过Moka能够做到开发刚开始时就可以提供相应的联调服务，流程基本如下。
一键生成独立Mock优于平台的点在于，适用性好。也支持Thrift的注解方式使用和Mock数据管理。
测试环境
1.存在的问题
由于服务数量增多，链路变长，调用依赖增多，整个环境的搭建会十分吃力。
多人共用一套环境，互相影响，容易影响测试结果。
稳定性差。
2.解决方案
解决的问题主要集中在，资源的申请，申请后的环境隔离与数据隔离，测试环境的维护，恢复测试环境等。
环境搭建可以从三个方面考虑，环境隔离、按需创建、描述依赖。
美团团队选择了通过HULK+泳道提供环境隔离，Cargo按需创建测试环境。骨干+泳道复制全新的环境，随后打通发布系统和代码仓库，发布大的测试环境，做稳定性与可控性的监控和三个9稳定性测试环境。
环境监控：
原则：泳道可以调骨干，骨干不可调泳道。
环境建好后，要保证随时可以使用。在稳定性监控下，只要提供服务，列表就可以进行监控，定时部署最新的分值代码。
整个环境都处于监控之中，每半个小时发送一次环境整体概况。如果某个服务稳定性降低，团队会直接@负责人查看原因。
持续集成
1.存在的问题
一次提测服务增多，提测了多个仓库，使得CI Job经历了爆炸性增长。
提测质量无法得到保证，测试不过关；缺乏前置测试，无效沟通太多。
2.解决方案
微服务环境中两个关键点：Merge到主分支前，提测前自动检测。
关键节点1：
代码提交和Merge到主分支，拉分支会自动创建CI Job，Push代码触发扫描，PR Merge到主分支触发扫描，PR更新触发再次扫描，通过允许Merge到主分支。
这样可以做到不把问题带到线上分支，并且前置的方式约束RD在上线前就解决问题。
关键节点2：
提测前还要再次自动检测。当需求提测的时候，根据提供的发布信息自动创建对应的Pipeline，点击提测之后会自动出发Pipeline的执行，自动部署，并做冒烟测试。Pipeline会明确的显示冒烟测试结果是什么，问题在哪里。
大大减少了无效的沟通。
工具链流程：
通过后台的CI服务，工具链从RD拉分支开始，拉分支会创建一个Pipeline Job，做Push代码的时候同时做Sonar扫描，由大象通知结果。
在工具链上共提供四个服务：
单测覆盖率CI服务。在Pom无侵入修改引入Jar包；一键接入单测覆盖率服务。
静态代码扫描CI服务，Sonar服务器进行线上监测。
自动部署，做冒烟测试。
内存扫描分析CI服务。Valgrind提供了Pipeline插件 开发，通过修改了插件，可以解决了许多相关的问题。在Pipeline上使用，可以一步分析，自动推送。
美团点评：打造微服务自动化测试与持续集成工具链实践
3 经验总结与反思
启示
理解用户需求的完整场景：源头，原因和原理。
坚持工具设计的主线和愿景，短期服从长期。
只有在用户需要时才出现。
从工具和服务做起，不要一开始就做平台。
跨团队合作，互补长短。
总结
我们在自动化测试方面，开发了规范化、标准化的LIPS自动化测试框架；开发联调方面，开发了Moka；Cargo来创建测试环境，做三个9的稳定性和可用性服务的测试环境；在持续集成方面，使用Pipeline，提供相应的CI服务且不做任何配置；PUSH代码会自动获取相应的信息，帮助大家做持续集成。
Q&A
Q：手工测试和自动化测试占比是怎么样的？
A：目前来讲，在工具应用之前，手工测试占比非常高，应该在60%以上，自动化测试应用的很不好，主要原因是整个标准化程度不够，维护起来很麻烦。根本的原因在于没有一个很好的框架工具支持它。
Q：Sonar扫描历史债怎么处理呢？
A：Sonar扫描每个团队都积累了很多关于怎样解决这个问题的经验。我们的解决方法一方面是依靠团队技术leader，有团队的支持，另外做好前置扫描，禁止有问题的代码上线。只有解决问题才可以上线。 |
