一种完全无侵入式生产线上的全链路压力测试技术_陈皓.pdf

2023 年 6 月 10 日第 7 卷 第 11 期现代信息科技Modern Information TechnologyJun.2023 Vol.7 No.1169692023.062023.06收稿日期：2023-04-23一种完全无侵入式生产线上的全链路压力测试技术陈皓，张博民（北京重载智子科技有限公司，北京 100025）摘 要：随着硬件性能的提升、网络带宽的增加和数据量的急剧增长，传统的单机应用已无法满足现代企业的需求，取而代之的是基于分布式的软件系统。这些软件系统在提供强大计算能力的同时，也引入了复杂性。文章介绍一种新型的基于云原生架构的生产线上全链路压力测试方法Shadow Service，通过实现业务一致性、数据一致性、资源一致性和各种隔离性，保证了测试结果的准确性和生产系统的安全性。同时，详细介绍了如何在一个简化后的订单支付场景中使用 Shadow Service 实现压力测试。关键词：生产环境；压力测试；影子服务；服务网格；云原生中图分类号：TP311.5 文献标识码：A 文章编号：2096-4706（2023）11-0069-04An End-to-End Pressure Testing Technology for a Completely Invasive Production LineCHEN Hao,ZHANG Bomin(MegaEase Inc.,Beijing 100025,China)Abstract:With the improvement of hardware performance,the big increment in network bandwidth,and the rapid growth of data volume,traditional stand-alone applications can no longer meet the needs of modern enterprises.Instead,distributed-based software systems have emerged.These software systems provide powerful computing capabilities while introducing complexity.This paper introduces a novel cloud-native architecture-based end-to-end pressure testing method for production linesShadow Service.By ensuring business consistency,data consistency,resource consistency,and various isolation levels,the accuracy of test results and the security of production systems are guaranteed.At the same time,it details how to use Shadow Service to achieve pressure testing in a simplified order payment scenario.Keywords:production environment;pressure testing;shadow service;service grid;cloud native0 引 言在网络时代，一个大型的互联网应用需要承受数以亿计的访问量，这需要我们对应用中所有的服务进行全面完整的全链路压力测试，但这面临着巨大的挑战，传统测试方法不仅成本高昂且无法保证准确性，还需要巨大的工作量并存在破坏生产系统的风险。为了应对这些问题，MegaEase 提出了 Shadow Service 技术，基于云原生的流量调度和 Service Mesh 技术，实现了业务一致、数据一致、资源一致以及业务隔离、数据隔离、流量隔离和资源隔离。这种方法不需要修改任何代码，成本低，能够保证业务逻辑与生产环境的一致性，同时可以使用生产数据进行测试，保证测试结果的准确性，且安全可靠。因此，Shadow Service 成为网络时代全站压力测试的理想选择。1 背景介绍随着硬件性能越来越强，带宽越来越高，数据越来越多，传统的单机应用已经无法满足用户需求，取而代之的是由各种组件基于网络而构成的软件系统。但这种软件系统，在带来更强大的计算能力的同时，也DOI:10.19850/ki.2096-4706.2023.11.016引入了单机时代所不具有的复杂性。今天，一个完整的软件系统，模块数量少则几十，多则成千上万。并且，为了提高开发上线速度，这些模块会由不同的团队使用不同的语言开发，这也让模块间的通信变得更加复杂。同时，今天的业务模式相比过去也发生了很大的变化，类似双十一的促销活动，会让系统承受数倍、数十倍于日常的压力。所以，压力测试变得日益重要，但传统的测试方法也变得越来越无法适应业务需求。2 问题和难点2.1 专用测试环境的问题在单机时代，使用“1:1”的测试环境，是非常好的压力测试方法。但到了网络时代，这种做法却可能非常不切实际。1）成本问题。要测试单机软件，即使是独立开发者，绝大多数情况下也可以轻松地购买一台独立的测试用计算机；但今天的系统所需的资源太多了，要想 1:1 的按照生产系统搭建一套测试系统，单是服务器成本就会高的让大多数公司难以承受，更不用说还可能有带宽、电力、机房等费用。2）环境问题。即使我们在成本上没有问题，但是真的“1:1”建起测试环境，保持这个测试环境与生产环境的软件、70702023.062023.06第 11期现代信息科技数据完全一致也充满挑战。在实际工作中，测试环境与生产环境的差异会随着时间的推移越来越大，最终导致测试结果失真。3）数据问题。我们还会面对测试数据的问题，如果不能保证测试环境的数据与生产环境接近甚至相同，测试结果就不可信。比如一个类似微博的系统，像作者这种普通用户一般只有几十或几百人关注，所以我发一条消息，随便怎么做都可以很容易地通知所有关注者。但对一个千万大 V，情况就会截然不同。所以，我们不能简单地使用模拟数据进行测试。4）安全问题。为了让测试结果真实可靠，最好能够把完整的生产数据导入到测试环境。乍看上去，这只需要简单地备份恢复下数据库，但生产环境包含大量敏感数据，随意复制到测试环境无疑会极大地增加数据泄露的风险。2.2 在生产环境进行测试的问题因为使用测试环境进行压测存在诸多困难，人们就把目光转向了生产环境，尝试直接利用生产环境上的压力低谷时段，比如凌晨，进行测试。但这是一种侵入式的解决方案，涉及修改甚至重新定义业务逻辑，所以同样面临巨大挑战。假设我们要修改的是一个网购系统，那么用户购物下订单的流程应该会涉及用户、订单、支付等一系列的模块。1）如果我们要修改用户模块，那么我们需要用代码判断过来的请求是应该走测试逻辑还是生产逻辑。比较常见的方法是预先指定一个用户 ID 的范围，如果是这个范围的用户，就走测试逻辑，否则走生产逻辑。2）用户模块之后，逻辑走到了订单模块，这时，我们可能仍然希望通过用户 ID 来判断是否应该走测试逻辑，但实际情况却可能是：经过一系列的复杂处理流程，订单模块根本看不到用户信息，所以此路不通。3）为了让订单模块能区分出正常订单和测试订单，就必须在用户模块增加一些处理逻辑，比如给订单号加上特殊标记等。但是，在一个复杂的系统里，用户模块并不容易知道后续流程要经过的所有模块，所以，为了不影响正常的生产逻辑，仅仅保证测试状态的正常传递就需要付出不小的努力，更不用说还要考虑是否要访问不同的数据集，是否要模拟第三方服务等各种情况。很明显，这种业务逻辑的修改，所需的工作量与功能点数量成正比。但除了巨大的工作量，更严重的问题是，在辛苦的修改之后，有谁能保证所有需要做的修改都改了，并且改对了？而万一有遗漏或错误，就有可能破坏生产系统，这个风险实在是太大了，我们很难承受。3 解决之道3.1 一致性和隔离性从前面的分析可以看出，传统的测试方法或者成本高昂且得不到准确的数据，或者工作量巨大且存在破坏生产系统的风险。因此，MegaEase 认为，要解决网络时代的全站压力测试问题，必须使用一种全新的方法，而这种方法的关键在于“三一致”和“四隔离”。“三一致”是指业务一致、数据一致和资源一致。也就是说，测试系统和生产系统应该完全相同，只有这样，才能得到准确的测试数据。现实地说，100%的一致并不容易做到，比如，我们通常无法要求第三方配合我们进行测试，所以，只能使用模拟的方法替换掉部分第三方依赖。但我们仍然需要尽最大可能保证两个系统的一致性。“四隔离”是指业务隔离、数据隔离、流量隔离和资源隔离。这些隔离，都是为了将生产系统和测试系统完全分开，避免它们相互影响。很显然，三一致解决的是测试结果的准确性问题，而四隔离则保证了测试过程不会影响生产系统。基于上面的定义，我们可以使用一种叫 Shadow Service的技术，其主要利用云原生中的 SideCar 和 Service Mesh 技术。通过 Shadow Service，我们可以非常容易地为系统中的所有的应用服务创建一个影子（Shadow）副本，除了带有Shadow 标记之外，这些影子副本与原始服务完全相同，从而保证了业务一致和业务隔离。同时，Shadow Service 还会自动创建一条流量分配规则，将带有特殊标记的流量，比如，我们在用于测试的请求协议头中加上一个标志 Request-Header:Test，通过 Shadow Service 的 Mesh Ingress 组件，将此请求作为测试请求转发到服务副本，将其他没有该标识的请求发送给原始服务，以实现流量隔离。在数据方面，Shadow Service 可以根据配置替换掉包括MySQL、Kafka、Redis 等在内的多种中间件的连接信息，并借此改变数据请求的发送目标，这保证了数据隔离。而用户则可以直接将生产数据复制一份作为测试数据来保证数据一致。资源一致和资源隔离是指测试系统要使用与生产系统规格相同的资源，但不应该共享同一套资源。这主要是一个硬件问题，但Kubernetes已经在软件层面给出了非常好的答案，而 Shadow Service 是建立在 Kubernetes 之上，所以，通过将服务副本部署到新的 Pod 中，资源一致和资源隔离就都得到了保证。3.2 Shadow Service 工作方式下面我们以一个简化后的订单支付的场景，介绍一下Shadow Service 的具体使用方法。这个场景涉及订单（Order）和支付（Payment）两个服务，订单服务会调用支付服务，支付服务最终会调用第三方服务（图中未画出）来完成支付，同时，订单服务还会访问 MySQL 数据库。整个系统，通过 MegaEase 的 EaseMesh 部署在 Kubernetes 中，部署过程中，EaseMesh 会向应用的 Pod 中注入的 SideCar（基于Easegress）和 JavaAgent（基于 EaseAgent），从而劫持应用发出的 HTTP 请求和数据请求，实现前面提到的“三一致”和“四隔离”。系统的总体架构如图 1 所示。要对其进行测试，我们需要首先创建数据库的副本。这一步，可以通过数据库的备份恢复功能来完成，如图 2 所示，因为数据副本和原始数据位于同一个安全域，所以不必对数据进行脱敏处理。71712023.062023.06第 11期然后，使用下面的配置通过 EaseMesh 的命令创建订单服务的 shadow 副本和灰度规则。注意，在创建服务的副本时，我们将其使用的数据库指向了刚刚创建的数据库副本。最终系统架构如图 3 所示。kind:ShadowServiceapiVersion: namespace:megaease-mallmysql:uris:jdbc:mysql:/172.20.2.216:3306/shadow_order_db.userName:megaease password:megaease Ingress Mirror DB Testing Request Order Service JavaAgent Side Car Order Service JavaAgent Side Car Mesh Ingress Kubernetes Pod Real Customer Request Prod DB Payment Service JavaAgent Side Car Kubernetes Pod 图 3 扩展影子服务并对测试流量进行调度最后，因为不想在测试的时候实际支付费用，我们要用下面的命令 Mock 支付服务。注意，调用第三方支付服务时通常会涉及多个非常复杂的安全验证步骤，这导致这个服务难以被直接 Mock。所以，我们把第三方服务包装成了系统内部的服务，并借此简化了调用接口，下面 Mock 的实际上是这个包装后的服务：kind:MockapiVersion: rules:-match:pathPrefix:/Mirror DB Order Service JavaAgent Side Car Mesh Ingress Kubernetes Pod Real Customer Request Prod DB Payment Service JavaAgent Side Car Kubernetes Pod Order Service JavaAgent Side Car Mesh Ingress Kubernetes Pod Real Customer Request Prod DB Payment Service JavaAgent Side Car Kubernetes Pod 图 1 订单支持系统部署架构示意图 图 2 全量镜像复制数据库为测试库陈皓，等：一种完全无侵入式生产线上的全链路压力测试技术72722023.062023.06第 11期现代信息科技 Payment Service JavaAgent Side Car Ingress Mirror DB Testing Request Order Service JavaAgent Side Car Order Service JavaAgent Side Car Mesh Ingress Kubernetes Pod Real Customer Request Prod DB Payment Service JavaAgent Side Car Kubernetes Pod 图 4 Mockup 不参与测试的支付服务headers:Request-Header:exact:Testcode:200headers:Content-Type:application/jsonbody:result:succeeded这样就完成了整个测试系统的创建，我们可以向其发送带有 Request-Header:Test 头部的请求来进行压力测试。最终的系统架构如图 4 所示。3.3 Shadow Service 的优势相对于传统的测试方法，使用 Shadow Service 进行压力测试在以下 5 个方面具有明显的优势：1）0 代码修改：全部通过配置完整，不需要修改任何代码，没有改出 Bug 的风险。2）低成本：在使用云服务器的情况下，测试用的硬件资源随用随申请，用完就释放，仅需要为实际使用时段付费。3）业务逻辑与生产环境基本一致：除少数被 Mock 的服务外，测试系统与生产系统完全一致，最大程度避免了业务逻辑的差异导致的误差。4）可以使用生产数据进行测试：测试系统和生产系统的数据完全一致，保证了测试结果的准确性。5）安全：虽然测试时使用的是生产数据，但测试系统和生产系统处于同一个安全域，所以没有增加数据泄露风险。4 结 论通过 Service Mesh 以及 Shadow Service 技术把生产环境的应用服务和数据复制出一份用于测试，并通过流量网关进行测试流量的调度，我们可以在极低的成本下，实现业务一致、数据一致、资源一致以及业务隔离、数据隔离、流量隔离和资源隔离，同时，也避免了对代码的修改，降低了成本，保证了业务逻辑与生产环境的一致性，并可以使用生产数据进行测试，确保了测试结果的准确性和系统安全。因为只需要在付出一定的低成本云计算基础硬件资源，Shadow Service 成为网络时代全站压力测试的理想解决方案。参考文献：1 KOSCHEL A，BERTRAM M，BISCHOF R，et al.A Look at Service Meshes C/2021 12th International Conference on Information,Intelligence,Systems&Applications(IISA).Chania Crete：IEEE，2021:1-8.2 WEYUKER E J，VOKOLOS F I.Experience with performance testing of software systems:issues,an approach,and case study J.IEEE Transactions on Software Engineering，2000，26（12）：1147-1156.3 MALINA P.Kubernetes Canary Deployment Controllerbc EB/OL.2023-03-23.https:/dspace.vutbr.cz/bitstream/handle/11012/180400/final-thesis.pdf.4 RUDRABHATLA C K.Comparison of zero downtime based deployment techniques in public cloud infrastructure C/2020 Fourth International Conference on I-SMAC(IoT in Social,Mobile,Analytics and Cloud)(I-SMAC).Palladam：IEEE，2020：1082-1086.5 BINDER W，HULAAS J，MORET P.Advanced Java bytecode instrumentation C/Proceedings of the 5th international symposium on Principles and practice of programming in Java.Lisboa Portugal：Association for Computing Machinery，2007：135-144.作者简介：陈皓（1976），男，汉族，云南昆明人，资深系统架构师，本科，主要研究方向：大规模分布式计算系统及云原生架构；张博民（1977），男，汉族，河北雄县人，资深系统架构师，硕士，主要研究方向：服务网关和服务网络。