API如何治理？

個(gè)人理解首先要實(shí)現(xiàn)最基本的API全生命周期管理能力。

這個(gè)能力部分可以由API網(wǎng)關(guān)來提供，但是更多的還是要自己開放API的治理管控平臺來實(shí)現(xiàn)。具體的API全生命周期管理包括了如下內(nèi)容。

API接口的定義

在定義API接口的時(shí)候首先要定義API分組，這個(gè)從京東，淘寶等OpenAPI能力開放平臺的API文檔都可以看到，首先要有API歸類分組，然后再定義詳細(xì)的API。

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

API的定義包括兩個(gè)部分，一個(gè)是API基本信息定義，一個(gè)是詳細(xì)輸入輸出定義。

API基本信息仍然是包括了API的編碼，API名稱，API的分組，API的用途描述，API的緩存，安全等基本控制信息的定義等。還有就是這個(gè)API接口的訪問路徑定義，API接口是Get還是Post方法定義等。

API詳細(xì)信息主要就是API的輸入和輸出信息定義。

API的輸入?yún)?shù)注意實(shí)際有多種形式，一個(gè)就是在API訪問路徑上的路徑參數(shù)，還有一個(gè)就是在訪問路徑后?參數(shù)后面的查詢參數(shù)信息，還有就是一個(gè)完整的Request Body請求參數(shù)信息。

比如對于Http Rest查詢接口，這類Get方法接口，可以看到并沒有Body信息，更多的是通過路徑和查詢參數(shù)定義來完成查詢。而對于Post接口往往就涉及到具體的Body信息定義。

但是要注意，為了實(shí)現(xiàn)Http Rest接口和SOAP WS接口服務(wù)的互相轉(zhuǎn)換，對于SOAP WS查詢服務(wù)接口在自動轉(zhuǎn)換為Http Rest接口服務(wù)的時(shí)候?qū)嶋H上仍然為轉(zhuǎn)換為Post方法+Body參數(shù)模式。

對于API接口定義，仍需要預(yù)留標(biāo)準(zhǔn)的系統(tǒng)級參數(shù)部分內(nèi)容。這部分內(nèi)容是API網(wǎng)關(guān)實(shí)現(xiàn)統(tǒng)一標(biāo)準(zhǔn)化管理的基礎(chǔ)，不能隨便修改和變動。比如京東API平臺預(yù)留的API名稱，方法，版本，Token，APP_Key，Date等都是使用系統(tǒng)級別的參數(shù)定義，是每一個(gè)接口API暴露后都需要增加的參數(shù)頭信息。

API快速開發(fā)的支持

在API接口服務(wù)定義完成后，一方面是可以通過類似WADL或RAML等標(biāo)準(zhǔn)的Rest接口定義規(guī)范文件，另外一個(gè)就是需要提供客戶端和服務(wù)端的開發(fā)框架代碼。

在這個(gè)基礎(chǔ)上，還可以提供完整的示例代碼下載，方便開發(fā)商或合作伙伴對API接口進(jìn)行快速開發(fā)。開發(fā)完成的后端原始服務(wù)接口，在注冊接入前還可以提供接口服務(wù)的模型匹配自校驗(yàn)功能，確認(rèn)開發(fā)的服務(wù)完全遵循從上到下方式-》API開發(fā)框架生成和API后端服務(wù)開發(fā)。

對于API接口管理，如果是標(biāo)準(zhǔn)的從頂朝下模式，即在定義了API接口后，實(shí)現(xiàn)生成類似WADL或RAML標(biāo)準(zhǔn)接口規(guī)范。后端服務(wù)基于我們標(biāo)準(zhǔn)的API接口契約進(jìn)行開發(fā)，那么開發(fā)完成后就方便快速代理方式接入，在接入過程中就不再有參數(shù)映射和轉(zhuǎn)換的問題，否則我們的API接入過程會比較復(fù)雜。

API接口服務(wù)的注冊和接入

API接口定義過程和API接口的注冊接入最好分開。

在API接口定義完成后進(jìn)行API接口服務(wù)的注冊，即選擇具體的后端服務(wù)，然后對服務(wù)進(jìn)行接入。同時(shí)將后端服務(wù)對應(yīng)到我們在前面定義的API接口代理服務(wù)上。注意在前面談到的API路徑定義，方法類型定義，實(shí)際上也可以在API接口服務(wù)注冊和接入的時(shí)候來完成。

API接口服務(wù)的后續(xù)變更發(fā)布，還可以考慮和DevOps平臺配合并支持灰度發(fā)布功能。

