這是專題的第三篇文章，聊聊內網環境中的 API 開發與治理。

前面的文章中有說到微服務的通信方式，Martin Folwer 先生在他對微服務的定義中也提到“每個服務運行在其獨立的進程中，服務與服務間采用 輕量級的通信機制 互相協作（通常是基于 HTTP 協議的 RESTful API）”。

那么，在各個微服務之間具體怎么進行輕量級的通信呢？這篇文章就來聊聊微服務 API 開發及治理的幾個方面。

首先需要解釋一下，標題中的“內網環境中 的 API”指的是提供給內網里的其它微服務調用的 API。與其相對應的是“開放給互聯網 用戶調用的 API”，它們的開發方法大體相同，但治理方法卻不太一樣。

例如開放給互聯網用戶調用的 API 需要在 API 網關上加上授權、鑒權、限流、限并發、統計、計費等等功能。

本篇文章分享的是內網環境中的 API 開發及治理。

API 開發，首先考慮的就是該用什么樣的協議，是 HTTP API 還是 RPC？

我們先來介紹一下這兩種 API 類型：

HTTP API 指的是簡單的基于 HTTP 協議的 API，具體的例子就是 Spring MVC 的 Controller，例如 

“http://127.0.0.1/helloworld/myapi.do”。

RPC 就是 Remote Procedure Call，中文名遠程過程調用，在 API 調用的場景下，大多指的是基于 Socket 通信方法的遠程調用（當然，我們也可以使用 HTTP 協議來實現 RPC 調用，例如 gRPC）。Json-RPC 和 Xml-RPC 指的是使用 Json 或 Xml 作為文本格式的方式傳輸命令和數據。

那么回到剛才那個問題，到底要使用 HTTP API 還是 RPC 呢？我們之所要對比 HTTP API 和 RPC，主要是因為大家都知道 HTTP 簡單，而基于 Socket 的 RPC 性能更好。

這個問題我們糾結了很久，直到后來，想明白了下面兩件事，最終決定在絕大部分場景中使用 HTTP API。

通常來講（根據資料），算上序列化的時間，RPC 協議的吞吐量是 HTTP 性能 兩倍（沒有親測），例如 Protobuf、Thrift、Kyro、Dubbo 等等。

這里面，又以 Thrift 的性能最高。具體的性能測試報告可以參考《RPC 框架性能基本比較測試》。

我們團隊在結合自身技術棧、成本、穩定性、易用性、可維護性、業務場景等等因素綜合考慮后，覺得我們面臨的大多數場景中，HTTP 和 RPC 的性能差別并不是主要問題。

再加上下圖所示的 HTTP 性能測試結果作為佐證，我們完全可以采用 HTTP API 的方式來進行微服務 API 開發。

再者，當業務發展到一定的程度，如果某些業務功能的性能壓力變大時，我們還是可以使用 RPC 小范圍地進行改造。這也是符合敏捷思想的一個決定。

下圖是對 helloworld 頁面進行 10000 次連續請求的測試結果，總耗時 1.504 秒，平均每個請求耗時 0.15 毫秒。

下面是對 helloworld 頁面以 100 并發數進行 10 萬次請求的測試結果，平均每個請求耗時 11.9 毫秒。

所以，按照上面的測試結果，HTTP API 方式的性能完全足以支撐絕大多數的微服務 API 開發。讓我們把 RPC 方式留給那些可能出現雙十一業務量的大型互聯網公司去玩。

這是另一個折磨人的問題。相對于 HTTP API，RESTful API 在 HTTP API 的基礎上增加了一些非常抽象晦澀的概念，例如資源（Resource）、表述（REpresentation）、狀態轉移（State Transfer）、統一接口（Uniform Interface）……。

在經歷了一次又一次的折磨，例如“login/logout 是什么 RESTful 方法？”、“批量刪除該怎么實現？”、“RESTful 的 resource 究竟該怎么定義？”之后，越來越感覺這是一個形而上學的問題，太過于抽像。

我們不該盲從于時髦的技術，需要加上技術人的基于自身情況的理性思考。所以，RESTful 雖好，但不是我們團隊的菜。

再者，即使團隊中有些人可以理解并正確地實踐，也很難或者說不可能讓整個團隊來正確地實踐這樣一種方法。

所以，我們在一番掙扎后，選擇了 HTTP API 方式，原來怎么開發，現在還是怎么開發，把主要精力放到了 API 的監控和治理上面。

這里推薦大家看看知乎上的這篇討論 《WEB 開發中，使用 JSON-RPC 好，還是 RESTful API 好？》，幾位大神講得都挺好。

