流量回放－The Big Picture

分享一个大牛的人工智能教程。零基础！通俗易懂！风趣幽默！希望你也加入到人工智能的队伍中来！请轻击人工智能教程

一、大背景是什么

微服务架构的同时，服务自身依赖的第三方服务、数据越来越多。

传统的自测/测试方式面临困难

1. 被依赖的线下服务不稳定；
2. 服务无法提供期望的响应数据；
3. 缺少场景构造标准；

传统的解决方式

1. 提高环境稳定性：服务不稳定的情况仍无法避免；
2. 自己构造数据、改代码注入object：繁杂；
3. 想当然的构造场景：场景构造不充分、心里没底；

上述问题导致了代码质量下降、自测/测试困难，在业务越来越复杂，依赖服务越来越多的大环境下，这些问题变得越加严重，已经到了必须要升级解决方案的地步。

二、The big picture

托管被测服务，利用线上流量来测试。

• 服务托管：

服务被托管，其外部依赖被mock，程序的运行环境不再依赖第三方服务，解决环境的不稳定问题；

被托管的服务被提前录制的线上流量测试，第三方依赖也由线上流量mock，解决第三方响应数据难构造、缺少场景构造标准的问题；

• 线上流量：

线上流量被提前录制，请求和对应的第三方交互数据也被正确group起来。

三、技术方案

1、服务托管

• 利用iptables进行托管

利用iptables在系统层面对服务进行托管，服务所有的第三方交互被iptables拦截后mock；好处是通用，对服务的语言无要求，坏处是只能托管网络流量。

• 利用libc、程序网络库等托管

通过hook掉libc中的connect\send\rcv等函数对服务进行托管。好处是可托管网络流量外的如文件读取类流量，坏处是不同的语言hook的方式需要定制，如php用libc方式，go需要修改语言库。

同时，我们会hook掉系统时间调用，让被托管服务回到线上流量的时间。

2、线上流量录制

线上流量，包含服务的请求流量及第三方交互流量。仅有服务的请求流量是不够的，同时，其第三方交互需要被正确的和请求关联，这里要解决的难题是如何在网络层缺少关联id（traceid在应用层，且redis/mysql数据缺少traceid）的情况下，正确的关联请求及其第三方交互。

• 利用时间gap来关联

将一台线上机器服务的请求串行化，请求之间加上一个时间gap，则两个请求之间的第三方交互可以和这个请求正确关联。

好处是通用，不区分程序语言，代码侵入性小；坏处是会增加一些运维成本和机器资源；对于不同协议的服务需要定制不同的串行方案，如http采用nginx+lua，thrift采用服务内转发。

• 利用threadid 来关联

通过hook掉libc中的connect\send\rcv等函数，将相同threadid的流量进行关联。

好处是可以做到并行，录制速度快，case丰富，无资源浪费，对部署架构无影响；坏处是对服务的处理模型有要求，适用于请求、第三方交互都处于同一线程的处理模型，目前在php-fpm处理模型中应用得较好。