微服務架構下API的治理其中的一個老大難問題是面對眾多的第三方依賴，如何高效開發和測試？

一個很好的想法就是對線上流量進行錄製回放。

線上流量具有場景真實、場景豐富等特點，由於傳統的流量回放只能無序的把Inbound req/resp和outbound reqs/resps錄製下來卻無法進行關聯，其利用價值一直沒能正常發揮出來，一直是一個待挖掘的寶庫。

不過開源的流量回放系統OTDD（Online Test Driven Development），終於解決了這個問題，利用時間gap將inbound和outbound的流量正確進行了關聯，錄製後的流量線上下進行回放，極大的加快開發效率和測試效率！

其在2020/3/22號正式釋出了第一個版本0.1.0版本，快去體驗一下吧！

隨著容器平臺的建設落地，微服務越來越火，越來越多的公司已經開始採用或者正在考慮採用微服務架構。但微服務架構應用通常是分散式的，一個業務應用通常是由眾多的微服務編排而成，服務之間的呼叫、通訊、安全認證、訪問控制、負載均衡、限流限額等需求也帶來了運維的複雜性，實現微服務治理是個不小的難題。

企業常用的微服務架構平臺——RestCloud

RestCloud 作為商業化的微服務框架具有很多成熟、現成可用的模組可以達到開箱即用，RestCloud 底層本身基亍 SpringBoot 進行擴充套件開發而來，繼承了 SpringCloud 框架的基礎能力，同時又開發了很多易用的模組來加快微服務的開發和管理能力。

在API管理，很多企業最難問題是對第三方依賴，以及人員成本高。服務治理的問題由來已久，服務治理也是一個很大的話題。服務網格（Service Mesh）的不成熟。

RestCloud

RestCloud API管理平臺是完全自主研發的企業級統一API介面管理平臺，本平臺不但可以從Java程式碼中的註解自動掃描生成API文件還能透過OpenAPI3.0標準文件、手工等方式匯入企業的其他API介面，最終形成企業的統一的API清單。 本平臺功能全面優於swagger ui等開源的API介面生成平臺,支援對API介面的搜尋、分類、測試、匯入OpenAPI3.0文件、匯出OpenAPI3.0文件，匯出Word文件、標籤化管理、自動生成前端JSON常量等等功能。

(透過API介面管理平臺統一管理企業的所有API介面並進行分類和打標籤，實現API介面的知識管理功能)

個人理解首先要實現最基本的API全生命週期管理能力。

這個能力部分可以由API閘道器來提供，但是更多的還是要自己開放API的治理管控平臺來實現。具體的API全生命週期管理包括瞭如下內容。

API介面的定義

在定義API介面的時候首先要定義API分組，這個從京東，淘寶等OpenAPI能力開放平臺的API文件都可以看到，首先要有API歸類分組，然後再定義詳細的API。

比如京東開放平臺，有商品，店鋪，倉儲，支付等多個類目，然後各類目下有詳細的API的定義。

API的定義包括兩個部分，一個是API基本資訊定義，一個是詳細輸入輸出定義。

API基本資訊仍然是包括了API的編碼，API名稱，API的分組，API的用途描述，API的快取，安全等基本控制資訊的定義等。還有就是這個API介面的訪問路徑定義，API介面是Get還是Post方法定義等。

API詳細資訊主要就是API的輸入和輸出資訊定義。

API的輸入引數注意實際有多種形式，一個就是在API訪問路徑上的路徑引數，還有一個就是在訪問路徑後?引數後面的查詢引數資訊，還有就是一個完整的Request Body請求引數資訊。

比如對於Http Rest查詢介面，這類Get方法介面，可以看到並沒有Body資訊，更多的是透過路徑和查詢引數定義來完成查詢。而對於Post介面往往就涉及到具體的Body資訊定義。

但是要注意，為了實現Http Rest介面和SOAP WS介面服務的互相轉換，對於SOAP WS查詢服務介面在自動轉換為Http Rest介面服務的時候實際上仍然為轉換為Post方法+Body引數模式。

