随着持续集成、持续交付等理念的普及，很多软件开发团队都搭建了自己的staging、UAT等生产环境。这些环境的软件、硬件和网络配置将尽可能接近真实的生产环境，起到沙盘演练的作用。毕竟班级生产环境前面有个班级字，沙盘毕竟不是真正的战场，越接近越好，毕竟不是完全一致的。准生产环境和真实生产环境的一个重要区别就是访问次数。一个稍大规模的互联网应用每天访问数百万是正常的，而准生产环境的访问量一般相形见绌。有多种工具可以弥合这种差异，例如ApacheJMeter、Gatling。测试人员可以与开发人员一起设计测试用例，并以自动化或半自动化的方式对类生产环境进行压力测试。但即使精心设计的用例仍然是用例，而不是真正的请求。真实的请求是多种多样的，会随着昼夜的交替而变化，会随着时事的变化而波动，很难用工具来模拟。这就引出了本文的主角——影子流量。简而言之，影子流量就是将发送到生产环境的请求复制转发到类生产环境，从而达到压力测试和正确性测试的目的。这就好比把真实战场上的敌方炮火放到了演练场中。1.实现方式Shadow流量通常有两种实现方式：服务端实现和客户端实现。下图描绘了服务器端实现的简化示例。生产环境接收来自用户或上游系统的请求，在响应请求的同时，将请求原封不动地发送给类生产环境。下图描述了客户端的实现。当客户端设备或上游系统向生产环境发送请求时，它也会向类生产环境发送相同的请求。这两种实现方式各有优缺点。将它们放在服务器端可以减少客户端设备的流量消耗，这对于移动应用来说非常重要。客户端的实现比较简单，通常只需要几行代码。如果后端架构复杂，可以选择前端实现。无论前端还是后端实现，都要遵循即发即弃的原则，以免阻塞正常进程或增加响应时间。1.适用场景一般来说，影子流量可以适用于所有的互联网应用。在以下场景中，影子流量的作用尤为明显：以新系统替换旧系统系统进行大规模改造，系统更新直接上线，面对高风险客户，以及需要提供一个向后兼容的实验架构调整上述场景下影子流量的使用，可以在不影响终端用户的情况下完成验证和测试。2、开通时机在上线前集中测试一段时间固然是可行的方式，但我个人更倾向于在项目运营初期引入影子流量。这样做可以让开发团队尽早并持续地暴露在真实的外部压力中。相当于用成本不是很高的方式组建一支有产品运维经验的开发团队。2.支撑机制Shadowtraffic的原理和实现并不高深，但要发挥其应有的价值还需要一些前期工作。1.基础设施监控要了解系统的性能，基础设施监控必不可少。上图是我体验过的一个项目的可视化监控界面。监控范围包括docker容器数量、请求数量、响应时间、4或5开头的HTTP状态码数量、网络、内存、CPU使用率等。通过上面的可视化图表，开发团队可以得到反馈即时的。2.日志基础设施监控可以提供一个外部视角，日志可以窥视应用内部。日志可以帮助开发团队定位影子流量中发现的问题，影子流量也可以提示开发团队提高日志质量。两者可以起到双向的积极促进作用。3.下游系统的协调如果一个系统开放了影子流量，可以想象其下游系统所面临的压力也会急剧上升。这时候需要提前和负责下游系统的团队沟通。3.使用变体影子流量不是静态的技术实践，可以根据需要进行微调。1.Requestpicking不是每个request都需要转发。可以优先处理具有高流量或高商业价值的请求。2.流量控制如果要做极压测试，可以将每个请求多次发送到类生产环境。当然也可以只挑10%的请求发到类生产环境，随着团队信心的提升逐渐增加。3、重放可以在每天高峰时间截取并保存请求，在其他时间段重复重放。这种考验可以有效锻炼团队的心理素质，促使团队形成应急预案。4.总结如果明天上线，今天将是不安的一天。系统性能如何？会不会有奇怪的用户行为导致系统异常？与上下游系统的连接会不会有问题？这些问题的答案都可以通过测试人员的仔细模拟找到。但还是难免会出现泄密的情况。启用影子流量，如果开发团队能习惯影子流量的日常生活，就有能力应对线上运维问题。【本文为专栏作者“ThoughtWorks”原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
