vlambda博客
学习文章列表

随着分布式建设工作的推进，核心系统正在逐步下移，分布式系统不但降低成本，具有比集中式更佳的性能，同时也便于系统扩展、维护。

分布式统一入口系统在整个系统中担任类似网关的角色，为不同请求提供统一入口，验证请求合法性、安全性，转换请求报文的格式等功能，将请求按照策略转发到其他分布式系统处理请求。

由于分布式系统之间需要相互调用、转发，才能正常完成业务需求。

为了避免分布式核心系统之间相互调用造成的连带影响，保护分布式统一入口系统及其他关联分布式核心系统，提供交易级、微服务级、子系统级等5种维度的流量控制方案，主要针对TCP请求进行流量控制，流量控制采用配置中心配置、文件配置两种方式，实现对交易请求的流量控制，具体架构如图1所示。

图1  简化分布式系统架构

本次流控功能测试，主要对：流控计数功能、交易维度流控阈值功能、超时刷新缓存、配置中心热更新配置四个方面进行功能测试。

本次只涉及TCP请求的流控，为了全面的覆盖各个分支，测试分别选取主机交易、开放交易、查询系统交易，测试工具选取Jmeter模拟触发流控场景。

为了避免其他其他测试请求对测试结果产生影响，选用性能环境中，一台未接入F5的server执行测试。

测试前，在配置中心中提前配置流控参数，如图2所示，配置项包括：总流控阈值为100，请求数据超时时间30秒，统计窗口为0-10、10-20、20-30，限流统计时间间隔为30秒。

图2  配置中心中流控配置集的参数配置

此时，使用Jmeter按照50并发发压，待TPS稳定后，将流控总阈值100修改为30，此时会触发流控，交易执行情况如图3所示。

图3  开放交易修改阈值后触发流控场景

如果，需要按照交易维度进行流量控制，在配置中心中可以按照图4设置配置项。

其中，TR_COD指明规则按照交易维度配置，命中交易且阈值为35，default为非命中交易的阈值，交易维度配置中也有个total，可以解释为命中维度配置规则（即TR_COD）的流量控制阈值。

图4  交易维度流量控制配置

当进行混合交易测试的时候，同时发送命中交易和非命中交易，分别按照20并发和30并发，此时是不会触发流控的。

将配置中心中命中交易的阈值35修改为15，此时，预期效果是命中交易会触发流控，而非命中交易正常执行，但是使用Xmeter的实际执行中发现，一旦触发流控，两支交易会同时触发，如图5。

通过查看分布式统一入口系统的日志，发现日志中只记录的其中一支交易触发流控，没有另一支交易的报错信息（其中绿色为成功的命中交易，红色为成功的非命中交易，蓝色为失败的命中交易，棕色为失败的非命中交易）。

图5

不同交易同时发送命中交易未到阈值触发流控

后来，又分别对命中交易、default制造触发流控的场景，两支交易始终同时触发或着均不触发，日志仍然只有一支交易的报错信息，并且报错的记录数是两支交易请求数量的总和。

后来，使用Xmeter单独对命中交易发压并触发流控，流控期间使用TCP报文请求小工具发送非命中交易请求，此时查看分布式统一入口系统日志，可以看到非命中交易未触发流控正常执行，而命中触发流控，推断出是Xmeter发压工具的问题。

经过分析，流量控制的触发是因为Jmeter发压工具中取样器的问题导致。

一般地，在使用Xmeter发压的时候，先通过本地Jmeter5.X中调通脚本，后上传至Xmeter执行。

对于TCP请求报文，主要使用我行开发的BoEing取样器，而此取样器基于TCP取样器开发，其中有一个参数Re-use connection是默认勾选的。

在Jmeter5.X中，取样器将可勾选参数封装在内部，无法选择是否勾选，该参数将脚本设置为请求连接复用的方式发送请求，而分布式统一入口系统当请求到来的时候，会为每个请求线程赋予一个存储区域，存放交易的交易码、通道、渠道等参数。

如果使用复用连接的方式，导致分布式统一入口系统从存储区域取到的请求参数始终为第一个建立连接的请求交易线程的参数，所以，出现了不按照预期触发流控的情况。

当其他核心系统在测试的过程中，如果遇到分布式统一入口系统报流量控制的错误，除了考虑其他交易请求影响、分布式统一入口系统自身问题，还需要关注测试工具的正确性。

通过本次测试，发现Jmeter5.X版本的取样器造成结果的异常，如果使用Jmeter5.X版本的时候，需要重点关注取样器中的勾选参数是否会影响测试结果的正确性，有时候测试返回结果是符合预期的，但是看日志会发现执行过程其实不符合预期，这种情况可能会对测试结果的准确性产生影响。

如果会影响，建议使用Jmeter提供的原生取样器或者使用Jmeter3.X版本或者其他发压工具。