對於API介面定義，仍需要預留標準的系統級引數部分內容。這部分內容是API閘道器實現統一標準化管理的基礎，不能隨便修改和變動。比如京東API平臺預留的API名稱，方法，版本，Token，APP_Key，Date等都是使用系統級別的引數定義，是每一個介面API暴露後都需要增加的引數頭資訊。

API快速開發的支援

在API介面服務定義完成後，一方面是可以透過類似WADL或RAML等標準的Rest介面定義規範檔案，另外一個就是需要提供客戶端和服務端的開發框架程式碼。

在這個基礎上，還可以提供完整的示例程式碼下載，方便開發商或合作伙伴對API介面進行快速開發。開發完成的後端原始服務介面，在註冊接入前還可以提供介面服務的模型匹配自校驗功能，確認開發的服務完全遵循從上到下方式-》API開發框架生成和API後端服務開發。

對於API介面管理，如果是標準的從頂朝下模式，即在定義了API介面後，實現生成類似WADL或RAML標準介面規範。後端服務基於我們標準的API介面契約進行開發，那麼開發完成後就方便快速代理方式接入，在接入過程中就不再有引數對映和轉換的問題，否則我們的API接入過程會比較複雜。

API介面服務的註冊和接入

API介面定義過程和API介面的註冊接入最好分開。

在API介面定義完成後進行API介面服務的註冊，即選擇具體的後端服務，然後對服務進行接入。同時將後端服務對應到我們在前面定義的API介面代理服務上。注意在前面談到的API路徑定義，方法型別定義，實際上也可以在API介面服務註冊和接入的時候來完成。

API介面服務的後續變更釋出，還可以考慮和DevOps平臺配合並支援灰度釋出功能。

反向的後端服務快速接入併發布為API介面服務，即直接對後端已有的API服務進行快速接入，將API後端服務釋出為代理服務，在整個接入過程中需要定義API介面名稱，API訪問路徑，API方法型別等資訊。在釋出為API介面服務後，對於後端服務的API引數資訊也需要進行快速匯入，以方便在API介面查詢中看到詳細的介面內容定義。

在將後端業務服務釋出為API介面服務的時候，釋出的代理服務要自動增加系統級的輸入引數資訊，這個輸入引數最好的方式是在訪問路徑中進行增加，以減少對已有的後端服務的影響。

API介面在註冊和接入完成後，將自動進行服務部署和服務釋出，即註冊接入完成後的服務可以透過釋出的訪問路徑地址進行訪問。

API介面線上模擬測試功能

這個功能參考當前的OpenAPI能力開放平臺的做法來實現即可。即對於已經發布完成的API介面服務，提供線上測試工具進行線上測試。同時對介面服務呼叫的輸入引數進行結構化展示，方便使用者對測試需要的各種引數進行輸入。在輸入完成後形成完整的提交引數完整字串。透過測試，可以返回最終的模擬呼叫返回結果字串資訊。

API介面查詢功能

對於API介面查詢功能也是一個標準的功能，實際上可以考慮將查詢功能和API介面服務的分類瀏覽分開。對於API介面的分類瀏覽參考開放平臺的API介面文件做法來實現介面。對於API介面查詢，即可以設定不同的動態查詢條件，對API介面進行查詢，返回結果集。對於查詢到的API介面清單列表，可以點選詳細進入到API介面詳細的輸入和輸出資訊檢視介面。

API狀態管理功能

對於已經註冊和釋出的API介面可以對其狀態進行管理。其中主要的狀態包括了待發布，上線，暫停，下線廢棄等幾種關鍵狀態。對於API狀態本身還需要和後續的API監控管理結合，能夠透過API效能監控動態的調整API介面的狀態。比如在API觸發熔斷後，自動對API介面狀態調整為暫停。

API版本管理能力

對於API需要啟用版本管理能力。當前一些API介面服務實現方法會在路徑引數中增加API版本資訊，以確定究竟訪問哪個版本。但是由於不同的API版本可能存在返回的結果集的資料結構不一樣的問題，因此對於這種場景需要針對該API定義不同的大版本，不同的大版本實際上對應不同的後端原始服務。

當然對於API治理也可以參考SOA治理整體方法論，比如對於SOA治理我們給出過如下的治理管控框架，如下：

