作者簡介

劉曉攀，攜程酒店性能測試負責人，專注性能測試分析和輔助測試工具的開發。

一、前言

Mock在整個軟件開發測試周期中已經非常普遍，我們也會經常有意無意地使用它。譬如開發了一段代碼，這段代碼強依賴了其他服務，在對方服務完成之前，肯定是期望代碼能夠同步開發。那么在開發的過程中一定會根據約定固定對方服務的返回，這種在代碼中的模擬行為，是一種mock。

另外當前很多應用為了提高性能，普遍采用cache的方式。有些cache數據是需要很多database的數據經過一定的邏輯運算得到的，而在測試過程中，為了快速驗證測試場景，直接取修改cache數據的方式，也是一種mock。

在當前五花八門的mock方式中，我們希望有一種方便快捷的mock方式，便于開發測試使用，特別是對于多依賴、多變化的場景，更需要mock的協助。否則將需要打通一系列的外部依賴來滿足一個場景的需要。

于是，我們推出了mock全鏈路。mock全鏈路既是一種mock方式，又是mock在不同階段的擴展使用。當然 mock全鏈路還面臨著一些些問題，我們將在后面的章節中詳細展開。

二、技術背景

技術的進步更多源于底層技術，比如正是由于蒸汽機的發明，才有了現在各式各樣的機動車，挖土機，收割機等等，工業上各種技術也有了不同形式的發展。同理，酒店mock也是伴隨著基礎架構、日志系統的更新換代而不斷發展。

mock全鏈路就是在框架能夠完整跟蹤應用調用鏈，指定header在鏈路上無限透傳，ES日志系統大范圍應用的背景下產生的 。當然不管mock怎么變化，最基礎的原理還是建立在常規mock的基礎上的（如圖1）。

圖1 常規mock示意圖

首先在多依賴的應用中，特別是強依賴服務的業務邏輯比較復雜，依賴服務所在的組還有一堆任務的情況下，通過構造打通依賴服務的行為會變得非常耗時。嚴重的時候，會拖累整個項目的進度。

ES在公司的大規模應用，為我們解決此類問題提供了契機。ES的埋點數據為mock提供了很好的種子。框架的鏈路完整埋點為全鏈路提供最基礎的管道,沒有這個最基礎的管道，所有的鏈路都將是模糊不清，無法識別的。同時 header在鏈路中的透傳為整個mock實現鋪平了道路，使得mock能夠快速根據header中的規則來識別不同的鏈路調用。

測試的不同場景在這里也有了很好的區分。而這些數據又都可以在ES中通過埋點來解決。mock可以通過ES API把這些數據拉來使用，從而基礎的API調用鏈路已經成形并且明晰。這就為后續的實現打下基礎。

基礎調用鏈路圖如下：

Es鏈路埋點如圖2所示：

圖2 ES埋點鏈路示意圖

?

當所有的鏈路設施都準備好之后，影響整個使用過程的就是怎么樣把mock快速無縫的切入真實調用鏈路。

我們知道，無論是slb還是ip直連，最基本的原理還是所有的服務都需要注冊，注冊的最終目的就是所有的服務中心化。當調用依賴服務的時候，在中心里獲取對方的服務，提供給調用方使用。

這樣的情況下，應用切入mock最直接的想法就是把中心中依賴方地址修改成mock地址，當然這就需要框架提供支持。這是一種侵入式的mock應用方法。

另外一種方式是通過PROXY，類似于網絡代理，所有經過代理的網絡包在代理中進行收編和整理，該走mock的走mock，不走mock的放回原來的網絡中。這種方式是當前相對比較理想的方式。把對應用的侵入，變成系統層面配置的更改，相對適應性更強一些。

綜上兩點解決后，整個mock鏈路的基本技術方案有了一個比較可行的落點。mock全鏈路的整體架構如圖3。

圖3 MOCK鏈路架構圖

三、技術實現

Mock的技術實現要注意以下三點：

3.1 Mock的響應速度

