中台架构下的性能测试实践方法

知识星球有同学私信问我：中台服务建设过程中，性能测试如何开展？问题背景如下：

业务背景：银行业务；

技术架构：业务应用和中台之间请求统一走 ESB；

当前阶段：中台建设中，一边拆分一边推动业务应用接入；

具体问题：性能测试范围如何界定？业务应用是否需要纳入压测范围？

在我看来，这是一个很典型的性能需求分析问题。只有明确了测试的范围和目的，才能制定合理的测试方案，采用正确的测试策略来对中台服务开展性能测试。

一分钟快速了解中台

中台这个概念，国内最早是在 15 年由阿里提出并开始实践的。中台的出现是为前台(业务层)提供服务，支撑业务规模化创新，进而更好的服务用户，让企业业务目标更好的达成。

现在很多公司的技术部门都有基础架构团队，负责为公司技术部门提供各种支撑技术研发的底层设施和通用框架或工具。简单理解，可以将中台看作一种公司的基础设施，它具备三大特征：敏捷+解耦+服用。

• 敏捷：业务需求变化快，变更频率以天甚至小时为计，将大应用变为多个小应用，才能支撑业务的敏捷。

• 解耦：随着业务发展，业务系统间的交互也更复杂，一次变更带来的影响范围可能是多方面的。只有将需要大量交互的功能独立，从应用中拆解出来，才可以使得应用之间耦合度大幅下降。

• 复用：将公共能力复用，可以提高开发效率，避免重复建设，同时使得数据和流程可以集中得以管理和优化。

在上述的案例背景下，我个人认为性能测试活动的开展，可以分三步走。

第一步：验证中台服务水位

首先中台服务中包含的是多个公共需求组合而成的服务，比如用户、支付、订单业务，以及更基础的服务，如安全认证、权限管理、消息通知等。在开展性能测试活动时，应该遵循这几个步骤：

• 单机单接口：验证中台服务中某个公共应用功能模块的性能表现，排查明显的性能问题；

• 单机混合场景：验证中台服务中某个公共应用服务级别的性能表现，得到安全水位的性能指标；

• 集群扩展能力：中台服务作为基础设施，要满足业务的快速扩展，支撑峰值流量冲击，因此其本身要具备性能的水平扩展能力。集群压测的目的是为了验证服务扩容后，带来的性能提升比率，便于后续的限流降级等服务稳定性保障手段开展。

单机单接口的目的是性能问题快速排查和性能摸底，单机混合场景是得到服务级别的性能表现，而集群扩展能力的测定依赖与单机混合场景的安全水位下的性能指标数值。

当然，单机混合场景的开展前提，需要对业务调用关系(业务模型)和调用次数及强弱依赖(流量模型)进行梳理，否则得到的结果往往是不准确的。

业务模型和流量模型内容，详见:《核心链路四问》《构建三大模型》

第二步：设定服务保护阈值

中台服务作为一种基础设施，为业务应用提供支撑，原则上应该无条件支撑业务的扩展和高速迭代。但在实际建设和应用过程中，首先应该考虑的是先保障自己的稳定性。只有自身的性能和稳定性足够好，才能支撑业务，否则就会出现前段时间阿里云服务宕机带来的巨大影响和损失。

中台服务本身是为了业务快速发展提供支撑，降低业务调用之间的耦合，提高复用能力，那么可以将其本身的性能看作一种对业务的承诺。即我承诺在多少并发及什么异常场景下，保障自己的稳定性达到多少(比如 SLA=99.9999%)，而超出的部分，为了保障整体服务的稳定性，我会进行限流降级熔断等措施。

前面的文章介绍过限流降级熔断隔离等稳定性保障手段，这里大致介绍一下这些应急手段的副作用和相关的冗余手段。比如业务降级是有损的，需要提前进行详细的评估，并和业务方达成一致；比如限流熔断除了需要精准的测试得到指标数值之外，还需要完善及时的监控系统以及应急响应机制来支撑，否则大概率会出问题。

关于限流降级熔断内容，详见:《聊聊稳定性预案》《高可用和性能优化》《监控能给你带来什么》

第三步：业务链路端到端压测

知道了中台服务本身的性能表现，又通过限流降级等手段保障了中台服务其本身的稳定性，接下来就是业务链路端到端压测，也就是全链路压测。

全链路压测现在已经有了很成熟的落地方案和很多优秀的实践案例，但在现实工作场景中，对大多数公司来说，落地依然是一个很大的挑战。主要原因有如下几项：

• 全链路压测并不是一个银弹，它只适合小部分公司，且不能解决所有稳定性问题；

• 全链路压测特别是在生产环境落地，最大的挑战不是技术问题，而是跨团队沟通和组织协调问题；

• 全链路压测落地的成本其实很高，并不存在什么低成本便捷的落地方案，因此端到端的业务测试性价比更高；

关于全链路压测更多内容，详见:《从零开始落地全链路压测系列》

当然，在上述案例背景下，除了考虑压测和性能优化，还要考虑 ESB 本身的性能扩展、带宽以及业务团队的配合度。复杂的问题往往需要整套的解决方案，但这个解决方案本身，其实是由一个个小而简单的方法构成。