對於Oracle的SOA治理，為了實現業務、企業架構 和 SOA 目標，必須在不同業務領域制定策略：體系結構、技術基礎架構、資訊、財務、組合、人員、專案（或專案的執行方式）和運營。其比較明顯的特點是體現了EA企業架構，業務架構對SOA治理活動的影響和推動。而IBM的SOA 治理和管理方法（SOA Governance and Management Method，SGMM）是一種端到端的定義方法，透過設計、實現和改進 SOA 治理來進行。IBM的治理生命週期將治理活動分為了計劃，定義，使能和度量四個階段，涉及到服務生命週期各個方面的內容，具體如下：

服務定義，包括服務的範圍、介面和邊界服務部署生命週期服務版本治理，包括相容性服務遷移, 包括棄用和退役服務註冊中心，包括依賴關係服務訊息模型，包括規範資料模型服務監視，包括進行問題確定服務所有權，包括合作組織服務測試，包括重複測試服務安全, 包括可接受的保護範圍

對於Oracle和IBM的治理進行對比分析，不斷髮現存在的一些相同點。從方法上看都覆蓋了傳統的專案管理，SOA服務工程框架，ITIL運維管理三個方面的內容。從範圍上看則包括了組織人員，業務技術和管理三個方面的內容。而從流程上面可以講是覆蓋了服務全生命週期，包括服務識別發現，定義設計，開發測試，上線的前生命週期，也包括了服務開通，運維，監控的後生命週期。基於以上分析，可以看到SOA治理是一個覆蓋服務全生命週期，涉及業務域，服務域和支撐過程域三個方面內容的完整治理框架和模型。如上圖所描述一樣，透過這種二維的結構，基本上可以看到SOA治理和管控所涉及的全部內容。基於該業務目標架構，SOA治理和管控又包括瞭如下關鍵內容：服務全生命週期管理中心SOA治理和管控一定要能夠對服務全生命週期進行很好的管理，廣義點的需要從企業業務目標和流程目標入手，到流程分析和需求分析，到服務識別和發現，到服務定義和設計，服務開發測試，服務上線的全過程有效的管理。對於服務識別和定義階段，需要對業務域，服務目錄，服務進行相應的元資料定義，以形成服務目錄庫。而服務目錄庫是後續服務使用和檢索，服務設計開發測試的基本依據。能力提供中心SOA提供的服務本身就是一種能力，提能力提供中心的意義就在於要將服務轉化為一種能力進行提供。達到業務元件化，元件能力化的目標。只要這樣才能夠更好的推進服務的重用，服務的編排和整合。對於能力提供中心包括了兩個方面的內容，一個是服務前生命週期的管理可以實現服務的入庫，服務入庫後即轉變為服務的能力提供。那麼對於需求方可以對服務資產庫進行檢索，檢視自己需要使用的能力，然後進行服務申請，服務開通和使用。運維監控中心運維監控中心可以參考ITIL的標準進行構建，包括了事件管理，問題管理，變更管理，效能分析和監控，SLA管理，配置管理庫等基本內容。運維監控中心是保證SOA平臺能夠高可用執行的基礎。透過運維監控中心一方面是解決服務使用過程中遇到的問題，一方面是透過預警規則和策略的設定，能夠及時的預警SOA平臺存在的潛在問題，保證平臺的高可用性。

在微服務架構中，一個大應用被拆分成多個小的服務，這些微服務自成體系，可以獨立部署和提供對外服務。一般來說，微服務的呼叫規範主要有 RPC 和 RESTFul API 兩種，微服務是透過眾多元件搭建的，這是一個挺大的工作量。微服務治理主要是為每個微服務都實現一個API閘道器，來對外提供統一的介面，實現註冊、轉換、路由、限流、負載均衡等功能，又使API閘道器職責過重，使微服務生態複雜化。如果把每個微服務的這些非業務邏輯能力要求都提取出來，放在一個公用的API閘道器上去實現，使每個微服務專注於其業務邏輯的開發，就會簡化開發，提升敏捷性。在公用的統一的API閘道器上實現微服務的註冊、轉換、路由、流控等，對映為一個標準的API對外提供服務。這樣既滿足了微服務開發敏捷性的要求，也是簡化微服務治理的需求。微服務所有的安全認證、訪問控制等可以從微服務本身剝離出來，透過統一的API閘道器元件定義策略配置來實現微服務的安全管控和服務治理。