響應速度要滿足服務調用基本要求，不能timeout。正常情況下，mock不需要業務邏輯處理，只需要做規則的簡單匹配，響應速度要快才對，這是建立在規則相對少的情況下。

如果在千萬億級的規則進來之后，規則的獲取，場景的匹配速度會拖慢整個mock的響應，現在的mock系統同樣要依賴緩存技術來提高規則場景的匹配速度。

另外是pb格式請求，我們要進行多次的序列化和反序列化，來保證配置的明文json或者xml能夠正確的在請求中傳遞，而序列化和反序列化本身就是一個消耗cpu的動作，這會給響應造成極大的延遲。

當前情況下，我們盡量提前進行序列化和反序列化操作，操作結果存入緩存，這樣能夠在此等格式請求傳遞和返回傳遞的過程中，保持快速的字節流傳遞而不需要額外的序列化反序列化操作。

最后在轉發的情況下，相對正常服務調用多了一次網絡請求，時間消耗相對較長。在這方面我們盡量采用減少連接等待，保持連接狀態等方式來減少多次socket連接造成的時間損耗。

3.2 契約依賴問題

對于依賴契約的請求格式，如pb等，需要契約的更新速度必須在ES埋點落庫之前。

契約延遲更新是我們面臨的很大問題，契約的不及時更新，會造成數據節點的丟失或者直接調用報錯。發布訂閱和編譯包下載替換是我們目前解決這個問題的主要方式。

當前這需要維護一個所有應用契約文件的列表，以便我們在編譯包中進行查找替換。而替換動作成功發生的前提是當前契約文件沒有被進程占用。

3.3?系統操作的易用性 ?

操作簡單是用戶使用的基礎，也是系統的目標，當然操作習慣也會影響系統在不同人群中的使用。但最終的目標，是希望用戶用盡量少的鼠標或者鍵盤動作，來完成整個mock的操作。鏈路使用操作相對簡單是系統能夠被使用的重要環節。

譬如ES數據拉取，我們采用了只讓用戶輸入ES共享鏈接來代替繁瑣復雜的ES過濾器配置。

最原始的設計UI如下圖所示：需要有十幾個配置項需要用戶取配置：

改良后的交互如圖4所示，只需要輸入ES共享連接即可，其余的事情都由系統來協助用戶完成，從而減少用戶的使用費力度。

圖4 ES數據拉取

四、面臨的一些問題

在mock全鏈路的使用過程中，遇到一些新的問題，比如在真實調用鏈中重復調用的問題。由于重復調用的返回結果不一致，導致我們在mock全鏈路的時候無法知曉哪個是第一次要返回，哪個是第二次要返回，從而影響全鏈路的真實性。

緩存問題。之前提到過很多應用都會在本地或者其他緩存服務器做數據緩存，很多處理邏輯是緩存數據存在的情況下，拉取緩存數據，否則走依賴接口調用，在mock切入應用之后，發現很多緩存未過期導致mock無法被調用，從而影響全鏈路的正確性。

轉發302問題。有些服務需要在服務API之間做302轉發調用，而mock正常是要返回http code 200的狀態的。

針對不同業務的問題，我們只能針對性的進行個性化或者通用兼容性修補，在通用系統的基礎上，進行個性業務適應。

總之，mock全鏈路系統需要在實際業務中進行不斷的鍛造、更新，在使用中不斷調整，從而保證mock全鏈路能夠適應不同業務的需要。

五、后記

Mock的設計特別要考慮壓測的需求，壓測對mock系統的要求會更高，所以我們在設計之初，要把這種需求優先考慮，對系統擴展和快速資源擴容留下足夠的空間。

另外匹配規則的設計要盡量簡單，譬如正則和xpath, jpath此類的功能，從當前的統計數據來看，使用率不高；而簡單的規則，譬如header匹配，包含等則被用戶大面積使用。

總結

以上是生活随笔為你收集整理的干货 | 携程酒店MOCK全链路实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。