华为云高级测试专家马海谈《云时代如何更高效测试微服务性能》
马海：大家好，我叫马海，来自于杭州华为研究所，我目前任职于华为云cloudBU，主要负责云性能测试服务CPTS的开发与测试工作。非常荣幸今天能够来到北京参加这次的云测峰会，也很高兴能和这么多同行一起共同探讨测试行业的前沿技术。
我今天分享的题目是“云测时代如何更高效的测试微服务的性能”，从题目当中看出有三个关键词，第一个是“云测时代”，第二个是“微服务”，第三个是“性能”，所以我今天要给大家带来的是微服务性能的云化解决方案。
我将从三个方面开展我的分享，首先我会系统的讲解一下微服务架构面临的挑战，接着我会分享一下华为云在微服务性能这块给出的解决方案设计，最后我会从测试角度来分享一下性能测试的实施策略。
首先我们来看一下微服务架构所面临的挑战，提到“云时代”我们不得不说当下很火的一个架构-微服务架构。各大互联网公司或者云服务提供商都倾向于采用微服务架构，我们来看下微服务架构给我们带来什么核心价值呢？我将其总结成“3S”特性，第一个S指safety，这主要是指服务高可靠性和容错性，服务的高可用性就可以保证你的服务能够对外提供7*24小时的持续服务质量。
第二个S指“Scale”，我总结为可扩展性；随着服务的功能越来越复杂，或者随着业务流量的爆发式增长，亦或是随着组织扩张以及业务扩张，我们的技术架构需要能够很快的进行扩容以满足流量的爆发式增长。
第三个S指Speed，这主要是强调服务的快速上线和独立发布能力，以及我们的服务如何快速的响应用户需求，同时，在我们的服务当中可以进行一些创新的尝试，允许在服务中使用多样性的技术，这是微服务架构给我们的核心价值。
以上分享了微服务架构的好处，我们再来看一下微服务架构带来的挑战。单服务流量激增情况下，我们的服务要能很快的进行扩容响应，其次，随着我们微服务架构的采用，原来我们的用户请求可能只需要访问一个系统，但是现在采用微服务架构后，我们的用户请求（比如说一个电商网站购买行为），可能需要调用不同服务的多个接口，这时候就使得整个服务调用链条变长，调用关系变得更复杂；再者，随着微服务架构的采用，我们的整个系统被拆成了很多的微服务，导致可能出错的一些故障点也相继增多，这样一些技术挑战给我们的性能测试带来哪些问题呢？这里大概列举了一下，比如说单服务上线变更怎么样评估对性能的影响？性能瓶颈在各个服务当中进行漂移，我们怎么做好我们的性能测试？应对突发流量需求我们服务要进行准确扩容，这个时候我们如何验证我们扩容的有效性？还有，我们每一个服务都会有很多服务实例承载在后面，当服务实例众多时候我们怎样采集信息以便于我们更快速的定位性能问题呢？这是微服务架构给我们带来的一些挑战。
接下来就引出华为云在微服务性能方面给出的方案设计；整个第二章就是讲华为云的微服务技术架构，主要有三张图，这块主要是为后面我们整个的性能测试方案做一个引导。首先我们整个的华为云微服务架构是基于Service Mesh技术实现的框架，这个Service mesh是一个开源技术，它的实现原理就是在TCP、IP加一层代理以进行服务请求的转发，通过服务请求的转发可以很好的获取服务与服务之间的调用关系，这是Service Mesh技术的大致介绍。
下面这张图是华为云微服务框架的技术架构图，首先最左边是我们微服务框架提供的管理面的功能，比如说提供服务注册、服务配置中心，可以进行一些参数的配置及修改。还有，我们的框架给用户提供一个很好的用户界面。中间这块的话指的是一个个微服务可以通过两个技术接入到我们的微服务框架里面来，一个是mesher无侵入式技术，另一个是通过JavaSDK or GoSDK 的方式接入微服务框架。这些服务的底层是承载在K8S容器、虚拟机、以及CCE容器化引擎等这样的一些底层资源上；然后我们的微服务在对外提供访问能力的时候，我们实际上是把我们每个服务的API注册到一个公共的API网关上去，这样我们每一个服务在对外提供服务能力的时候，外围看到的就是一个一个可访问的API。这个图最右边想表达意思是，我们整个微服务框架还支持对接第三方监控的平台，如zipkin、普罗米修斯、以及华为自研的APM监控平台等，从而实现对服务的监控和治理。这就是我们整个华为云微服务框架的介绍。
下面这张图跟上面想表达的意思差不多，这张图在讲我们整个微服务框架所提供的能力，比如服务注册中心、配置下发、服务监控，调用引擎等，我们的服务可以通过侵入式的SDK方式，或者是通过无侵入式的Mesner技术，直接接入到整个微服务框架中去。
以上讲了微服务这块的技术架构，重点是为了我们接下来的微服务的性能做引导；我们来看下在微服务架构下面，我们需要关注哪些性能瓶颈呢？首先第一点，因为我们引入了Mesner代理层，这一层肯定会带来性能损耗，我们自己评估出这个代理层会带来1ms左右的性能损耗；其次，我们采用微服务架构以后，我们需要关注每一个服务的单服务接口性能，这个是我们做性能测试的时候需要非常关注的点；还有，当我们每一个接口的性能调优完毕后，我们需要关注不同微服务之间的接口调用情况，我们称之为全链路调用性能，这块也是我们需要重点关注和测试的；与此同时，我们还要关注每一个服务的伸缩能力；这是我们整个性能测试过程中的一些瓶颈点和需要重点关注的地方。
接下来这张图想表达的意思是，在我们的云化时代，我们整个的性能测试如何从传统解决方案向云化解决方案过渡；在传统测试解决方案中我们需要安装环境、在每个节点安装监控工具，还需要收集数据，最后还需要使用一些分析工具进行数据分析；整个过程下来可能耗时数周或数月，而且使用起来也很不方便。我们过渡到云化解决方案后，看看是什么样的解决过程呢？我们实际上提供的是一个即来即用、用完即走的方案，是一个一站式、小时级的解决方案；使用云化解决方案，用户只需要做一些很简单配置（比如：请求的URL、参数等），不用去管底层环境的搭建，云化解决方案直接可提供百万级的并发模拟能力，同时能够提供数据分析汇总能力，通过这些即实现了应用性能瓶颈的探测；其次，我们的云化解决方案还提供了节点的资源分析和监控能力；还可以接入到调用链和监控系统，以实现我们的微服务与微服务之间的调用链分析和监控；我们可以看到整个云化解决方案提供的是测试场景与性能问题的自动关联，再加上智能辅助分析，这是整个云化解决方案的重点。
接下来我们看一下，一个微服务应用从开发到上线我们需要做哪些性能测试？其实总结一下可以认为，我们需要做一个三层的分层性能测试；首先我们需要对单服务的接口进行性能测试，可能会发现一些应用逻辑的问题，这时候有针对性的进行性能优化。当我们把单服务接口性能优化完以后，我们就需要结合用户场景进行全链路的场景性能测试，这时候可能会发现一些服务与服务之间的接口调用的问题，同样也会进行对应的性能优化；最后我们还需要关注服务的伸缩能力验证，从而确定我们每一个服务所支持的扩容模型。以上是一个服务在上线前需要做的性能测试，当一个服务上线后再进行持续迭代的过程中，我们需要做哪些性能测试呢？其实也是需要关注三点，首先是性能测试的基线化，在一些重要的迭代版本中，我们需要进行性能测试的持续集成，从而保证对我们微服务性能的持续看护；其次，在关键的大促场景，比如说针对电商网站的“双十一大促”场景，我们需要针对关键链路进行线上的性能测试；再次，我们还需要做好用户量的评估，从而对线上的资源需求做好充分的准备。所以这页PPT想展示的就是一个应用从上线前到上线后我们需要开展的性能测试活动。通过对服务性能的分层验证，从而掌握每一个服务的能力基线。
下面这张图就是我们整个性能测试服务平台的技术架构图，从这个图我们可以看到，我们的性能测试服务平台主要分为管理面和数据面，管理面很好的提供了用户管理、配额、测试工程管理、测试资源管理等一些跟用户使用相关的功能，在数据面主要是提供了一个测试执行机集群，当然这个执行机集群又分为执行管理机和执行压测引擎，执行管理机主要是用来进行测试任务的下发以及测试性能数据的收集和汇总；执行压测引擎这块主要功能就是实现报文的收发，通过执行引擎来对被测对象实现高并发的用户请求；这个图右边的意思是我们的被测服务可以通过Agent代理接入监控运维平台，从而实现调用链分析和节点资源监控，当然还有日志监控和报警管理等功能。图的上半部分想表达意思是，我们的性能测试平台的API接口可以通过API网关以接口的方式开放给用户，这样用户可以通过自己的Jenkins等持续集成工具调用性能测试平台的接口，对接平台上的性能测试用例，从而实现性能测试的持续集成。整个平台是构建在K8S、Docker等开源技术基础之上，这里我要感谢下上一个课题的分享者--金玲老师，他的课题里刚好把K8S技术和docker技术做了系统的介绍，我这部分的内容刚好可以继承她那部分的技术介绍，从而让我这个架构更容易理解。
接下来的两页内容，我想分享下我们整个性能测试平台的两个关键设计，第一个关键设计是：平台实现了模块化管理以及事务的灵活组合与使用。这里想表达意思是，我们可以把我们微服务的一个一个的API接口，在我们的平台上定义成一个一个的事务，甚至可以把多个API接口（也就是全链路的场景）定义成一个事务；最后我们在开展性能压测、定义性能测试模型的时候，我们可以对这些事务进行一些灵活的组合和复用，同时，针对每一个事务可以定义多个阶段，每个阶段可以定义要持续多长时间，持续多大的并发量；通过这些事务的组合，可以根据各自业务的需求来实现性能测试模型的定义；当然除了这些功能之外，工具平台还提供了DNS域名解析、录制器等一些比较友好的功能，通过域名解析的配置，可以实现线上、线下环境的快速切换，这是第一个关键设计。
第二个关键设计也很好理解，刚才说我们的执行机集群是构建在K8S及Docker技术之上实现的可扩展、高性能的执行机集群。其中可扩展是什么意思呢？我们可以灵活的根据我们用户请求的并发量来实现执行集群的扩展；如果说并发量比较小，我们就可以使用很少的执行机资源；当需要的并发量比较大，比如说我们现在要测百万级并发，我们就可以通过我们的平台灵活的扩容我们的执行机资源，从而达到百万级高并发的模拟。所以我们的第二个关键设计就是基于K8S集群和Docker技术之上实现的可扩展的性能测试执行机集群。
上面讲了微服务架构和微服务性能测试平台的技术架构图，接下来我将从测试的角度来讲解一下我们整个性能测试的一些实施策略。这里我得声明一下，我今天讲的性能测试的内容，大家其实可以看得到，其瞄准的是针对于服务端的性能测试；前几位老师们分享的自动化测试、脚本录制回放等内容，是针对app端的测试，我今天讲的内容主要是针对app应用所对应的后端服务的性能测试。
在开展一次性能测试的过程当中，首先我们得明确一些关键的度量指标，比如说响应时间、并发访问数、TPS、CPU占用率等，这些概念我相信做过性能测试的同学对这一块都比较熟悉。如果有些同学不是很熟悉可以回去百度搜索一下，对这些概念有一个基本的认知；在进行性能测试之前，我们需要定义好我们所要关注的一些性能指标，同时结合用户的使用预期，对这些度量指标给出一些评估标准，达到什么样的状态我们认为系统是优秀的，什么样的状态是不合格的；右边这张图是我们结合用户预期来制定的整个测试过程需要关注的性能指标。有了这些指标后，我们接下来就可以开展性能测试了，这张图想表达的意思是，我们的一次性能测试并不是一蹴而就、一下子就直接杀到线上去进行大规模的性能探底，而是说整个性能测试其实是一个循序渐进的过程；首先从一个小规模的性能验证开始，在进行小规模验证时候，我们的被测对象一般是针对微服务的单个实例进行开展，这时候我们会发现性能测试的问题会出现在服务本身的逻辑上，或是应用的配置出现了问题，这部分问题解决以后，我们就可以针对应用的多实例进行中规模的性能调优测试，这时候我们会发现性能的瓶颈会逐步向底层转移，比如说数据库的连接池不够，或者缓存链接有问题；当我们把这些性能瓶颈解决以后，我们的服务就可以扩展为集群式的多实例，同时数据库也会是多实例的，这时候我们就可以把性能测试模型对接到线上环境去进行大规模的性能测试，这个时候会发现，我们的性能瓶颈就会向更底层转移，比如说带宽、操作系统配置出了问题。这页PPT给我们表达的意思就是：性能测试是一个逐步提升的过程，这样才能更准确的度量出我们服务扩容的模型。
下面这页是讲测试报告的分析解读，这个测试报告也是我们的云化工具提供的一个很好的能力，怎么形容呢？可以理解为，我们的工具平台提供了一个实时报告的功能，这个实时报告会进行数据的分析和汇总；实时报告就像一个仪表盘，我们可以一边看着这个仪表盘，一边开展我们的性能测试，当我们从这个仪表盘上看出一些问题的时候，我们就可以实时的去调整我们的性能测试的措施，整个这张图就是想表达这么一个意思。我举一个简单的例子，当我们从实时报告中看到TP90响应时间比较短，也就是说90%的用户请求能够在很短时间内返回，但是TP99（99%的用户请求）时间就比较长了，这种情况下说明什么呢？说明我们的被测系统的性能已经快接近瓶颈了，这时候我们就可以通过我们的工具平台进一步施加压力，来看一看系统是否会出现一些非正常的响应，从而准确度量出我们整个系统的瓶颈，这就是这页PPT所想表达的意思。
作为一次比较完备的性能测试，我们不能测完就不管了，我们还会给出一些性能优化的手段，这里我就大致列举了一下我们常用性能优化的手段，例如，第一个是扩容：这个很好理解，比如说服务顶不住了，我赶紧扩容一把，以实现更多的用户请求可以被不同的服务实例分担，从而增加服务的响应能力；第二个手段是进行应用的逻辑优化；我们应用里面存在着不合理请求，比如说没有做数据库读写分离，这对于我们的数据库会造成很大的压力，这时候如果能对应用的内部逻辑进行优化，也是一个很好的优化手段。第三是设置合理超时时间：服务与服务之间的调用，如果设置的超时时间比较短，当我们用户量一起来之后，就会发现很多的请求会等在那里，这样就会占用我们系统资源，导致系统吞吐能力上不去，通过合理的优化响应时间，从而获得我们访问链路的一个性能提升。再者就是缓存的应用：应用缓存可以让更多请求从前端直接返回，而不是每一个请求都必须调用到后端数据库这一层，通过缓存的引入，可以减轻后端应用对数据库的访问压力。还有就是限流：限流就是拦截掉一部分用户请求，从而保证系统不崩溃。最后就是降级：降级是把非核心链路应用直接下线掉，或者把应用的非核心接口给关掉，从而保证我们核心链路上的应用的性能。
下面这张图想表达意思是，我们在面对一个复杂的网络时如何做性能测试呢？其实一个主要思路就是，我们可以拆分压力的入口点，从而进行一个分阶段的验证，什么意思呢？首先，我们可以从CDN入口进行压力测试，等这块我们测试OK了，认为没有问题了，我们就可以绕开CDN网元，把我们的性能测试用例对接ELB上，直接从ELB这个层面进行测试；等这里测试没有问题了，我们就可以把性能测试模型直接对接到业务层，甚至对接到某一个服务实例上去进行压力测试，从而分阶段的屏蔽掉每一个网元对性能测试的影响。这里引出来一个问题：对于业务层，也就是应用内部的性能瓶颈，我们该如何定位？我们怎么样去提高我们定位效率呢？这就引出了我们最后的内容，我们的服务可以通过一些方式对接到应用监控平台和运维平台，从而灵活展现我们应用的拓扑结果和调用链追踪以及资源的监控。从拓扑图上就可以看到我们这个应用有哪些微服务，每一个微服务有多少个实例，每一个实例当前的状态，每一个服务有多少用户请求，有多少请求是成功的多少是失败的，这就是整个的拓扑图。当我们看到一个请求失败后，我们可以通过调用链跟踪，下钻到我们应用日志当中，从而准确定位到具体是哪个请求，甚至是哪个方法出现的问题；以上就是我们华为云的微服务性能的整体解决方案。
我今天要讲解的内容就这些，简单回顾一下,我首先讲解了一下微服务架构的挑战，其次我讲解了一下我们华为云在微服务架构这块给出的性能方案设计，以及云化性能测试解决方案，最后从性能测试角度给出了一些性能测试的策略，这就是我要分享的内容，谢谢大家。
本文来自：2018中国首届云测试峰会，举办方：Testin 云测
Testin，让应用更有价值：www.testin.cn
关注公众号“Testin”，了解更多测试行业动态和测试知识。