机器人大闹光棍节：直击双11京东全链路军演ForceBot

常听说各大电商需要通宵备战双十一。购物大趴过后，人们摩挲着光秃秃的手腕，不禁在想，这些口口声声说在为我们保驾护航的家伙，那天究竟干了什么？为此，我们提前走访了京东双11作战指挥部，先为大家带来这支神秘之师战前演练的实况！

心里要有点数

什么是全链路压测？

全链路压测可以理解为网络链路 + 系统链路。网络链路是用户到机房的各个网络路由延迟环境；系统链路是各个系统之间的内部调用关系和强依赖性。

为什么要做全链路压测？

电商大促期间存在不同于日常流量场景的高流量冲击，为了应对大促流量场景，保证大促期间用户可以顺畅地进行购买的一系列流程，而不会出现某个环节（比如支付环节）上的系统宕机或者数据错乱（比如商品库存量读写错误）等情况，必须要在大促前进行全链路压测，也就是进行大促前的军演，以便提前做好扩容及系统问题修复优化等。

传统的全链路压测是如何来做的？

传统的系统压测会用到一些常用的工具：loadrunner、jmeter、nGrinder、gatling、iperf等，通过这些工具，模拟生产环境中的真实业务操作，对系统进行压力负载测试，同时监控被压测的系统负载、性能指标等不同压力情况下的表现，并找出潜在的性能优化点和瓶颈。压测的部署基本都是在内网环境，和被压测的系统部署在一个局域网内。目前流行的压测工具，工作原理基本都是一致的，在压力机端通过多线程或者多进程模拟虚拟用户数并发请求，对服务端进行施压。

传统的全链路压测存在哪些问题？

• 由于业务不断扩张，研发体系的系统也随之增加，各核心系统环环相扣，尤其是强依赖系统，且上下游关系等紧密结合，其中一个系统出现瓶颈问题，会影响整个系统链路的处理性能，直接影响用户购物体验。在这种情况下，利用传统的全链路压测方法来做压测，需要至少提前 3个月来准备，各个性能的压测需要根据一定的排期来进行，且每个压测团队的工作量也很大，须耗费大量的人力物力和时间。
• 传统的压测数据与线上对比，并不准确。以前对某个系统性能的压测需要在内网线下进行多次，压测出的结果各项指标与线上相比差异太大；这是因为线下服务器配置和上下游服务质量不可能与线上一模一样，只能作为一个参考，不能视作线上系统的真实表现。
• 更重要的一个问题是各系统的容量规划，每次大促前备战会必不可少的讨论话题就是服务器资源申请扩容的问题，各团队基本都是依据往年经验和线上资源使用率给出评估量，提出一个扩容量需求，导致各个业务系统每次促销的扩容量都非常大。如果不能精确预估容量需求，会发生扩容行为的浪费。

从以上问题的回答中，我们了解了什么是全链路压测，为什么要做全链路压测，传统的全链路压测是如何来做的，以及传统的全链路压测存在哪些问题。既然全链路压测是电商大促前必不可少的一个环节，且传统的全链路压测方法又存在这么多的问题，那么，是否有更好的方法来进行全链路压测，以节省人力物力和时间成本，且能够得到线上的真实数据，对系统资源进行更优的配置从而降低扩容浪费等行为呢？

让我们来看京东的ForceBot是否解决了这些问题。

ForceBot简介

ForceBot全链路压测项目，是京东基础架构部为了解决传统全链路压测的各种苦恼，在 2016 年整体牵头启动的项目，此项目牵扯到所有京东研发体系团队，各系统必须对压测过来的流量和线上正式流量进行区分标记等特殊处理，以识别两种不同的流量，不能因为压测流量而影响正常的用户体验和污染线上数据等，由于跨团队协作之多、跨系统协调改造等工作量非常大，挑战性可想而知！

ForceBot能做什么

2016年ForceBot项目启动后，当年便主要实现了如图1所示的订单前的所有黄金链路流程高并发压测用户行为模拟，模拟用户操作涉及模块包括首页、登录、搜索、列表、频道、产品详情、购物车、结算页、京东支付，详细链路示意图如图2所示。在黄金链路中有各种用户行为场景，比如一般用户首先访问首页，在首页搜索想要的产品，翻页浏览，加入购物车、凑单、修改收货地址、选择自提等。各系统压测量会以往年双11峰值作为基础量，在此基础上动态增加并发压力，同时区分对待两大压测的场景：日常流量场景和大促流量场景。大促场景下抢购活动集中，交易中心的写压力最大，且用户行为和日常有很大的反差，如用户会提前加入购物车、选择满减凑单、集中下单等场景。ForceBot同时也可以承担内网单一系统的日常压测任务，开放给开发与测试团队，作为统一平台来支撑京东所有的性能压测需求，使效率显著提升。

