從入門到上癮，滴滴開源的 RDebug 讓人慾罷不能

點選上方“業餘草”，選擇“置頂公眾號”

第一時間獲取技術乾貨和業界資訊！

 

滴滴這家公司，不管它每年所說的虧了多少？賠了多少？也不管它到底有沒有方便我們出行？我們只討論它開源的幾個強悍的產品對我們開發的幫助和影響。

我不知道，大家還記得我前段時間所說的滴滴變色龍產品。《滴滴重磅開源 Chameleon(變色龍)讓各種小程式一鍋端！》，以及滴滴對員工的敬愛《滴滴員工竟然被裁出了幸福感》。滴滴的企業文化可能受阿里的影響比較深，畢竟滴滴的程維是從阿里出來的，價值觀還是有的。

最近，我看到了滴滴新開源的 Rdebug，非常震撼人心！

Rdebug 是滴滴開源的一款用於 RD 研發、自測、除錯的實用工具，可以被用來提升 RD 研發效率、保障程式碼質量進而減少線上事故。

背景

鑑於微服務具有易於擴充套件、部署簡單、技術異構性等優點，越來越多的服務都在採用微服務的架構模式。一個複雜的單體服務通常會被拆分成多個小的微服務，當然在享受微服務帶來的一系列便利的同時也要接受因為微服務改造帶來的問題：需要維護的服務數變多、服務之間 RPC 呼叫次數增加……

在服務化改造完成之後，原來的單體服務演化成一堆微服務，這就造成線下開發測試環境維護成本大大增加，其次線下環境涉及到的部門較多，維護一個長期穩定的線下環境也是一個挑戰；業務快速發展、需求不斷迭代，手寫單測又因複雜的業務邏輯以及複雜的服務呼叫需要 mock 多個下游服務，導致手寫單測成本特別的高；手動構造資料，又不夠全面真實。以上問題都嚴重影響 RD 的研發效率，並且增加線上發生事故的隱患。

我們固執地相信這個行業需要一場變革。

宗旨

提升研發效率、降低測試成本、縮短產品研發週期，保障程式碼質量、減少線上事故。

適用場景

適用於對已有介面進行程式碼重構、功能升級，且該介面已經有錄製的流量。

不適合新開發的介面 或 未進行流量錄製的介面。

支援新介面的方案在調研中。

技術方案

因為我們需要使用線上的真實流量來進行線下的回放測試，所以我們需要將線上的真實流量儲存下來，然後將儲存的真實流量線上下環境進行回放一遍。故 Rdebug 的核心技術方案就是 流量錄製和流量回放。

流量錄製: 即錄製線上服務的真實請求，包括呼叫下游服務的 RPC 請求。流量錄製的難點在於如何將上下游請求以及每次 RPC 的請求/響應一一對應。

流量回放: 即用線上錄製的流量，對線下測試程式碼進行回放，通過流量匹配 mock 掉下游 RPC 請求。因此，流量回放的難點在於請求的攔截和匹配。

整體架構圖

看完這個架構圖就知道，Rdebug 的核心是，它能夠將正式生產環境中的請求資料，請求流量給儲存下來。也就是 Rdebug 的流量錄製功能。

流量錄製完了之後，copy 到測試環境，或線上的映象環境中進行流量回放。這就相當於，將線上的真實流量自動的轉發的測試環境等。實際的測試，debug 就相當於線上上除錯一樣。

這就相當於，開發人員有一個 Buff 夾持，開了掛一樣可以對線上環境程式碼進行 debug。

這個功能如果你用到你們公司，真的會上癮啊，欲罷不能。想想你以前，苦逼的查日誌，本地是好的，線上是有問題的。現在有了它，基本能做到，本地就是線上，線上就是本地！

原文連結：https://www.xttblog.com/?p=3978

10T技術資源大放送！包括但不限於：C/C++，Linux，Python，Java，PHP，人工智慧，GO等等。在公眾號內回覆對應關鍵字或框架名字，即可免費獲取！！

 你再主動一點點   我們就有故事了