从入门到上瘾，滴滴开源的 RDebug 让人欲罢不能
滴滴这家公司，不管它每年所说的亏了多少？赔了多少？也不管它到底有没有方便我们出行？我们只讨论它开源的几个强悍的产品对我们开发的帮助和影响。
最近，我看到了滴滴新开源的 Rdebug，非常震撼人心！
Rdebug 是滴滴开源的一款用于 RD 研发、自测、调试的实用工具，可以被用来提升 RD 研发效率、保障代码质量进而减少线上事故。
背景
鉴于微服务具有易于扩展、部署简单、技术异构性等优点，越来越多的服务都在采用微服务的架构模式。一个复杂的单体服务通常会被拆分成多个小的微服务，当然在享受微服务带来的一系列便利的同时也要接受因为微服务改造带来的问题：需要维护的服务数变多、服务之间 RPC 调用次数增加……
在服务化改造完成之后，原来的单体服务演化成一堆微服务，这就造成线下开发测试环境维护成本大大增加，其次线下环境涉及到的部门较多，维护一个长期稳定的线下环境也是一个挑战；业务快速发展、需求不断迭代，手写单测又因复杂的业务逻辑以及复杂的服务调用需要 mock 多个下游服务，导致手写单测成本特别的高；手动构造数据，又不够全面真实。以上问题都严重影响 RD 的研发效率，并且增加线上发生事故的隐患。
我们固执地相信这个行业需要一场变革。
宗旨
提升研发效率、降低测试成本、缩短产品研发周期，保障代码质量、减少线上事故。
适用场景
适用于对已有接口进行代码重构、功能升级，且该接口已经有录制的流量。
不适合新开发的接口 或 未进行流量录制的接口。
支持新接口的方案在调研中。
技术方案
因为我们需要使用线上的真实流量来进行线下的回放测试，所以我们需要将线上的真实流量保存下来，然后将保存的真实流量在线下环境进行回放一遍。故 Rdebug 的核心技术方案就是 流量录制和流量回放。
流量录制: 即录制线上服务的真实请求，包括调用下游服务的 RPC 请求。流量录制的难点在于如何将上下游请求以及每次 RPC 的请求/响应一一对应。
流量回放: 即用线上录制的流量，对线下测试代码进行回放，通过流量匹配 mock 掉下游 RPC 请求。因此，流量回放的难点在于请求的拦截和匹配。
整体架构图
看完这个架构图就知道，Rdebug 的核心是，它能够将正式生产环境中的请求数据，请求流量给保存下来。也就是 Rdebug 的流量录制功能。
流量录制完了之后，copy 到测试环境，或线上的镜像环境中进行流量回放。这就相当于，将线上的真实流量自动的转发的测试环境等。实际的测试，debug 就相当于在线上调试一样。
这就相当于，开发人员有一个 Buff 夹持，开了挂一样可以对线上环境代码进行 debug。
这个功能如果你用到你们公司，真的会上瘾啊，欲罢不能。想想你以前，苦逼的查日志，本地是好的，线上是有问题的。现在有了它，基本能做到，本地就是线上，线上就是本地！