架构方案：测试场多环境逻辑隔离方案

Posted 2022-03-29 中间件兴趣圈

引言

随着功能的迭代和业务的增长，一套开发环境和一套测试环境往往很难满足需求。不同的功能、不同的分支代码在同一套环境测试，难免互相影响。所以看到公司往往有多套开发环境和多套测试环境，以应对这些冲突。多套环境带来的运维成本增加，例如：像中间件、DB、机器等往往需要独立部署。另外多套环境也难以解决众多开发测试需求，还可能造成冲突。

本文介绍通过测试场的方式来解决众多环境的的问题，主要内容有：

单套环境对开发测试的影响

测试场启动流程

测试场调用流程

中间件在测试场中的实现

一、单环境对开发测试的影响

下面整理了同一套环境开发测试中的常见问题，RPC调用错乱、消息消费错乱以及数据问题。

1.服务RPC调用错乱

如图所示，调用链路调用关系，A调用B，B调用C，接着C调用D，最后D调用E。

在同一套环境中，A和B两个服务分别拉了两个分支开发不同的功能。

A-branch1与B-branch1

A-branch2与B-branch2

期望A-branch1调用B-branch1，而A-branch2调用B-branch2。但有可能A-branch1调用B-branch2，A-branch2调用了B-branch1。也就是A和B之间的调用随机的，给开发调试造成困扰。

2.发送消费消息错乱

如图所示，调用链路调用关系，A调用B，B发送消息到消息集群，C消费后RPC调用D，最后D调用E。

在同一套环境中，B和C两个服务分别拉了两个分支开发不同的功能。

B-branch1与C-branch1

B-branch2与C-branch2

期望B-branch1发送的消息被C-branch1消费，而B-branch2发送的消息被C-branch2消费。但有可能B-branch1发送的消息被C-branch2消费了，B-branch2发送的消息被C-branch1消费了。也就是C-branch1和C-branch2消费时随机的，给开发调试造成困扰。

3.存储数据被改错乱

数据被改这个容易理解，大家共用一套数据库，各管各的开发调试。

把公共数据改了

把别人的数据改了

由于数据修改，影响了其他人的调试，给别人造成困扰。

二、测试场启动流程

1.测试场启动流程图示

2.测试场启动流程概述

在发布系统【创建测试场】该测试场中可以拉入联调的上下游服务以及分支

在发布系统脚本中通过-D将测试场参数（例如：-DtestGround=abcd）传入，RPC框架该标记写入注册中心，完成【节点打标】。例如：在注册中心节点1.2.3.4写入tag=abcd

消息集群通过不同主题来完成【消息流量隔离】，在启动节点可以动态拼接不同的消费组来订阅不同的主题。例如：abcd_melon_consumer 订阅 abcd_melon_topic 完成测试场abcd的流量隔离

三、测试场调用流程

1.RPC调用流程

测试场中提供一套稳定环境，该环境部署了master分支代码

在测试场1中，有联调服务A-branch1和B-branch1，没有其他服务。B-branch1调用C转回稳定环境调用

在测试场2中，有联调服务A-branch2和B-branch2，没有其他服务。B-branch2调用C转回稳定环境调用

2.消息调用流程

测试场中提供一套稳定环境，该环境部署了master分支代码

服务B发送消息到melon_topic，被服务C的消费组melon_consumer订阅，以及被另一个服务APP-X的消费组melon_appx_consumer订阅

在测试场1中，有联调服务B-branch1和C-branch1，没有其他服务，B-branch1发的消息被C-branch1消费

在测试场1中，通过不同主题abcd1_melon_topic和不同消费组abcd1_melon_consumer实现发送和消费流量隔离

在测试场2中，有联调服务B-branch2和C-branch2，没有其他服务，B-branch2发的消息被C-branch2消费

在测试场2中，通过不同主题abcd2_melon_topic和不同消费组abcd2_melon_consumer实现发送和消费流量隔离

在稳定环境中，APP-X的消费组melon_appx_consumer没有在测试场联调，需消费melon_topic、abcd1_melon_topic以及abcd2_melon_topic三个主题的消息