[http://www.virginiabusinesslawupdate.com]

API 存在的意義在于有人調用它，如果調用方在調用 API 的時候很麻煩，甚至不能正確地調用，那么團隊內部及團隊之間的溝通成本及配合程度就會大受影響。

我們是通過文檔來溝通的，項目開始的時候還好，但隨著時間的推移，文檔的更新變得不是那么及時（這其實是個自我辯解的說法，事實是大部分情況下文檔都不更新了），API 變更時，也不容易找出哪些模塊調用了這個 API。

所以，得先解決 文檔不及時更新 的問題。雖然我們可以通過流程管理的方式來強制大家更新文檔，但這對于開發人員來說，顯然是不夠科學或人性化的，因為變更一個 API，就要在兩個地方進行修改，一是 API 代碼，二是 API 文檔，程序員的思維就得在代碼和文檔之間不斷切換，工作效率必然受影響。

我們就想，能不能只需要在同一個地方修改，如果能做到，API 文檔的更新就沒有那么麻煩了，于人于已都是好事。

經過調研，我們選擇使用 Swagger 來編寫文檔，按照 Swagger 的規范，在 API 上加一些描述性的 Annotation 就可以了。

通過以上的 Annotation，將自動生成以下在線 API 文檔。

調用方可以在 API 文檔界面填入參數并點擊“Try it out!”按鈕嘗試調用這個 API。這樣，在沒有 API 提供方支持的情況下，即可以自行完成絕大部分的 API 調用，是不是很爽？

API 開發出來了，API 文檔也寫好了，接下來就是被調用了。前篇文章講到，通過 Spring Cloud 的 Eureka + Ribbon + Zuul 可以很方便地調用到這些 API。

那么，如何來追蹤 API 被誰調用了，調用是否出錯及出錯原因，調用鏈路里各個 API 的性能怎么樣，是不是存在僵尸 API……這些都是關于 API 治理的問題。

實現這個目標，有一個比較取巧的方法，就是在 Ribbon 的客戶端里做點文章，在調用 API 之前記錄一下開始時間，API 調用返回后，記錄 API 調用耗時、調用狀態，如果有錯則記錄一下錯誤原因。

如果還想追蹤調用鏈，可以在請求頭里加上一個調用鏈 ID，這樣就來把調用關系都串連起來。

下邊是我們自己研發的調用鏈管理組件（DCTrace）的幾個效果圖：

站在技術管理者的角度，可以從調用鏈里看出來，哪些模塊之間發生了不正當關系 [噗嗤]；哪些模塊之間本該有關系的，事實卻沒有；通過對比 Swagger 和調用鏈的 API 清單，找出僵尸 API……

使用微服務架構后，API 是每個微服務的 唯一能力出口。由于互聯網行業的快速發展，軟件需求變更變得越來越頻繁，迭代升級的速度變得越來越快。

對于提供方來說，需要保證變更和迭代的過程中，不影響之前承諾的功能（包括正確性、穩定性和性能等）。

對于調用方來說，同樣需要確保自身依賴的 API 能正常使用，不能因為其它模塊的錯誤而導致自身業務受到影響（包括正確性、穩定性和性能等）。

畢竟，從組織角度來看，系統出錯就是出錯，不管原因是自身導致的還是服務提供方導致的，所以 服務調用方就需要對服務提供方進行管理。

這也就是前幾年契約測試（Pact）方法大行其道的原因。有興趣的朋友可以去看看這種測試方法。

對于 API 白盒測試，推薦使用基于 Java 的 REST-Assured 測試框架，用起來特別方便。

[https://github.com/rest-assured/rest-assured]

更進一步，基于 HTTP 協議、JSON/XML 報文的規范性，完全可以開發一個 API 測試小工具（暫且叫它 小鷹 吧）來替換 REST-Assured。我們也暫未實踐，只是覺得會很有用，供大家參考。

基礎步驟是：

1. 服務提供方開發 API，并正確書寫 Swagger 文檔。

2. 服務提供方在小鷹的界面上選擇需要測試的 API，并填寫測試參數。（API 清單和參數都可以通過調用 Swagger 的 API 獲?。?/p>

3. 服務調用方根據自已的理解，也將對自己有用的服務方提供的 API 配置到小鷹上。

4. 小鷹 7*24 小時為服務提供方和調用方巡視這些 API，并在異常出現時發送警報。

所以，對于微服務 API 開發，我們

• 使用最常見的技術（例如 Spring MVC）進行 API 開發

• 使用 REST-Assured（以及未來的 小鷹）進行測試

• 使用 Swagger 來管理 API 文檔

• 使用自研的 DCTrace 進行調用鏈管理