反向的后端服務(wù)快速接入并發(fā)布為API接口服務(wù)，即直接對后端已有的API服務(wù)進(jìn)行快速接入，將API后端服務(wù)發(fā)布為代理服務(wù)，在整個(gè)接入過程中需要定義API接口名稱，API訪問路徑，API方法類型等信息。在發(fā)布為API接口服務(wù)后，對于后端服務(wù)的API參數(shù)信息也需要進(jìn)行快速導(dǎo)入，以方便在API接口查詢中看到詳細(xì)的接口內(nèi)容定義。

在將后端業(yè)務(wù)服務(wù)發(fā)布為API接口服務(wù)的時(shí)候，發(fā)布的代理服務(wù)要自動增加系統(tǒng)級的輸入?yún)?shù)信息，這個(gè)輸入?yún)?shù)最好的方式是在訪問路徑中進(jìn)行增加，以減少對已有的后端服務(wù)的影響。

API接口在注冊和接入完成后，將自動進(jìn)行服務(wù)部署和服務(wù)發(fā)布，即注冊接入完成后的服務(wù)可以通過發(fā)布的訪問路徑地址進(jìn)行訪問。

API接口在線模擬測試功能

這個(gè)功能參考當(dāng)前的OpenAPI能力開放平臺的做法來實(shí)現(xiàn)即可。即對于已經(jīng)發(fā)布完成的API接口服務(wù)，提供在線測試工具進(jìn)行在線測試。同時(shí)對接口服務(wù)調(diào)用的輸入?yún)?shù)進(jìn)行結(jié)構(gòu)化展示，方便用戶對測試需要的各種參數(shù)進(jìn)行輸入。在輸入完成后形成完整的提交參數(shù)完整字符串。通過測試，可以返回最終的模擬調(diào)用返回結(jié)果字符串信息。

API接口查詢功能

對于API接口查詢功能也是一個(gè)標(biāo)準(zhǔn)的功能，實(shí)際上可以考慮將查詢功能和API接口服務(wù)的分類瀏覽分開。對于API接口的分類瀏覽參考開放平臺的API接口文檔做法來實(shí)現(xiàn)接口。對于API接口查詢，即可以設(shè)置不同的動態(tài)查詢條件，對API接口進(jìn)行查詢，返回結(jié)果集。對于查詢到的API接口清單列表，可以點(diǎn)擊詳細(xì)進(jìn)入到API接口詳細(xì)的輸入和輸出信息查看界面。

API狀態(tài)管理功能

對于已經(jīng)注冊和發(fā)布的API接口可以對其狀態(tài)進(jìn)行管理。其中主要的狀態(tài)包括了待發(fā)布，上線，暫停，下線廢棄等幾種關(guān)鍵狀態(tài)。對于API狀態(tài)本身還需要和后續(xù)的API監(jiān)控管理結(jié)合，能夠通過API性能監(jiān)控動態(tài)的調(diào)整API接口的狀態(tài)。比如在API觸發(fā)熔斷后，自動對API接口狀態(tài)調(diào)整為暫停。

API版本管理能力

對于API需要啟用版本管理能力。當(dāng)前一些API接口服務(wù)實(shí)現(xiàn)方法會在路徑參數(shù)中增加API版本信息，以確定究竟訪問哪個(gè)版本。但是由于不同的API版本可能存在返回的結(jié)果集的數(shù)據(jù)結(jié)構(gòu)不一樣的問題，因此對于這種場景需要針對該API定義不同的大版本，不同的大版本實(shí)際上對應(yīng)不同的后端原始服務(wù)。

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

對于Oracle的SOA治理，為了實(shí)現(xiàn)業(yè)務(wù)、企業(yè)架構(gòu) 和 SOA 目標(biāo)，必須在不同業(yè)務(wù)領(lǐng)域制定策略：體系結(jié)構(gòu)、技術(shù)基礎(chǔ)架構(gòu)、信息、財(cái)務(wù)、組合、人員、項(xiàng)目（或項(xiàng)目的執(zhí)行方式）和運(yùn)營。其比較明顯的特點(diǎn)是體現(xiàn)了EA企業(yè)架構(gòu)，業(yè)務(wù)架構(gòu)對SOA治理活動的影響和推動。而IBM的SOA 治理和管理方法（SOA Governance and Management Method，SGMM）是一種端到端的定義方法，通過設(shè)計(jì)、實(shí)現(xiàn)和改進(jìn) SOA 治理來進(jìn)行。IBM的治理生命周期將治理活動分為了計(jì)劃，定義，使能和度量四個(gè)階段，涉及到服務(wù)生命周期各個(gè)方面的內(nèi)容，具體如下：