在稳定环境中，当测试场中部署了C-branch1和C-branch2时，稳定环境服务C的消费组melon_consumer，只消费melon_topic的消息

在稳定环境中，当测试场中只部署了C-branch1，而没有C-branch2时，稳定环境服务C的消费组melon_consumer，需消费melon_topic、abcd2_melon_topic两个主题的消息

在稳定环境中，当测试场中只部署了C-branch2，而没有C-branch1时，稳定环境服务C的消费组melon_consumer，需消费melon_topic、abcd1_melon_topic两个的消息

在稳定环境中，当测试场中没有部署了C-branch1和C-branch2时，稳定环境服务C的消费组melon_consumer，需消费melon_topic、abcd1_melon_topic、abcd2_melon_topic三个主题的消息

四、中间件在测试场中的实现

测试场多环境逻辑隔离主要依赖基础组件提供的能力支持，主要涉及标记链路透传、RPC框架节点打标和选择、消息的流量隔离以及网关和分布式调度的标记透传。

1.链路标记透传

链路透传在众多方案中都是必备的，比如：全链路压测、链路tracing，可参考下面两种实现方式：

OpenTracing Baggage

transmittable-thread-local

备注：通过中间件提供公共组件完成链路标记向下透传。

2.RPC框架节点打标和选择

测试场中需要对节点打标，再根据上下文透传的标记选出打标节点发起调用，具体RPC框架能力为：

节点打标，比如：对1.2.3.4节点打上测试场的标【abcd】

节点选择，比如：根据链路透传过来的标记【abcd】选择对应的打标节点

默认节点，如果没有打标节点，需要选择默认节点

链路透传，选择了节点发起RPC调用，继续透传测试场标记【abcd】

3.消息的流量隔离

对于消息来说，需要对不同的测试场流量进行隔离，如上第三部分测试场调用流程中的消息调用，场景也比较多，消息的方案复杂的多。

流量隔离，通过不同的主题和消费组完成测试场流量的隔离

消息发送侧，如果链路中有测试场标记，则动态拼接隔离主题，将该流量发送到隔离主题，例如：abcd_melon_topic。同时在元数据中心记录【发送侧测试场标记】

消息消费侧，如果该消费组被拉入测试场，通过隔离消费组订阅隔离主题，实现消费流量隔离，例如：abcd_melon_consumer订阅abcd_melon_topic。同时在元数据中心记录【消费侧测试场标记】

稳定环境的消费组，需要监听【发送侧测试场标记】和【消费侧测试场标记】的变化，实现动态接管测试场的流量或者剔除测试场流量，例如：稳定环境消费组melon_consumer除了订阅melon_topic外，是否订阅abcd_melon_topic；取决于测试场中是否有abcd_melon_consumer

在实践中可以在RocketMQ/Kafka集群开启自动创建主题和消费组权限，并在新的集群自动创建的主题和消费组与原集群分离，方便清理。

4.其他组件

测试场的流量隔离主要在RPC框架和消息队列实现，网关和分布式调度等主要参与标记透传。另外，数据可以通过构造偏移数据来规避数据的不一致，降低数据库实现逻辑隔离的复杂性。

最后说一句(求关注，别白嫖我)

如果这篇文章对您有所帮助，或者有所启发的话，帮忙扫描下发二维码关注一下，您的支持是我坚持写作最大的动力。

求一键三连：点赞、转发、在看。

关注公众号：「中间件兴趣圈」，在公众号中回复：「PDF」可获取大量学习资料，回复「专栏」可获取15个主流Java中间件源码分析专栏，另外回复：加群，可以跟很多BAT大厂的前辈交流和学习。

走进作者

10年IT老兵给职场新人的一些建议

“我”被阿里巴巴宠幸了

程序员如何提高影响力

优秀程序员必备技能之如何高效阅读源码

我的另一种参与 RocketMQ 开源社区的方式

点击查看“阅读原文”，可直接进入[中间件兴趣圈]文章合集。

手把手这篇全链路压测实践教程

Hello，大家好呀，前两篇文章，我们说了下关于全链路压测的意义、整体架构，以及5种压测的方案。

