OAuth和OpenID Connect圖解指南
我們團隊在結合自身技術棧、成本、穩定性、易用性、可維護性、業務場景等等因素綜合考慮后，覺得我們面臨的大多數場景中，HTTP 和 RPC 的性能差別并不是主要問題。
再加上下圖所示的 HTTP 性能測試結果作為佐證，我們完全可以采用 HTTP API 的方式來進行微服務 API 開發。
再者，當業務發展到一定的程度，如果某些業務功能的性能壓力變大時，我們還是可以使用 RPC 小范圍地進行改造。這也是符合敏捷思想的一個決定。
下圖是對 helloworld 頁面進行 10000 次連續請求的測試結果，總耗時 1.504 秒，平均每個請求耗時 0.15 毫秒。
測試環境：原生 Tomcat7（沒有任何優化）運行在本地虛擬機上
下面是對 helloworld 頁面以 100 并發數進行 10 萬次請求的測試結果，平均每個請求耗時 11.9 毫秒。
測試環境：原生 Tomcat7（沒有任何優化）運行在本地虛擬機上
所以，按照上面的測試結果，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 的監控和治理上面。
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。我們也暫未實踐，只是覺得會很有用，供大家參考。
基礎步驟是：
所以，對于微服務 API 開發，我們
文章轉自微信公眾號@InfoQ