图1 黄金链路图

图2 京东全链路压测关系图

ForceBot替代了往年各系统独自优化、性能压测备战状态，可以秒级监控到压测源、压测中、京东所有的黄金链路系统、接口响应时间、TPS 、TP99 等数据，军演完成后会提供丰富的压测报告，准确地找到各系统的并发瓶颈。目前所有的备战数据和各系统性能承载能力、资源规划等都由ForceBot给出直接数据作为依据，也是大促前性能优化与资源规划的主要依据。

综上所述，ForceBot可以一次性、自动化完成整个黄金链路的压测工作，且能动态增加并发压力，实现了自动化、全链路、强压力的目标，又因为其对压测流量及线上正式流量做了标记区分，使压测可以完全在真实场景下进行模拟，得到的各项压测数据也更加真实。

ForceBot技术架构

如此强大的ForceBot压测军演平台是如何实现的呢？下面我们来看一下其具体的技术架构。

如图3所示，平台在设计时针对核心功能进行了尽可能的解耦，将各模块拆分成一个个相对独立的服务程序，所有服务均为分布式，避免了单点故障对系统功能带来的影响，并方便进行有针对性的水平扩容。

图3 ForceBot架构

其中一些服务程序说明如下。

• Controller负责任务分配，并通过数据库字段维护Agent状态。
• Task Service负责任务下发，支持横向扩展。
• Agent用来注册心跳、拉取任务、执行任务。
• Monitor Service用于接受Agent上报的监控和日志数据并转发给Kafka，由 Compute Service 对数据进行进一步计算处理。
• Compute Service对压测数据做计算，将计算结果保存到Elasticsearch。
• Git 用来保存性能测试脚本，提供完整的版本控制管理功能。
• Script Package Service 为压力测试脚本提供统一的异步构建打包支持，通过对Maven的支持，与内网Maven私服交互，为脚本提供灵活可靠的依赖管理。
• JSS为 FoceBot 提供了可靠高效的一站式资源分发解决方案，所有经 Script Package Service 构建并打包后的性能测试脚本会上传至 JSS的对象存储，通过Agent主动拉取的方式向Agent分发资源。

系统为性能测试脚本提供了多种生命周期控制，已适用不同的场景，并可大幅度提升执行效率，减少对象创建次数。同时，提供动态增减进程线程数量及 Agent数量的功能，以灵活控制测试压力。此外，还提供集合点设计功能，以适用更多场景。

由于篇幅关系，关于架构中的核心功能、容器部署、心跳和任务下发、数据收集和计算等具体介绍请见《京东基础架构建设之路》一书。下面先只对架构中 Agent的实现做一个简短的介绍。

Agent实现

Agent采用多进程多线程的结构设计。主处理进程负责任务的接收、预处理和 Worker 进程的调度。将任务的控制和执行进行进程级别的分离，这样可以为测试的执行提供相对独立且高度灵活的类库环境，使不同任务之间的类库不会产生冲突，并有益于提升程序运行效率。

Agent与 Task Service 保持通信，向系统注册自身并获取指令。如图4所示，根据任务，需要启动Worker进程执行任务，主进程负责管理 Worker 进程的生命周期。Worker进程启动后会通过TCP连接与主进程保持通信，获取新的变更指令，如线程数变化通知，并及时进行调整。

图4 ForceBot Agent结构

ForceBot已经在多次电商大促中进行实践并取得了很好的果效。曾经进行一次全链路压测可能需要 3个月，如今只需要 2天左右便可完成，大幅度降低了人力物力和时间成本，同时真实模拟线上环境，使得获取的压测数据更加真实可用，减少了资源分配的浪费。京东也希望 ForceBot 未来可以实现“人工智能预言”，在全链路压测中引入 AI 技术，通过人工智能预言各个系统的流量值和资源分配建议，根据线上的系统军演数据预言未来大促的各系统场景。

本文取材自《京东基础架构建设之路》一书，并参考了张克房的文章《 618升级全链路压测方案，打造军演机器人 ForceBot》。关于ForceBot 业务系统改造的详细内容及其他基础架构的详细解析请，可点击文末 阅读原文 直达↓↓↓这本烫手新书！