在進行產品測試時，我們會碰到下面幾種情況：
- 依賴接口不通。比方說，在我測試訂單系統時，需要調用商品系統的接口獲取商品信息。如果商品接口壞了，需要等待商品接口恢復之后才能繼續我的測試。我們都有感觸，這種情況在測試環境中尤為突出。依賴接口能不能穩定一些呢？
- 異常數據模擬困難。再舉個例子，在我測試商品系統時，需要調用商家系統的接口認證商家為非法商家時，接口正常情況下無法提供這樣的數據。可能這樣的測試執行會比較困難。那我們如何簡便的構造接口的異常數據呢？
- 依賴接口性能參數無法保障。這個例子是這樣的。我在對商品系統進行壓力測試，需要商家接口及時返回數據，滿足商品這邊的調用頻度。現在的做法是，找一台高性能機器，部署商家系統，來滿足商品的壓測要求。當依賴接口多的情況下，這會是很大的額外工作量。如何能夠省略這個工作量呢？
可能大家想到用Mock的方式，去模擬一個網絡的接口。過程是這樣的。我想要得到的是被測系統的輸出。Tesla是被測系統。數據輸入后經過Tesla，Tesla要調用Stub接口，然后返回數據。也就像之前咱們舉的例子：商品系統調用商家接口。如果Stub接口掛了，我們用Mock服務代替這個接口，返回定制好的數據，然后得到輸出，完成數據的正常流動。
那是不是有Mock服務就完全解決了開頭提到的三個問題呢？我覺得並沒有。我們研究了業界眾多的Mock方案，比方說，支持HTTP協議的WireMock，支持WebService的SoapUI里面的MockService，Dubbo需要自己寫接口實現再打成jar包中並需要同接口在一個jar包中。我們從中看到這樣的缺點：不同協議的方案從屬於不同的平台，多個Mock服務無法有效管理。
Mock服務的平台管理部分，其實各家有個家的方案，主要看是不是便利了。而對於Mock方案，不同方案其實千差萬別。看起來都是對於接口的模擬，如果不是從協議底層出發，可能它的擴展性不會很大。
現代RPC的本質其實就是在網絡上傳輸數據包，而這個數據包的特點是header+body。Header就是協議頭，分為定長或者變長，這個取決於協議的設計者。比方dubbo協議就是定長的。而有些協議是變長的。Body就是消息體，其實就是對象的序列化過程，把序列化好的數據放入到body里面。現在流行的序列化方案有：hessian，java，json，msgpack等。
有了這個本質了，咱們看一下，用什么樣的方式從網絡中傳輸這個數據包。
底層框架用NIO/Netty框架。因為是異步通信，高性能，高並發的支持，Netty框架就可以做到。
建立通信之后，客戶端發起請求，發送數據包到服務端。服務端拿到數據包之后進行解碼操作。
服務端構造響應結果，序列化完成后，加上協議頭信息，返回給客戶端。
過程雖然簡單，但是在實際開發過程中可能碰到一些問題。下面就是我在實踐的時候碰到過的一些坑，列出來供大家參考。
- 心跳包的處理。什么是心跳包，其實就是為了保持連接，客戶端向服務端定時發起的檢測包，里面沒有任何的具體內容，只是用於告訴服務端，我還活着。因為沒有body，所以要做特殊的處理，不能直接類同有響應體的數據包。
- 客戶端可能是連着發請求，數據包是連在一起的，需要判斷長度，到某個字節一次請求就結束了，跟着的應該是下一次請求了。這就需要對數據包進行合理的切割。
- 數據包的協議頭部分可能帶有認證信息比方requestID之類的，需要在返回時，也需要把這個id返回到客戶端。因為一般客戶端都會有認證的機制，如果id不一樣，則不解析這個響應。
綜上，對於接口的Mock，從協議底層下手擴展性好，處理較方便，能夠協助剝離依賴關系，更便捷、專注於自身系統的測試工作，達到事半功倍的效果。