服務(wù)定義，包括服務(wù)的范圍、接口和邊界服務(wù)部署生命周期服務(wù)版本治理，包括兼容性服務(wù)遷移, 包括棄用和退役服務(wù)注冊中心，包括依賴關(guān)系服務(wù)消息模型，包括規(guī)范數(shù)據(jù)模型服務(wù)監(jiān)視，包括進(jìn)行問題確定服務(wù)所有權(quán)，包括合作組織服務(wù)測試，包括重復(fù)測試服務(wù)安全, 包括可接受的保護(hù)范圍

對于Oracle和IBM的治理進(jìn)行對比分析，不斷發(fā)現(xiàn)存在的一些相同點(diǎn)。從方法上看都覆蓋了傳統(tǒng)的項(xiàng)目管理，SOA服務(wù)工程框架，ITIL運(yùn)維管理三個(gè)方面的內(nèi)容。從范圍上看則包括了組織人員，業(yè)務(wù)技術(shù)和管理三個(gè)方面的內(nèi)容。而從流程上面可以講是覆蓋了服務(wù)全生命周期，包括服務(wù)識別發(fā)現(xiàn)，定義設(shè)計(jì)，開發(fā)測試，上線的前生命周期，也包括了服務(wù)開通，運(yùn)維，監(jiān)控的后生命周期。基于以上分析，可以看到SOA治理是一個(gè)覆蓋服務(wù)全生命周期，涉及業(yè)務(wù)域，服務(wù)域和支撐過程域三個(gè)方面內(nèi)容的完整治理框架和模型。如上圖所描述一樣，通過這種二維的結(jié)構(gòu)，基本上可以看到SOA治理和管控所涉及的全部內(nèi)容。基于該業(yè)務(wù)目標(biāo)架構(gòu)，SOA治理和管控又包括了如下關(guān)鍵內(nèi)容：服務(wù)全生命周期管理中心SOA治理和管控一定要能夠?qū)Ψ?wù)全生命周期進(jìn)行很好的管理，廣義點(diǎn)的需要從企業(yè)業(yè)務(wù)目標(biāo)和流程目標(biāo)入手，到流程分析和需求分析，到服務(wù)識別和發(fā)現(xiàn)，到服務(wù)定義和設(shè)計(jì)，服務(wù)開發(fā)測試，服務(wù)上線的全過程有效的管理。對于服務(wù)識別和定義階段，需要對業(yè)務(wù)域，服務(wù)目錄，服務(wù)進(jìn)行相應(yīng)的元數(shù)據(jù)定義，以形成服務(wù)目錄庫。而服務(wù)目錄庫是后續(xù)服務(wù)使用和檢索，服務(wù)設(shè)計(jì)開發(fā)測試的基本依據(jù)。能力提供中心SOA提供的服務(wù)本身就是一種能力，提能力提供中心的意義就在于要將服務(wù)轉(zhuǎn)化為一種能力進(jìn)行提供。達(dá)到業(yè)務(wù)組件化，組件能力化的目標(biāo)。只要這樣才能夠更好的推進(jìn)服務(wù)的重用，服務(wù)的編排和整合。對于能力提供中心包括了兩個(gè)方面的內(nèi)容，一個(gè)是服務(wù)前生命周期的管理可以實(shí)現(xiàn)服務(wù)的入庫，服務(wù)入庫后即轉(zhuǎn)變?yōu)榉?wù)的能力提供。那么對于需求方可以對服務(wù)資產(chǎn)庫進(jìn)行檢索，查看自己需要使用的能力，然后進(jìn)行服務(wù)申請，服務(wù)開通和使用。運(yùn)維監(jiān)控中心運(yùn)維監(jiān)控中心可以參考ITIL的標(biāo)準(zhǔn)進(jìn)行構(gòu)建，包括了事件管理，問題管理，變更管理，性能分析和監(jiān)控，SLA管理，配置管理庫等基本內(nèi)容。運(yùn)維監(jiān)控中心是保證SOA平臺能夠高可用運(yùn)行的基礎(chǔ)。通過運(yùn)維監(jiān)控中心一方面是解決服務(wù)使用過程中遇到的問題，一方面是通過預(yù)警規(guī)則和策略的設(shè)置，能夠及時(shí)的預(yù)警SOA平臺存在的潛在問題，保證平臺的高可用性。