1、首先看下微服務是什麼

微服務架構是一種將單應用程式作為一套小型服務開發的方法，每種應用程式都在其自己的程序中執行，並與輕量級機制（通常是HTTP資源的API）進行通訊。這些服務是圍繞業務功能構建的，可以透過全自動部署機制進行獨立部署。這些服務的集中化管理已經是最少的，它們可以用不同的程式語言編寫，並使用不同的資料儲存技術。

2、再讓我們看下api閘道器

服務的粒度，服務的劃分，服務的功能都隨時間或者需求會有不同程度的變化，服務之間的通訊透過api來實現。

API閘道器是一個伺服器，是系統的唯一入口。從面向物件設計的角度看，它與外觀模式類似。API閘道器封裝了系統內部架構，為每個客戶端提供一個定製的API。它可能還具有其它職責，如身份驗證、監控、負載均衡、快取、請求分片與管理、靜態響應處理。

3、api閘道器治理

api治理實質上可以理解為api的用途自己實現

a、路由，api閘道器是服務的入口，透過路徑的方式指向不同的服務

b、版本控制，透過版本號來控制服務的不同時期的內容

c、協議統一處理，不同服務間的協議可能不同，需要統一的處理方式進行轉換

d、許可權控制，服務之間的互動，使用者的登入等透過如jwt等方式進展限制與驗證

e、限流，控制服務的承載，保證主體業務的實時性與存活等

f、熔斷，高峰期保證主體業務存活，阻斷重要性低的服務

g、降級，優先順序處理

4、靈活運用才是關鍵

根據不同的業務場景。技術背景選擇符合自己的治理方式。

都不要說微服務架構，就是單體應用架構中，API服務也是需要治理的。

首先是API介面文件的問題，這一點經常會被大家忽視，相信很多公司還在寫介面文件，專案開始的時候還好，但是隨著專案的發展，如果介面有改動，但是文件更新的不是那麼及時甚至是不更新，那麼這會加重團隊之間溝通的成本。

雖然我們可以透過管理流程強制大家寫文件，但是再怎麼說，程式碼和文件是要修改兩次的，難免會有疏漏。所以可以考慮使用一些框架或外掛，自動地根據程式碼生成文件，這樣開發人員只修改程式碼就好了，文件始終會和程式碼保持一致（當然開發人員還是要修改程式碼和Annotation，但是它們畢竟是在一起的）。

第二就是API介面測試的問題了，新開發一個介面很簡單，難的是修改一個介面功能的時候，如何保證之前功能的正確性和穩定性；而對於介面呼叫方來說，同樣需要確保自身依賴介面的正確性，因為使用者是不會區別是你們系統的問題還是你們依賴系統的問題。我們是依靠單元測試覆蓋率的統計和每天定時跑所有系統單元測試用例的方式，來提高各個系統的可用性（雖然這只是一種管理手段，單元測試用例覆蓋率也很容易造假，但正是“防君子不防小人”）。

監控和缺陷追蹤，如果是在分散式架構下，就是呼叫鏈路的管理；以往的系統，更多的是A系統呼叫B系統，而現在可能面對這A->B->C->D，而在這種情況下，如果沒有鏈路跟蹤的方案，那麼查詢和定位問題就會非常困難；這時候可以使用Sleuth來做服務之間呼叫提供鏈路追蹤；使用Sleuth的時候，也可以和zipkin做整合，將蒐集到的資訊傳送到zipkin，利用zipkin進行資料的儲存和展示。

個人經驗，新專案怎麼都好說，老專案的改造是老大難，這種時候，可以考慮引入日誌平臺吧，對各個系統的API日誌進行主動抓取，然後在日誌平臺裡面加工展示。

老妖在帶著團隊弄微服務。對於API沒想那麼複雜。一是我們前後端開發時都由一個人負責，沒分開。二是老妖定好了開發規範，直接使用Swagger生成API文件就可以了。

當然，如果你是前後端分離由不同人員開發的，那麼API的定義文件是必須要有的了。不然，前後端人員經常打架是一定的了。