前面两篇基本都属于比较理论的内容，今天这篇咱们来点实践的东西，手把手带你搞出一个压测来

如果不清楚之前两篇的文章的小伙伴，可以先看下，在这里

• 大厂钟爱的全链路压测有什么意义？四种压测方案详细对比分析
• 代码级】全链路压测的整体架构设计，以及5种实现方案（流量染色、数据隔离、接口隔离、零侵入、服务监控）

7 环境准备

7.1 环境服务列表

服务	ip	端口	备注
mysql	172.18.0.10	3306	数据库服务
rabbitMQ	172.18.0.20	5672,5672	RabbitMQ消息服务
redis	172.18.0.30	6379	Redis缓存服务
nacos	172.18.0.40	8848	微服务注册中心
skywalking	172.18.0.50	1234,11800,12800	链路追踪APM服务端
skywalking-ui	172.18.0.60	8080	链路追踪APM服务UI端

7.2 应用服务列表

服务	ip	端口	备注
order-service	127.0.0.1	8001	订单服务
account-service	127.0.0.1	8002	账户服务
storage-service	127.0.0.1	8003	数据存储服务
notice-service	127.0.0.1	8004	通知服务

7.3 docker-compose 编排环境

version: 2
services:
    mysql:
        image: mysql:5.7
        hostname: mysql
        container_name: mysql
        networks:
            docker-network:
                ipv4_address: 172.18.0.10
        ports:
            - "3306:3306"
        environment:
            MYSQL_ROOT_PASSWORD: root
        volumes:
            - "/tmp/etc/mysql:/etc/mysql/conf.d"
            - "/tmp/data/mysql:/var/lib/mysql"
    rabbitMQ:
        image: rabbitmq:management
        hostname: rabbitMQ
        container_name: rabbitMQ
        networks:
            docker-network:
                ipv4_address: 172.18.0.20
        ports:
            - "5672:5672"
            - "15672:15672"
    redis:
        image: redis
        hostname: redis
        container_name: redis
        networks:
            docker-network:
                ipv4_address: 172.18.0.30
        ports:
            - "6379:6379"
        volumes:
            - "/tmp/etc/redis/redis.conf:/etc/redis/redis.conf"
            - "/tmp/data/redis:/data"
        command:
           redis-server /etc/redis/redis.conf
    nacos:
        image: nacos/nacos-server
        hostname: nacos
        container_name: nacos
        depends_on:
            - mysql
        networks:
            docker-network:
                ipv4_address: 172.18.0.40
        ports:
           - "8848:8848"
        environment:
            MODE: standalone
        volumes:
            - "/tmp/etc/nacos/application.properties:/home/nacos/conf/application.properties"
    skywalking:
        image: apache/skywalking-oap-server
        hostname: skywalking
        container_name: skywalking
        networks:
            docker-network:
                ipv4_address: 172.18.0.50
        ports:
           - "1234:1234"
           - "11800:11800"
           - "12800:12800"
    skywalkingui:
        image: apache/skywalking-ui
        hostname: skywalkingui
        container_name: skywalkingui
        depends_on:
            - skywalking
        networks:
            docker-network:
                ipv4_address: 172.18.0.60
        environment:
            SW_OAP_ADDRESS: 172.18.0.50:12800
        ports:
           - "8080:8080"
networks:
    docker-network:
        ipam:
            config:
                - subnet: 172.18.0.0/16
                  gateway: 172.18.0.1

7.4 初始化数据

1. 初始化用户数据以及产品数据

2. 将feign,hystrix,ribbon等统一配置配置到nacos

   # 配置超时时间
   feign:
     hystrix:
       enabled: true  #开启熔断
     httpclient:
       enabled: true
   hystrix:
     threadpool:
       default:
         coreSize: 50
         maxQueueSize: 1500
         queueSizeRejectionThreshold: 1000
     command:
       default:
         execution:
           timeout:
             enabled: true
           isolation:
             thread:
               timeoutInMilliseconds: 60000
   ribbon:
     ConnectTimeout: 10000
     ReadTimeout: 50000
   

8 全链路压测测试

