整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
很多时候我们如果不想等待缓存的过期，想要主动清除缓存，可以采用第三方的缓存清除模块清除缓存nginx_ngx_cache_purge 。安装nginx的时候，需要添加 purge 模块， purge 模块我们已经下载了，在 /usr/local/server 目录下,添加该模块 --add-module=/usr/local/server/ngx_cache_purge-2.3/ ,这一个步骤我们在安装 OpenRestry 的时候已经实现了。
安装好了后，我们配置一个清理缓存的地址：
这里 代表的是 (/.*) 的数据。
每次请求 $host$key 就可以删除指定缓存，我们可以先查看缓存文件的可以：
此时访问 <http://192.168.211.141/purge/user/wangwu>
此时再查看缓存文件，已经删除了。
参数说明：
Lua是一门以其性能著称的脚本语言，被广泛应用在很多方面。Lua一般用于嵌入式应用，现在越来越多应用于游戏当中，魔兽世界,愤怒的小鸟都有用到。
优势：
Lua脚本的作用：嵌入到应用程序中，给应用程序提供扩展功能。
依赖安装： yum install libtermcap-devel ncurses-devel libevent-devel readline-devel pcre-devel gccopenssl openssl-devel
下载安装包： curl -R -O http://www.lua.org/ftp/lua-5.3.5.tar.gz
解压安装： tar zxf lua-5.3.5.tar.gz
安装：
此时原来系统自带的lua其实是5.1.4，我们需要替换原来系统自带的lua：
查看版本
创建hello.lua文件，内容为
编辑文件hello.lua
在文件中输入：
保存并退出。
执行命令
输出为：
效果如下：
lua有交互式编程(在控制台编写代码)和脚本式编程(在文件中写代码叫脚本编程)。
交互式编程就是直接输入语法，就能执行。
脚本式编程需要编写脚本，然后再执行命令 执行脚本才可以。
一般采用脚本式编程。（例如：编写一个hello.lua的文件，输入文件内容，并执行lua hell.lua即可）
(1)交互式编程
Lua 提供了交互式编程模式。我们可以在命令行中输入程序并立即查看效果。
Lua 交互式编程模式可以通过命令 lua -i 或 lua 来启用：
如下图：
(2)脚本式编程
我们可以将 Lua 程序代码保持到一个以 lua 结尾的文件，并执行，该模式称为脚本式编程，例如上面入门程序中将lua语法写到hello.lua文件中。
注释
一行注释：两个减号是单行注释:
多行注释
定义变量
全局变量，默认的情况下，定义一个变量都是全局变量，
如果要用局部变量 需要声明为local.例如：
如果变量没有初始化：则 它的值为nil 这和java中的null不同。
如下图案例：
Lua中的数据类型
Lua 是动态类型语言，变量不要类型定义,只需要为变量赋值。 值可以存储在变量中，作为参数传递或结果返回。
Lua 中有 8 个基本类型分别为：nil、boolean、number、string、userdata、function、thread 和 table。
lua红有个type函数，能出对象的类型。
实例：
if语句
Lua if 语句 由一个布尔表达式作为条件判断，其后紧跟其他语句组成。
语法：
实例：
if..else语句
Lua if 语句可以与 else 语句搭配使用, 在 if 条件表达式为 false 时执行 else 语句代码块。
语法：
实例：
循环[练习]
while循环[满足条件就循环]
Lua 编程语言中 while 循环语句在判断条件为 true 时会重复执行循环体语句。 语法：
实例：
效果如下：
for循环[练习]
Lua 编程语言中 for 循环语句可以重复执行指定语句，重复次数可在 for 语句中控制。
语法： 1->10 1:exp1 10:exp2 2:exp3:递增的数量
var 从 exp1 变化到 exp2，每次变化以 exp3 为步长递增 var，并执行一次 "执行体"。exp3 是可选的，如果不指定，默认为1。
例子：
for i=1,9,2 :i=1从1开始循环，9循环数据到9结束，2每次递增2
repeat...until语句[满足条件结束][练习]
Lua 编程语言中 repeat...until 循环语句不同于 for 和 while循环，for 和 while 循环的条件语句在当前循环执行开始时判断，而 repeat...until 循环的条件语句在当前循环结束后判断。
语法：
案例：
函数
lua中也可以定义函数，类似于java中的方法。例如：
执行之后的结果：
..:表示拼接
表
table 是 Lua 的一种数据结构用来帮助我们创建不同的数据类型，如：数组、字典等。
Lua也是通过table来解决模块（module）、包（package）和对象（Object）的。
案例：
模块
(1)模块定义
模块类似于一个封装库，从 Lua 5.1 开始，Lua 加入了标准的模块管理机制，可以把一些公用的代码放在一个文件里，以 API 接口的形式在其他地方调用，有利于代码的重用和降低代码耦合度。
创建一个文件叫module.lua，在module.lua中创建一个独立的模块，代码如下：
由上可知，模块的结构就是一个 table 的结构，因此可以像操作调用 table 里的元素那样来操作调用模块里的常量或函数。
上面的 func2 声明为程序块的局部变量，即表示一个私有函数，因此是不能从外部访问模块里的这个私有函数，必须通过模块里的公有函数来调用.
(2)require 函数
require 用于 引入其他的模块，类似于java中的类要引用别的类的效果。
用法：
两种都可以。
我们可以将上面定义的module模块引入使用,创建一个test_module.lua文件，代码如下：
任何项目中我们都有一些频繁的查询，而那些频繁的查询数据基本都是相同的，比如项目中查看用户个人信息，购物狂欢查询活动信息，这些功能点使用频率非常高，我们一般需要对他们做特殊处理。
我们以狂欢活动信息为例，当双十一的时候，很多人会去查看今天优惠活动有哪些，对这些活动信息我们可以采用多级缓存架构来抗住高并发。
基于Java版的缓存架构实现流程如下：
优点：
缺点：
优点：
我们以双十一活动信息加载为例，通过多级缓存架构来加载双十一活动信息，双十一活动信息表结构如下：
创建一个lua脚本 mysql.lua ，用于提供根据SQL语句执行查询操作，代码如下：
我们需要安装 lua-resty-redis-cluster ,用该依赖库实现Redis集群的操作，这里提供github地址，大家下载后按操作配置即可，下载地址： <https://github.com/cuiweixie/lua-resty-redis-cluster> ，下载该文件配置后即可实现Redis集群操作。
接下来我们实现Redis集群操作，创建一个脚本 redis.lua ，脚本中实现Redis中数据的查询和添加操作，代码如下：
配置创建Nginx缓存共享空间
创建多级缓存操作脚本 activity.lua ，代码如下：
Nginx配置：
每次在双十一或者618的时候，各大电商平台为了吸引用户，都会给与用户很大的优惠，比如送优惠券、抢红包等，抢优惠券或者红包的用户群体非常大，这时候会给服务器带来的并发也是非常大，解决这块问题，架构是关键。
双十一抢红包或者过年微信、QQ红包雨活动的并发量非常庞大，红包雨存在的规则也是非常多的，我们先来分析一下红包雨的特点。
上面我们已经分析过红包雨的特点，要想实现一套高效的红包雨系统，缓存架构是关键。我们根据红包雨的特点设计了如上图所示的红包雨缓存架构体系。
并发量非常大的系统，例如秒杀、抢红包、抢票等操作，都是存在溢出现象，比如秒杀超卖、抢红包超额、一票多单等溢出现象，如果采用数据库锁来控制溢出问题，效率非常低，在高并发场景下，很有可能直接导致数据库崩溃，因此针对高并发场景下数据溢出解决方案我们可以采用Redis缓存提升效率。
用户抢红包的时候，我们会分批次发放红包，每次发放红包会先根据发放红包的金额和红包的个数把每个红包计算好，然后存入到Redis队列中，存入到Redis队列后，用户每次抢红包都直接从Redis队列中获取一个红包即可，由于Redis是单线程，在这里可以有效的避免多个人同时抢到了一个红包，类似一种超卖现象。
表结构设计：
初始化读取
创建容器监听类 com.itheima.quartz.MoneyPushTask ，让该类实现接口 ApplicationListener ，当容器初始化完成后，会调用 onApplicationEvent 方法， 我们可以在该方法中实现初始化读取数据，将数据填充到变量中。
MoneyPushTask 代码如下：
定时加载
定时加载我们需要开
抢红包缓存队列溢出控制
上面已经实现将红包存入到Redis缓存队列中，用户每次抢红包的时候，只需要从Redis缓存队列中获取即可。com.itheima.controller.RedPacketController 代码：
com/itheima/service/RedPacketService.java 代码：
com.itheima.service.impl.RedPacketServiceImpl 代码：
用户抢红包的高并发场景下，如果让后端服务器直接处理所有抢红包操作，服务器很有可能会崩溃，就像高铁站如果很多人蜂拥挤进站而不排队，很有可能导致整个高铁站秩序混乱，高铁站服务崩溃，程序也是如此。
解决大量并发用户蜂拥而上的方法可以采用队列术将用户的请求用队列缓存起来，后端服务从队列缓存中有序消费，可以防止后端服务同时面临处理大量请求。缓存用户请求可以用RabbitMQ、Kafka、RocketMQ、ActiveMQ，我们这里采用RabbitMQ即可。
用户抢红包的时候，我们用Lua脚本实现将用户抢红包的信息以生产者角色将消息发给RabbitMQ，后端应用服务以消费者身份从RabbitMQ获取消息并抢红包，再将抢红包信息以WebSocket方式通知给用户。
如果想使用Lua识别用户令牌，我们需要引入 lua-resty-jwt 模块，是用于 ngx_lua 和 LuaJIT 的 Lua 实现库，在该模块能实现Jwt令牌生成、Jwt令牌校验，依赖库的地址： https://github.com/SkyLothar/lua-resty-jwt
lua-resty-jwt安装
在 资料\lua 中已经下载好了该依赖库 lua-resty-jwt-master.zip ,我们将该库文件上传到服务器上，并解压，当然，我们也可以使用opm直接安装 lua-resty-jwt ，配置 lua-resty-jwt 之前，我们需要先安装resty和opm。
安装仓库管理工具包：
添加仓库地址：
安装resty:
安装opm：
安装Jwt组件：
此时 lua-resty-jwt 安装好了，可以直接使用了。
令牌校验库token.lua
抢红包队列脚本:mq.lua,参考地址 <https://github.com/wingify/lua-resty-rabbitmqstomp>
抢红包队列脚本:mq.lua,参考地址 <https://github.com/wingify/lua-resty-rabbitmqstomp>
Java监听
打开资料中的 html/websocket.html ，执行抢红包测试，效果如下：
一般情况下，双十一很多查询的并发量是比较大的，即使 有了多级缓存，当用户不停的刷新页面的时候，也是没有必要的，另外如果有恶意的请求 大量达到，也会对系统造成影响。而限流就是保护措施之一。
限流和生活中很多现实场景类似，如下场景：
而程序限流，主要是控制应对高并发和恶意操作的一种技术手段。
nginx提供两种限流的方式：
控制速率的方式之一就是采用漏桶算法。
(1)漏桶算法实现控制速率限流
漏桶(Leaky Bucket)算法思路很简单,水(请求)先进入到漏桶里,漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率.示意图如下:
(2)nginx的配置
配置示如下：
创建限流缓存空间：
配置限流：
参数说明：
如果恶意一直刷新会出现如下现象：
(3)处理突发流量
上面例子限制 2r/s，如果有时正常流量突然增大，超出的请求将被拒绝，无法处理突发流量，可以结合 burst 参数使用来解决该问题。
例如，如下配置表示：
burst 译为突发、爆发，表示在超过设定的处理速率后能额外处理的请求数,当 rate=10r/s 时，将1s拆成10份，即每100ms可处理1个请求。
此处，burst=4 ，若同时有4个请求到达，Nginx 会处理第一个请求，剩余3个请求将放入队列，然后每隔500ms从队列中获取一个请求进行处理。若请求数大于4，将拒绝处理多余的请求，直接返回503.
不过，单独使用 burst 参数并不实用。假设 burst=50 ，rate依然为10r/s，排队中的50个请求虽然每100ms会处理一个，但第50个请求却需要等待 50 * 100ms即 5s，这么长的处理时间自然难以接受。
因此，burst 往往结合 nodelay 一起使用。
例如：如下配置：
如上表示：
平均每秒允许不超过2个请求，突发不超过4个请求，并且处理突发4个请求的时候，没有延迟，等到完成之后，按照正常的速率处理。
完整配置如下：
ngx_http_limit_conn_module 提供了限制连接数的能力。主要是利用limit_conn_zone和limit_conn两个指令。利用连接数限制 某一个用户的ip连接的数量来控制流量。
注意：并非所有连接都被计算在内 只有当服务器正在处理请求并且已经读取了整个请求头时，才会计算有效连接。此处忽略测试。
配置语法：
(1)配置限制固定连接数
如下，配置如下：
配置限流缓存空间：
location配置：
参数说明：
(2)限制每个客户端IP与服务器的连接数，同时限制与虚拟服务器的连接总数。
限流缓存空间配置：
location配置
每个IP限流 3个
总量5个
外！CFM-Hello语音杯团队赛开战，就在今天！16个民间大手子队要开始神仙打架了！比赛看个热闹就完事儿了，冠军那几万大奖跟咱没关系；直播间搞得抽奖活动，我等屁民还是可以去争一争滴，听说发的是现金喔！
Hello语音这次组织的比赛真是声势浩大，一个星期前250支队伍打海选，打到现在剩16支队伍争冠；这16支队伍的平民玩家不光过足了电竞的瘾，享受到比赛的刺激，还能马上在斗鱼直播里当一回明星选手，简直不要太爽！
Hello语音为这次团队赛请来了CFM官方解说西瓜丶SV，另外马上开打的个人赛请到官方解说朗大朝；都是官方解说界的大红人了，有这俩专业解说，观赛体验都上了一个档次了，这民间赛的办赛规格怕是跟官方专业比赛有一拼噢！
（团队赛解说西瓜丶SV直播地址：https://www.douyu.com/5961790）
（个人赛解说朗大朝直播地址：https://www.douyu.com/6368510）
比赛相关的事简单说下吧，4月8号16强赛正式开打，打到18号决冠军，基本是晚上7点开打，具体的比赛信息hello语音里都有，要了解的朋友自己去看；这次冠军奖金达到15000，总奖金也有40000，前8都有钱，搞得我都想组队参加下一届比赛了！
（团队赛奖励）
（官方地址：https://hstatic.ppx520.com/front/online/project/HYC-CFM/index.html）
另外，直播间有抽奖的事儿已经是板上钉钉了，听说下现金红包雨和贵重的游戏道具；我估摸着不光是OB间隙的常规抽奖，比如高光击杀、选手采访啥的也会来个突击抽奖；所以各位观众老爷别怪我没提醒，好好守着比赛时间吧，搞不好准点开播先来一手抽奖！
路人朋友的观赛指南就这些了，下面聊聊圈内人的事儿，有兴趣的朋友可以继续阅读。Hello语音这个比赛从海选到现在也打了一个星期了，讲道理精彩程度还真不输职业比赛；现金奖励多的好处就是选手都特认真，而打出的高光操作都来自我们身边的普通人，这种观赛代入感远比看职业比赛要强的多；说不定下一届我们也能成为赛事的其中一员，去追逐属于自己的电竞梦！
随着公司业务的不断扩张，用户流量在不断提升，研发体系的规模和复杂性也随之增加。线上服务的稳定性也越来越重要，服务性能问题，以及容量问题也越发明显。
因此有必要搭建一个有效压测系统，提供安全、高效、真实的线上全链路压测服务，为线上服务保驾护航。
关于全链路压测的建设，业界已经有了非常多文章，但是涉及到具体的技术实现方面，却很少介绍。本文想从全链路压测系统，从设计到落地整个实践过程，来详细介绍下全链路压测系统是具体是如何设计，以及如何落地的。希望能从技术落地实践的角度，给同行业的同学一些参考和启发。
全链路压测在业内已经有了广泛的实践，如阿里的 Amazon、PTS[1][2]，美团的 Quake[3][4]，京东的的 ForceBOT[5]，高德的 TestPG[6]等等，都为我们提供丰富的实践经验，和大量优秀的技术方案。我们广泛吸收了各大互联网公司的全链路压测建设经验，并基于字节跳动业务需求，设计开发了一个全链路压测系统 Rhino。
Rhino 平台作为公司级的全链路压测平台，它的目标是对全公司所有业务，提供单服务、全链路，安全可靠、真实、高效的压测，来帮助业务高效便捷的完成性能测试任务，更精确评估线上服务性能&容量方面风险。
因此在 Rhino 平台设计之初，我们就定下以下目标：
Rhino 是一个分布式全链路压测系统，可以通过水平扩展，来实现模拟海量用户真实的业务操作场景，对线上各种业务进行全方位的性能测试。它主要分为控制中心(Rhino Master)模块，压测链路服务模块，监控系统模块，压测引擎模块，如图。（每一个模块都是由多个微服务来完成的。如下图每个实线图都代表一个微服务或多个微服务）。
压测过程中数据构造是最重要，也是最为复杂的环节。压测数据的建模，直接影响了压测结果的准确性。
为了高效的构造特定的 Fake 压测数据，Rhino 压测平台提供大量数据构造方式：
在压测过程中，有些压测请求需要进行登录，并保持会话；此外在很多压测请求中涉及到用户账号信息 UserID，DeviceID 等数据。用户账号的构造问题，一直是压测过程中非常棘手的问题。Rhino 平台打通的用户中心，设置了压测专属的账号服务，完美地解决了压测过程中的登录态，以及测试账号等问题。具体流程和使用界面，如下图。
压测隔离中需要解决的压测流量隔离，以及压测数据的隔离。
压测流量隔离，主要是通过构建压测环境来解决，如线下压测环境，或泳道化/Set 化建设，将压测流量与线上流程完全隔离。优点是压测流量与线上流量完全隔离，不会影响到线上用户。缺点：机器资源及维护成本高，且压测结果需要经过一定的换算，才能得线上容量，结果准确性存在一定的问题。目前公司内压测都是在线上集群上完成的，线上泳道化正在建设中。
压测数据隔离，主要是通过对压测流量进行染色，让线上服务能识别哪些是压测流量，哪些是正常流量，然后对压测流量进行特殊处理，以达到数据隔离的目的。目前 Rhino 平台整体压测隔离框架如图。
压测标记就是最常见的压测流量染色的方式。
目前公司内各个基础组件、存储组件，以及 RPC 框架都已经支持了压测标记的透传。其原理是将压测标记的 KV 值存入 Context 中，然后在所有下游请求中都带上该 Context，下游服务可以根据 Context 中压测标记完成对压测流量的处理。在实际业务中，代码改造也非常简单，只需要透传 Context 即可。
Golang 服务： 将压测标记写入 Context 中。
Python 服务：利用 threading.local()存储线程 Context。
Java 服务：利用 ThreadLocal 存储线程 Context。
为了解决线上压测安全问题，我们还引入了压测开关组件。
线上压测中，最复杂的问题就是压测链路中涉及到写操作，如何避免污染线上数据，并且能保证压测请求保持和线上相同的请求路径。业界有很多解决方案，常见的有影子表，影子库，以及数据偏移，如图[7]。
Rhino 平台针对不同存储，有不同的解决方案：
在压测之前，需要对服务进行压测验证。对于不满足压测要求(即压测数据隔离)的服务，需要进行压测改造。
a. 尽量减少代码改动，并给出完整的指导手册及代码示例，减少 RD 的工作量，降低代码错误的可能性
b. 提供简单便捷的线上线下 HTTP&RPC 的压测请求 Debug 工具，方便代码改动的验证
c. 对于新项目，在项目开始初期，就将压测改造加入项目开发规范中，减少后期的代码改动
请求调用链，对于线上压测是非常重要的：
Rhino 平台通过公司的流式日志系统来完成调用链检索的。一个服务在被请求或者请求下游时，都会透传一个 LogID。RPC 框架会打印调用链日志（包括 RPC 日志-调用者日志，Access 日志-被调用者日志），所有日志中都会包含这个 LogID。通过 LogID 将一个请求所经过的所有服务日志串起来，就完成调用链检索。
Rhino 平台在公司流式日志系统提供的链路梳理功能基础上，进行了进一步优化，以满足压测需要：
虽然 Rhino 平台对于压测有很多的安全保障措施，但是对于大型压测，保证信息的通畅流通也是非常重要的。因此在压测周知方面，Rhino 平台也提供了很多解决方案：
在压测之前，需要开启整体链路的压测开关的，否则压测流量就会被服务拒绝，导致压测失败。
对于调用链中不能压测的服务(敏感服务)，或者第三方服务，为了压测请求的完整性，就需要对这些服务进行 Mock。业界通用的 Mock 方案有：
由于字节整个公司都采用微服务架构，导致一次压测涉及链路都比较长，快速无业务入侵的 Mock
方式成为了首选。Rhino 平台是通过公司 Service Mesh 和 ByteMock 系统来实现了高效的，对业务透明的服务 Mock。
压测执行前，Rhino 平台需要向 Service Mesh 注册染色转发规则，并向 Mock 服务注册 Mock 规则。然后在压测流量中注入 Mock 染色标记，才能完成服务 Mock：
Rhino 平台中，压测 Agent 就是一个最小调度单元。一次压测任务，通常会拆分成多个子 Job，然后下发到多个 Agent 上来完成。
2020 年春节抢红包压测中，Rhino 临时扩容在 4000+个实例，支撑了单次 3kw+QPS 的压测，但日常 Rhino 平台只部署了 100+个实例，就能满足日常压测需求。
Rhino 平台默认将全链路压测分为公网压测和内网压测。公网压测主要 IDC 网络带宽，延时，IDC 网关新建连接、转发等能力；内网压测，主要是压测目标服务，目标集群的 性能，容量等。
Rhino 平台在各个 IDC 都有部署 Agent 集群。各个 IDC 内服务的压测，默认会就近选择压测 Agent，来减少网络延时对压测结果的干扰，使得压测结果更精准，压测问题定位更简单。
除了多机房部署之外，Rhino 平台还在边缘计算节点上也部署了压测 Agent，来模拟各种不同地域不同运营商的流量请求，确保流量来源，流量分布更贴近真实情况。在 Rhino 平台上可以选择不同地域不同运营商，从全国各个地区发起压测流量。
为了应对线上压测风险，Rhino 平台提供两种熔断方式，来应对压测过程中的突发事件，来降低对线上服务造成的影响。
每个压测任务，都可以关联调用链中任意服务的告警规则。在压测任务执行过程，Rhino 平台会主动监听告警服务。 当调用链中有服务出现了告警，会立即停止压测。对于没有关联的告警，Rhino 平台也会记录下来，便于压测问题定位。
自定义监控指标及阈值，到达阈值后，也会自动停止压测。目前支持 CPU、Memory、 上游稳定性、错误日志，以及其他自定义指标。
此外，除了 Rhino 平台自身提供的熔断机制以外，公司服务治理架构也提供了很多额外的熔断机制，如压测开关，一键切断压测流量；过载保护，服务过载时自动丢弃压测流量。
对于 HTTP 协议，参考了 Postman，全部可视化操作，保证所有人都能上手操作，极大降低了压测的使用门槛和成本。
对于 RPC 任务，Rhino 也自动完成了对 IDL 的解析，然后转换成 JSON 格式，便于用户参数化处理。
对于非 HTTP/RPC 的协议，以及有复杂逻辑的压测任务，Rhino 平台也提供了完善的解决方案——Go Plugin。
Go Plugin 提供了一种方式，通过在主程序和共享库直接定义一系列的约定或者接口，就可以动态加载其他人编译的 Go 语言共享对象，使得主程序可以在编译后动态加载共享库，实现热插拔的插件系统。此外主程序和共享库的开发者不需要共享代码，只要双方的约定不变，修改共享库后也不再需要重新编译主程序。
用户只要根据规范要求，实现一段发压业务逻辑代码即可。Rhino 平台可以自动拉取代码，触发编译。并将编译后的插件 SO 文件分发到多个压测 Agent。 Agent 动态加载 SO 文件，并发运行起来，就可以达到压测的目的。此外，Rhino 还针对常见 Go Plugin 压测场景，建立了压测代码示例代码库。对于压测新手，简单修改下业务逻辑代码，就可以完成压测了。这样就解决了非常见协议，以及复杂压测场景等的压测问题。
压测调度的最小单元是压测 Agent，但是实际每个 Agent 中有挂载多种压测引擎的，来支撑不同的压测场景。Rhino 平台在压测数据和压测引擎之间增加了一个压测引擎适配层，实现了压测数据与压测引擎的解耦。压测引擎适配层，会根据选择不同的压测引擎，生成不同 Schema 的压测数据，启用不同的引擎来完成压测，而这些对用户是透明的。
在压测引擎上，我们有开源的压测引擎，也有自研的压测引擎。
开源压测引擎的优点是维护人多，功能比较丰富，稳定且性能好，缺点就是输入格式固定，定制难度大。此外 Agent 与开源压测引擎之间通常是不同进程，进程通信也存在比较大的问题，不容易控制。
自研压测引擎，优点是和 Agent 通常运行在单进程内，比较容易控制；缺点可能就是性能稍微差一些。但是 Golang 天然支持高并发，因此自研和开源之间的性能差距并不明显。
由于公司监控系统，最小时间粒度是 30s，30s 内的数据会聚合成一个点。这个时间粒度对于压测来说是比较难以接受的。因此，Rhino 平台自己搭建了一套客户端监控系统。
服务端监控，直接接入了公司 Metric 系统。
在压测过程中，Rhino 平台还可以实时采集目标服务进程的性能 Profile，并通过火焰图的方式展示出来，方便用户进行性能问题分析和优化，如图。
Rhino 压测平台是一个面向全字节跳动公司的，为了所有研发同学提供的一站式全链路压测的平台。Rhino 平台的研发团队，不仅负责 Rhino 平台的研发任务，还会配合 QA&RD 来完成公司大型项目，重点业务的性能压测工作。
公司内重大项目的压测，Rhino 平台都会积极参与，全力支撑的。其中，比较典型的项目有抖音春晚，西瓜百万英雄，春节红包雨等活动。
其中字节春节红包雨活动，完成是由 Rhino 团队来负责和完成的。字节春节红包雨活动是在春节期间，所有字节客户端发起的，诸如抽卡分现金，红包锦鲤，红包雨等一系列的超大规模的红包引流活动。其流量规模巨大，流量突发性强，业务逻辑和网络架构复杂度高等等，都对 Rhino 平台提出不小的挑战。
在春节红包雨活动中，所有用户流量都经过运营商专线接入到网络边缘的汇聚机房，然后经过过滤和验证后，再转发到核心机房。其中各个 IDC 互为备份，其具体流量路线如图。在这里，不仅要验证后端各服务是否能承载预期流程，还要验证各个专线带宽，各个网关带宽及转发能力，各 IDC 承载能力以及之间带宽等等。
为此，我们将整个压测拆分成多个阶段，来简化压测复杂性，也降低压测问题定位的难度：
在这些大型项目的支撑中，Rhino 团队不仅学到了大量的业务和架构设计知识，还了解到业务研发同学如何看待压测，如何使用平台，帮助我们发现更多平台的问题，促进平台不断迭代优化。
日常压测支撑，也是 Rhino 平台非常重要的一项任务。对于日常压测中遇到的各种问题，我们采用了各种方案来解决：
Rhino 平台还实现了线上流量的定期调度，以达到线上实例自动压测的目的[8]：
其具体实现方案如下：
目前已经有 500+微服务接入，每天定时执行流量调度，来监控线上服务性能变化趋势，如下图。
Rhino 平台目前还在公司内推行常态化压测，通过周期定时化的自动化全链路压测，来实现以下目标：
目前 Rhino 平台上的常态化压测，会周期定时，以无人值守的方式，自动执行压测任务，并推送压测结果。在压测执行过程中，会根据调用链自动完成压测开关开启，发起压测流量。实时监控服务性能指标，并根据 Metric 及告警监控，自动完成压测熔断，以保证压测安全。
目前已经有多个业务方接入常态化压测，以此保证线上服务的稳定性。
服务在上线时，都会经过预发布，线上小流量灰度，线上全量发布。在这个过程中，我们可以通过线上测试 Case 以及灰度发布，来拦截服务线上功能缺陷。但是对于性能缺陷的拦截，却不够有效。
从线上故障跟踪系统里就可以发现，由于上线前没有做好性能压测，很多性能缺陷都逃逸到了线上。
为了拦截各种性能缺陷，Rhino 平台完成了 DevOps 平台的打通。将压测服务在 DevOps 平台上注册成一个原子服务 ，研发人员可以将压测节点编排在任意流水线的任意位置，实现上线前的例行压测。DevOps 流水线中的压测，不仅可以帮助 RD 发现代码中的性能问题，还能与性能基线进行 Diff，来发现代码性能变坏的味道。
Rhino 压测平台从立项到现在，不到两年的时间内，其发展已经初具规模，如图（每月压测执行统计）。这个期间，非常非常感谢公司内所有合作团队，尤其是架构团队，中台团队对压测平台的支撑，没有他们的支撑，全链路压测建设是难以完成的。
通用压测平台已经初步搭建完成，基本上能满足业务线日常压测需求。但在日常压测支撑过程中，发现不同业务线在压测时，但是仍然有大量的前置和后继工作需要人工来完成。
如何更进一步降低业务方压测改造的成本，如何减少压测环境数据预置成本，如何快速完成压测数据清理，如何快速定位出性能问题等等，Rhino 压测平台后续将更进一步深入业务，与各大业务方开展更深入的合作，提供更深度的业务定制，为研发提效，助力业务线发展。
业务目前资源是否充足，其具体容量是多少；按照目前业务增长，其机器资源还能支撑多久？
目前服务资源利用如何，是否可以优化，如何更进一步提升资源利用率，降低机器资源成本？
某大型活动，需要申请多少资源？是否不需要压测，或者自动化利用线上流量数据，或者利用日常压测数据，就可以给出上述问题的结论？
如何保证服务稳定性，如何监控服务性能劣化并及时预警，限流、超时、重试以及熔断等服务治理措施配置是否合理？以及如何配合混沌测试进行容灾演练，保证服务稳定性等等，这些 Rhino 平台都会做更进一步探索。
目前 Rhino 团队还非常小，非常缺少性能测试以及后端开发相关的研发工程师，欢迎感兴趣的同学来加入。简历投递邮箱： tech@bytedance.com ；邮件标题： 姓名 - 工作年限 - Rhino 。
[1] http://jm.taobao.org/2017/03/30/20170330/
[2] https://testerhome.com/topics/19493
[3] https://tech.meituan.com/2018/09/27/quake-introduction.html
[4] https://tech.meituan.com/2019/02/14/full-link-pressure-test-automation.html
[5] https://www.open-open.com/lib/view/open1484317425690.html
[6] https://www.infoq.cn/article/NvfJekpvU154pwlsCTLW
[7] https://tech.bytedance.net/articles/3199
[8] https://www.usenix.org/conference/osdi16/technical-sessions/presentation/veeraraghavan
Fastbot：行进中的智能 Monkey
品质优化 - 图文详情页秒开实践
Android Camera 内存问题剖析
字节跳动自研线上引流回放系统的架构演进
欢迎关注「字节跳动技术团队」
*请认真填写需求信息，我们会在24小时内与您取得联系。
