Rhino 字节跳动全链路压测的实践( 三 ) _全链路压测

c. 对于新项目，在项目开始初期，就将压测改造加入项目开发规范中，减少后期的代码改动
3.3 链路治理链路梳理请求调用链，对于线上压测是非常重要的：

提供清晰压测流量地图，并提供完整的链路监控。
完成服务依赖的梳理，检测压测所依赖的服务/中台是否具备压测的条件，是否需要压测改造。
链接压测开关管理，压测上下游周知等。

Rhino 平台通过公司的流式日志系统来完成调用链检索的。一个服务在被请求或者请求下游时，都会透传一个 LogID 。RPC 框架会打印调用链日志（包括 RPC 日志-调用者日志，Access 日志-被调用者日志），所有日志中都会包含这个 LogID 。通过 LogID 将一个请求所经过的所有服务日志串起来，就完成调用链检索。

文章插图

Rhino 平台在公司流式日志系统提供的链路梳理功能基础上，进行了进一步优化，以满足压测需要：

自动梳理：由于公司采用微服务架构，每个请求背后的调用链路及其复杂，单纯靠人工维护是无法完成的。用户只需要提供请求中 LogID，Rhino 平台就能快速梳理出该请求经过的服务节点，如图。
实时梳理：由于线上服务不断在变化，上线下线新增等，因此同一个请求的调用链也是不断变化的。Rhino 平台建议一般使用 1 个小时内的 LogID 进行梳理。
多调链路合并：同一个接口，不同参数下的调用链是不尽相同的。Rhino 平台会将多个 LogID 梳理的结果自动进行合并，来补全调用链，保证链路梳理结果的准确性和完整性。

文章插图

压测周知虽然 Rhino 平台对于压测有很多的安全保障措施，但是对于大型压测，保证信息的通畅流通也是非常重要的。因此在压测周知方面，Rhino 平台也提供了很多解决方案：

一键拉群：梳理完链路后，在压测前可以一键拉群，将链路中上下游服务的 Owner 拉到同一个群里，同步压测信息。
压测周知：每个压测开始执行时，都会向压测周知群里推送消息，如压测 QPS，压测时长等信息。

文章插图

压测事件：在压测开始执行时，Rhino 平台还会向目标服务的事件队列中发送一个压测事件，方便快速评估/定位稳定性问题是否是压测导致，减少 RD 线上问题排查的干扰。

压测开关管理在压测之前，需要开启整体链路的压测开关的，否则压测流量就会被服务拒绝，导致压测失败。

一键开启：在压测执行之前，Rhino 平台可以一键开启链接上所有节点的压测开关。
压测开关开启周知：压测开关开启时，Rhino 平台会自动给对应服务 Owner 推送相关信息，确保服务 Owner 了解相关压测信息，上游会有压测流量会经过其服务。
静默关闭：压测开关到期后，Rhino 会自动静默关闭压测开关，以保证线上服务的安全。

文章插图

服务 Mock对于调用链中不能压测的服务(敏感服务)，或者第三方服务，为了压测请求的完整性，就需要对这些服务进行 Mock 。业界通用的 Mock 方案有：

修改业务代码，修改服务调用为空转代码。优点：实现成本低。缺点：返回值固定，代码&业务入侵高，推动困难。如要 Mock 位置比较靠下游，超出部门覆盖业务范围，推动就非常麻烦。
通用 Mock 服务。通用 MockServer，会根据不同用户配置不同 Mock 规则，执行对应的响应延时，并返回对应响应数据。优点：无代码入侵，业务方无感知。缺点：实现成本高。

由于字节整个公司都采用微服务架构，导致一次压测涉及链路都比较长，快速无业务入侵的 Mock
方式成为了首选。Rhino 平台是通过公司 Service Mesh 和 ByteMock 系统来实现了高效的，对业务透明的服务 Mock 。
压测执行前，Rhino 平台需要向 Service Mesh 注册染色转发规则，并向 Mock 服务注册 Mock 规则。然后在压测流量中注入 Mock 染色标记，才能完成服务 Mock：