接口Mock
從本篇開始結合筆者的實戰經曆講解開發運維場景。這些經曆中包含筆者自身思路的一些探索和實踐，網上類似的内容不多。看完這些思路後，相信各位在進行自研項目時一定能大大提高工作效率，而且在述職答辯、晉升答辯方面提升也會很大。
下面先講一個聯調相關的場景。
業務場景：第三方服務還沒完成，功能設計如何繼續
筆者團隊在設計新零售系統時，最在意的兩點是前期的方案設計和接口的聯調。比如在聯調階段，經常會碰到各種意外，其中最典型的兩個場景是這樣的。
1.與公司外部之間的調用
聯調外部接口往往需要先申請測試環境，而申請測試環境的時間一般都很長，會耗費很多精力。
比如有一次，需要對接一個第三方支付接口，系統自身的功能需求實作後，對接第三方支付接口的功能還遲遲沒有動工。組員不斷催商務，商務不斷催第三方支付的聯系人，第三方支付的聯系人一直說在走流程，最終僅僅一個第三方支付接口的測試環境就等了3周。
2.公司内部之間的接口調用
曾經有一個項目需要團隊配合另一個部門一起做。
需求宣講完後就是定排期，然後團隊就問合作部門：“這幾個接口什麼時候可以聯調？”
因為合作部門還在趕另外一個項目，便回複道：“我們先一起對接口，等忙完手頭這個項目，再給出排期可以嗎？”我們團隊道：“那也得給出一個具體的上線計劃啊！”
在我們的催促下，合作部門終于給出了一個日期。
過了幾天，合作部門手頭的項目出現了延期，又過來跟我們說：“可能晚幾天才能提供那些接口。”
因為需要與對方互動的功能遲遲未動，我們團隊也不敢釋放人手，擔心釋放後項目又立即啟動，好不容易熟悉新項目後又要回來做這個項目。
為此，項目組坐在一起讨論出了一個解決思路，下面一起來看看。
解決思路
項目組希望有一個Mock接口服務，它能提供與正式服務的URL、出入參一樣的接口，差別是主機名或者URL的字首不一樣。
在開發和測試過程中，大家的服務都連接配接上Mock服務進行聯調。等到接口或環境搭建好後，無須修改代碼，通過一個簡單的配置切換即可讓服務連接配接到真實接口服務，然後通過一些簡單的回歸測試即可實作上線，能大大提升開發效率。此時整體的系統架構如圖16-1所示。
圖16-1 Mock和真實服務切換
這個架構圖看起來很簡單，不過，如果想實作這個思路，就比較複雜了，因為它包含Mock服務端和Mock服務用戶端調用設計。
Mock服務端設計
先講一下在Mock服務端設計過程中都需要滿足哪些需求。
Mock接口支援傳回動态字段資料
比如有一個接口輸入的參數為userID、orderID和redirectURL（見圖16-2），輸出的參數為success和startTime（見圖16-3），每次調用這個Mock接口時，startTime都需要傳回目前時間（見圖16-4）。
• 圖16-2 支援回調連結
• 圖16-3 輸出參數
• 圖16-4 傳回動态值
Mock接口支援一些簡單的邏輯
在測試過程中，會通過不同的測試用例走完不同的流程。緊接着上面的例子，比如，若調用Mock接口傳入的userID是10001，那麼Mock接口傳回的success值為true，否則為false，而後系統會根據不同的success值進入不同的流程。
Mock接口支援回調
在實際開發工作中，有很多聯調接口需要異步回調，比如上面的例子中，如果傳回的success值是true，希望一段時間後回調redirectURL。
Mock接口支援規則校驗
項目組希望通過添加一些規則讓這個Mock服務對傳入的參數進行校驗，比如校驗userID是否為數字、orderID是否為15位數字、redirectURL是否為URL等。
Mock服務支援接口文檔導入
這一點比較特别，比如在設計接口文檔時，某些團隊直接将接口定義放在Wiki上，而某些團隊直接寫在Java代碼中，再通過Swagger生成線上接口文檔。
對于前者，要求定義接口時直接将接口文檔放在新的Mock服務上；而對于後者，因為不想改變他們的習慣，是以最終Mock服務需要支援Swagger文檔導入。
Mock服務端實作架構
根據以上5點需求，項目組開始尋找一些合适的開源架構。其中，收費的接口文檔管理工具有Apizza、Eolinker，免費的有YAPI和RAP2，出于各種原因，項目組最終決定在YAPI和RAP2中進行選擇。
YAPI和RAP2的對比見表16-1。
表16-1 YAPI和RAP2的對比
通過對比發現YAPI更貼合需求，開發人員隻需改動一個小功能即可滿足所有需求。
是以，在Mock服務端的實作過程中，最終基于YAPI進行二次開發。
Mock服務用戶端調用設計
講完Mock服務端，接下來看看調用Mock服務用戶端時，都需要考慮什麼。
Mock服務如何支援基于二進制流的接口調用
因為曆史原因，系統中有些服務間調用使用Spring Cloud Feign，而有些服務間調用使用基于二進制流序列化的RPC（當然是基于TCP協定）。
如果服務間的通信基于二進制流而不是JSON，就無法在YAPI上通過簡單的界面定義來輸入、輸出參數，且YAPI也不支援二進制流的調用，此時解決方案如圖16-5所示。
• 圖16-5 二進制流和JSON切換
該方案中添加了一個攔截器，它會攔截所有服務間調用的請求，并增加一個判斷。如果通路的位址是Mock服務，就使用HTTP協定，并且通過JSON進行序列化和反序列化，這樣問題就解決了。
這裡需要補充一點：有些第三方接口會使用XML格式（很多銀行的接口就是這樣），最終項目組決定先不支援自定義XML格式的接口，因為改造YAPI的工作量實在太大。
Mock服務用戶端如何簡單切換Mock與真實服務
這裡要考慮以下兩種情況。
1）對于第三方接口，隻需在配置中将第三方接口的Host改為Mock服務的Host即可。
2）對于微服務間的調用，Spring Cloud中的微服務定義都是服務級别，但是在實際開發的場景中，需要使用接口級别的Mock，比如開發的operationService，它依賴于productService的幾個接口。是以，在新項目中，還需要在productService中新增幾個接口，且它們必須調用Mock服務的接口，而原先的接口繼續調用真實的productService中原來做好的接口。此時需要在配置中心增加兩個配置項：mock.apis和mock.host，每次服務間調用時，先判斷調用的URL是否在mock.apis字元串清單中，如果在，則讓它調用mock.host這台機器。特别說明一下：關于這一點，筆者所在團隊也出過錯。因為在上線時配錯了mock.apis和mock.host，導緻線上環境使用了Mock服務，是以需要考慮如何預防線上環境使用Mock服務。
如何預防線上環境使用Mock服務
之後編寫了檢查代碼：在服務啟動時，先判斷目前的環境名稱，如果是prod（線上環境），就先判斷mock.apis中是否有值，有的話提示異常；然後掃描所有的properties配置，如果配置中包含Mock服務位址，則說明有些地方配置了Mock服務的調用，也提示異常。
到這裡，整體的Mock調用方案就完成了。
小結
Mock服務上線使用後，如果第三方服務或者其他團隊的接口還沒有準備好，可以直接根據接口文檔配置Mock接口，并且所有測試人員都可以基于這些Mock接口展開測試。測試成功後，就可以釋放團隊成員，安排他們開展其他項目。
等第三方服務或其他團隊的接口完成後，再抽調部分成員回到該項目進行簡單聯調和回歸測試，進而實作了系統快速上線。最終整個團隊對這個Mock服務的評價也不錯。
到這裡這一章就講完了，下一章将講解如何解決測試環境不夠用的問題。
本文給大家講解的内容是開發運維場景實戰：接口Mock
- 下篇文章給大家講解的内容是開發運維場景實戰：一人一套測試環境
- 覺得文章不錯的朋友可以轉發此文關注小編；
- 感謝大家的支援！！