RPC：流量回放，保障业务技术升级的神器

什么是流量回放？

• 就是某个时间段内的所有请求，我们通过某种手段把发送到A应用的所有请求录制下来，然后把这些请求同一转发到B应用，让B应用接收到的请求参数跟A应用保持一致，从而实现A接收到的请求在B应用里面重新请求了以便。
• 这就好比今晚有场球赛，但我没空看，但我可以利用视频录播技术把球赛录下来，我随时想看都可以拿出来看，画面是一模一样的。

流量回放可以做什么？

• 在团队中，我们经常是多个需求并行开发的，在开发新需求的过程中，我们还可能夹杂着应用的重构和拆分。每到这个时候，我们基本很难做到不改动老逻辑，那只要有改动就有可能会存在考虑不周全的情况。如果你比较严谨的话，那可能在开发完成后，你会把项目里面的TestCase 都跑一遍，并同时补充新功能的 TestCase，只有所有的 TestCase 都跑通后才能安心。
• 在代码里面，小改动的业务需求，这种做法一般不会出问题。但对于大改动的应用，比如应用中很多的基础逻辑都被改动过，这时候如果你还是通过已有的Case去验证功能的正确性，就很难保证应用上线后不出故障了，比如我们靠自己维护的Case相对线上运行的真实环境来说还是少了很多。
• 这时候我们会向更专业的 QA 测试人员求助，希望他们能从 QA 角度多加入一些 Case。但因为我们改动代码逻辑影响范围比较大，想要圈定一个比较确定的测试范围又很难，坦白讲这时候相对保险的方式就是 QA 把整个项目都回归测试一遍。这种方式已经是在最大程度上避免上线出问题了，但从概率角度上来讲也不是万无一失的，因为线上不仅环境复杂，而且使用场景也并不好评估，还有就是这种方式耗时也很长。

靠传统的QA测试的方案，不仅过程费时，结果也不是完全可靠。那有没有更可靠、更廉价的方案呢？

• 传统的QA测试出问题的根本原因是，因为改造后的应用在上线后跟应用上线前不一致的行为，而我们测试的目的就是为了保证改造后的应用跟改造前的行为一致，我们测试的Case也都是在尽力模拟应用在线上的运行行为，但仅通过我们自己的枚举方式维护的Case 并不能代表线上应用的所有行为。因此最好的方式就是用线上流量来验证，但是直接上线新应用肯定是不行的，因为一旦新改造的应用存在问题就可能导致线上调用方业务受损。
• 我们可以换一种思路，先把线上一段时间内的请求参数和响应结果保存下来，然后把这些请求参数在新改造后的应用里重新请求以便，最后比对一下改造前后的响应结果是否一致，这就间接达到了使用线上流量测试的效果。有了线上的请求参数和响应结果后，我们再结合持续集成过程，就可以让我们改动后的代码随时用线上流量进行验证

流量回放功能应该还可以用来恢复数据，比如一段时间的数据由于某种原因丢失了，那我们就应该用流量回放功能恢复这段时间的数据，当然要求接口是幂等的，否则会导致错误数据。

RPC怎么支持流量回放

那实际工作中农，我们该怎么实现流量回放呢？

我们常见的方案有很多，比如像TcpCopy、Nginx等。但在线上环境中要使用这些工具的时候，我们还需要找运维帮我们把应用安装到应用实例中，然后按照你的需求给配置好才能使用，整个过程繁琐而且总数重复做无用功，那有没有更好的办法呢？尤其是在应用使用了 RPC 的情况下。

我们知道，RPC是用来完成应用之间通信的，换句话就是说应用之间的所有请求响应都会经过RPC。

既然所有的请求都会经过RPC，那么我们在RPC里面是不是就可以很方便的拿到每次请求的出入参数？拿到这些出入参数后，我们只需要把这些出入参数旁路下来，并把这些旁路结果用异步的方式发送到一个固定的地方保存起来，这样就完成了流量回放的录制功能。

有了真实的请求入参之后，剩下的就是怎么把这些请求参数转发到我们要回归测试的应用里面。在RPC中，我们把能够接收请求的应用叫做服务提供方，也就是说，我们只需要模拟一个应用调用方，把刚刚接收到的请求参数重新发送一遍到要回归测试的应用里面，然后比对录制拿到的请求结果和新请求的结果，就可以完成请求回放