8.1 jmeter配置

8.2 第一轮压测

8.2.1 链路分析优化

8.2.2 数据库连接池优化

initialSize: 10
minIdle: 20
maxActive: 100

8.3 第二轮压测

8.3.1 观察消费节点

发现平均响应时间在200ms左右

检查断点链路/storage/order/actualPlaceOrder

9 Skywalking 使用

9.1 Skywalking 模块栏目

• 仪表盘：查看被监控服务的运行状态
• 拓扑图：以拓扑图的方式展现服务直接的关系，并以此为入口查看相关信息
• 追踪：以接口列表的方式展现，追踪接口内部调用过程
• 性能剖析：单独端点进行采样分析，并可查看堆栈信息
• 告警：触发告警的告警列表，包括实例，请求超时等。
• 自动刷新：刷新当前数据内容。

9.2 仪表盘

• 第一栏：不同内容主题的监控面板，应用/数据库/容器等
• 第二栏：操作，包括编辑/导出当前数据/倒入展示数据/不同服务端点筛选展示
• 第三栏：不同纬度展示，服务/实例/端点

9.3 展示栏

9.3.1 Global全局维度

• 第一栏：Global、Server、Instance、Endpoint不同展示面板，可以调整内部内容
• Services load：服务每分钟请求数
• Slow Services：慢响应服务，单位ms
• Un-Health services(Apdex):Apdex性能指标，1为满分。
• Global Response Latency：百分比响应延时，不同百分比的延时时间，单位ms
• Global Heatmap：服务响应时间热力分布图，根据时间段内不同响应时间的数量显示颜色深度
• 底部栏：展示数据的时间区间，点击可以调整。

9.3.2 Service服务维度

• Service Apdex（数字）:当前服务的评分
• Service Apdex（折线图）：不同时间的Apdex评分
• Successful Rate（数字）：请求成功率
• Successful Rate（折线图）：不同时间的请求成功率
• Servce Load（数字）：每分钟请求数
• Servce Load（折线图）：不同时间的每分钟请求数
• Service Avg Response Times：平均响应延时，单位ms
• Global Response Time Percentile：百分比响应延时
• Servce Instances Load：每个服务实例的每分钟请求数
• Show Service Instance：每个服务实例的最大延时
• Service Instance Successful Rate：每个服务实例的请求成功率

9.3.3 Instance实例维度

• Service Instance Load：当前实例的每分钟请求数
• Service Instance Successful Rate：当前实例的请求成功率
• Service Instance Latency：当前实例的响应延时
• JVM CPU:jvm占用CPU的百分比
• JVM Memory：JVM内存占用大小，单位m
• JVM GC Time：JVM垃圾回收时间，包含YGC和OGC
• JVM GC Count：JVM垃圾回收次数，包含YGC和OGC
• CLR XX：类似JVM虚拟机，这里用不上就不做解释了

9.3.4 Endpoint端点（API）维度

• Endpoint Load in Current Service：每个端点的每分钟请求数
• Slow Endpoints in Current Service：每个端点的最慢请求时间，单位ms
• Successful Rate in Current Service：每个端点的请求成功率
• Endpoint Load：当前端点每个时间段的请求数据
• Endpoint Avg Response Time：当前端点每个时间段的请求行响应时间
• Endpoint Response Time Percentile：当前端点每个时间段的响应时间占比
• Endpoint Successful Rate：当前端点每个时间段的请求成功率

9.4 拓扑图

• 1：选择不同的服务关联拓扑
• 2：查看单个服务相关内容
• 3：服务间连接情况
• 4：分组展示服务拓扑

9.5 追踪

• 左侧：api接口列表，红色-异常请求，蓝色-正常请求
• 右侧：api追踪列表，api请求连接各端点的先后顺序和时间

9.6 性能剖析

• 服务：需要分析的服务
• 端点：链路监控中端点的名称，可以再链路追踪中查看端点名称
• 监控时间：采集数据的开始时间
• 监控持续时间：监控采集多长时间
• 起始监控时间：多少秒后进行采集
• 监控间隔：多少秒采集一次
• 最大采集数：最大采集多少样本