在我之前談API網(wǎng)關(guān)的時(shí)候曾經(jīng)談到過(guò)快速開(kāi)發(fā)平臺(tái)，即將API快速開(kāi)發(fā)的一些內(nèi)容放入到API網(wǎng)關(guān)中，實(shí)際來(lái)看圍繞API全生命周期管理，本身包括了開(kāi)發(fā)態(tài)，運(yùn)行態(tài)，運(yùn)維態(tài)。

對(duì)于API網(wǎng)關(guān)更多的是解決運(yùn)行態(tài)的問(wèn)題，API網(wǎng)關(guān)本身應(yīng)該輕量化設(shè)計(jì)，不做太多的協(xié)議轉(zhuǎn)換，適配，數(shù)據(jù)映射等工作，這些工作應(yīng)該放到API開(kāi)發(fā)平臺(tái)來(lái)完成。API開(kāi)發(fā)平臺(tái)最終就是開(kāi)發(fā)完成并暴露一個(gè)標(biāo)準(zhǔn)的Http API接口，并將接口注冊(cè)和接入到API網(wǎng)關(guān)。

API全生命周期管理

圍繞API全生命周期管理來(lái)看，整個(gè)子系統(tǒng)劃分如下：

簡(jiǎn)單來(lái)講這部分可以分解為四個(gè)子系統(tǒng)，即API開(kāi)發(fā)平臺(tái)，API網(wǎng)關(guān)引擎，API監(jiān)控運(yùn)維平臺(tái)，API全生命周期管控平臺(tái)。

對(duì)于傳統(tǒng)ESB總線里面的適配器，協(xié)議轉(zhuǎn)換等相關(guān)比較重的內(nèi)容，都可以轉(zhuǎn)移到API快速開(kāi)發(fā)平臺(tái)來(lái)完成，即API開(kāi)發(fā)平臺(tái)暴露標(biāo)準(zhǔn)的API服務(wù)接口，注冊(cè)和接入到API網(wǎng)關(guān)引擎。而對(duì)于API監(jiān)控平臺(tái)則從引擎采集日志信息，進(jìn)行API性能監(jiān)控和日志監(jiān)控分析。

API全生命周期管控平臺(tái)實(shí)現(xiàn)API接口從設(shè)計(jì)，開(kāi)發(fā)，測(cè)試，部署上線的全生命周期管理，也可以理解為底層三個(gè)子系統(tǒng)的一個(gè)統(tǒng)一管理門(mén)戶，實(shí)現(xiàn)和下面三個(gè)子系統(tǒng)集成。

對(duì)于API開(kāi)發(fā)平臺(tái)開(kāi)發(fā)和配置完成的微服務(wù)API接口，可以支持自動(dòng)部署到微服務(wù)運(yùn)行平臺(tái)。

基于對(duì)象建模驅(qū)動(dòng)

在整個(gè)API開(kāi)發(fā)平臺(tái)實(shí)現(xiàn)中，核心思想仍然應(yīng)該是基于對(duì)象建模驅(qū)動(dòng)，通過(guò)對(duì)象建模很好的實(shí)現(xiàn)接口和底層數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)表之間的解耦，也方便實(shí)現(xiàn)底層多數(shù)據(jù)庫(kù)，多表的支持能力。

當(dāng)前很多API快速開(kāi)發(fā)平臺(tái)都是基于數(shù)據(jù)庫(kù)對(duì)象或表，直接發(fā)布類似CRUD的API接口服務(wù)，但是基于是數(shù)據(jù)庫(kù)表的直接發(fā)布，我們?nèi)匀唤ㄗh逆向?qū)ο筮@層，方便后續(xù)在對(duì)象層進(jìn)行相關(guān)的組合，規(guī)則擴(kuò)展等操作。

對(duì)象建模和API接口契約

可以直接在API開(kāi)發(fā)平臺(tái)創(chuàng)建對(duì)象，并對(duì)數(shù)據(jù)項(xiàng)進(jìn)行定義，對(duì)象是一個(gè)多層的樹(shù)狀結(jié)構(gòu)實(shí)體。一個(gè)對(duì)象可以向數(shù)據(jù)庫(kù)生成多張表。對(duì)于已經(jīng)存在的數(shù)據(jù)對(duì)象，也可以進(jìn)行組合，將多個(gè)組合為一個(gè)復(fù)合對(duì)象結(jié)構(gòu)。

對(duì)象的好處即是一個(gè)完整的對(duì)象屬于同一生命周期，可以一起進(jìn)行事務(wù)控制。

一個(gè)設(shè)計(jì)好的對(duì)象可以默認(rèn)生成標(biāo)準(zhǔn)的POST，GET，DELETE等接口操作方法，類似下圖，整個(gè)對(duì)象接口契約的生成也應(yīng)該是自動(dòng)的。

定義好的對(duì)象可以直接生成類似RAML,YAML,WADL等接口契約文件。

類似Swagger工具一樣，完成的對(duì)象建模本身也可以直接導(dǎo)出不同語(yǔ)言，不同開(kāi)發(fā)框架下的客戶端消費(fèi)框架，服務(wù)端提供框架代碼。

對(duì)象適配到數(shù)據(jù)庫(kù)

前面講到了，既可以是數(shù)據(jù)庫(kù)直接逆向?qū)ο?，也可以是在?duì)象建模完成后，將對(duì)象適配到數(shù)據(jù)庫(kù)。完成對(duì)象和數(shù)據(jù)庫(kù)表之間的映射。一個(gè)對(duì)象可以映射到多張數(shù)據(jù)庫(kù)表，因此在映射過(guò)程中除了完成數(shù)據(jù)庫(kù)表和字段映射外，還需要完成主外鍵關(guān)聯(lián)關(guān)系的映射操作。

在完成對(duì)象模型和數(shù)據(jù)庫(kù)表之間的映射和適配后，基本發(fā)布的API接口已經(jīng)可用。

API接口發(fā)布

對(duì)于完成的對(duì)象定義，可以選擇具體發(fā)布哪些API接口服務(wù)能力。比如可以只選擇發(fā)布查詢接口，也可以只選擇發(fā)布數(shù)據(jù)導(dǎo)入的POST接口等。

注意API接口的發(fā)布，具體可以基于全局的對(duì)象建模，配置具體需要發(fā)布到接口的數(shù)據(jù)項(xiàng)信息。很多時(shí)候我們對(duì)數(shù)據(jù)對(duì)象的操作，并不是操作整個(gè)對(duì)象全集，而僅僅是部分?jǐn)?shù)據(jù)項(xiàng)。

API接口模擬測(cè)試和驗(yàn)證

可以對(duì)發(fā)布的API接口進(jìn)行模擬測(cè)試和驗(yàn)證，因此需要提供在線的API測(cè)試工具，能夠方便在線進(jìn)行API接口的測(cè)試工作。同時(shí)可以對(duì)測(cè)試過(guò)的用例和測(cè)試數(shù)據(jù)進(jìn)行保存。

API接口文檔生成

支持自動(dòng)生成API接口文檔的能力。這個(gè)地方可以直接對(duì)接類似開(kāi)源Swagger等工具來(lái)實(shí)現(xiàn)API接口文檔的自動(dòng)生成功能。

對(duì)象常用接口操作

當(dāng)對(duì)象定義完成后，可以基于對(duì)象進(jìn)行相關(guān)API接口的自動(dòng)生成。在這里簡(jiǎn)單列下基于對(duì)象常用的接口方法，主要包括新增一條數(shù)據(jù)，基于主鍵更新，查詢，刪除數(shù)據(jù)。其它的則是基于條件查詢對(duì)數(shù)據(jù)進(jìn)行查詢相關(guān)操作等。

在GtiHub里面開(kāi)源又一個(gè)xmysql的工具，可以直接將整個(gè)mysql數(shù)據(jù)庫(kù)中的數(shù)據(jù)庫(kù)表發(fā)布為RestAPI接口，具體可以安裝試用。

npm install -g xmysql
xmysql -h localhost -u mysqlUsername -p mysqlPassword -d databaseName
http://localhost:3000

注意需要提前安裝Node.js，部分接口方法列表如下：

由于生成的API接口都沒(méi)有相關(guān)的權(quán)限控制，因此該開(kāi)源工具也僅僅用于自己測(cè)試和驗(yàn)證使用。但是生成的方法和API可以作為API開(kāi)發(fā)工具時(shí)候參考。

實(shí)際上對(duì)于API接口的生成，我們并不建議對(duì)于復(fù)雜查詢條件下的查詢都通過(guò)GET方法來(lái)實(shí)現(xiàn)，更好的思路還是通過(guò)POST方法，將查詢條件作為POST輸入進(jìn)行處理。

復(fù)合對(duì)象一次生成

比如將訂單作為一個(gè)對(duì)象，實(shí)際包括了訂單頭和訂單明細(xì)表，而在進(jìn)行API生成時(shí)候可以一次生成基于訂單對(duì)象的插入操作，查詢操作。最終查詢出來(lái)的是一個(gè)訂單復(fù)合實(shí)體Json數(shù)據(jù)。而對(duì)于訂單插入，也是先準(zhǔn)備好整個(gè)訂單實(shí)體信息，一次調(diào)用API接口完成數(shù)據(jù)插入，也方便在API接口實(shí)現(xiàn)的時(shí)候進(jìn)行事務(wù)控制。

復(fù)合對(duì)象生成的API接口更類似于領(lǐng)域?qū)ο蟊┞兜腁PI接口服務(wù)能力。

分頁(yè)支持

對(duì)于查詢API接口服務(wù)的生成，應(yīng)該支持分頁(yè)能力，具體分頁(yè)的大小，本次查詢?cè)L問(wèn)具體頁(yè)數(shù)等信息都可以作為API接口的查詢輸入?yún)?shù)進(jìn)行設(shè)置。

直接定義API接口并發(fā)布

在前面談到了基于對(duì)象來(lái)發(fā)布API接口服務(wù)，但是還有一些業(yè)務(wù)規(guī)則邏輯類接口，復(fù)雜的管理數(shù)據(jù)查詢類接口等并不能簡(jiǎn)單的通過(guò)對(duì)象來(lái)自動(dòng)生成。

因此還需要能夠?qū)崿F(xiàn)基于方法來(lái)發(fā)布API接口服務(wù)。

即在API快速開(kāi)發(fā)平臺(tái)能夠進(jìn)行API接口的自定義，詳細(xì)的定義API接口的輸入?yún)?shù)和輸出參數(shù)信息。同時(shí)對(duì)于定義完成的接口實(shí)現(xiàn)和后臺(tái)方法的綁定。

實(shí)現(xiàn)和JAR包里面的API接口的綁定

可以實(shí)現(xiàn)和一個(gè)JAR包里面方法或函數(shù)的綁定，將一個(gè)方法或函數(shù)發(fā)布為一個(gè)Http API接口方法。在當(dāng)前很多公有云的云服務(wù)總線產(chǎn)品上可以看到這個(gè)實(shí)現(xiàn)方式。

實(shí)現(xiàn)和動(dòng)態(tài)SQL的綁定

可以將定義的一個(gè)API接口方法和動(dòng)態(tài)SQL進(jìn)行綁定。其中動(dòng)態(tài)SQL本身具體動(dòng)態(tài)輸入?yún)?shù)，這些輸入?yún)?shù)和API接口定義中的輸入進(jìn)行數(shù)據(jù)映射。同時(shí)SQL語(yǔ)句查詢的輸出結(jié)果和API接口定義的輸出字段進(jìn)行映射。

如果動(dòng)態(tài)SQL是插入或更新類，同樣也可以通過(guò)參數(shù)化變量方式進(jìn)行數(shù)據(jù)映射和綁定操作。

和存儲(chǔ)過(guò)程進(jìn)行綁定

一個(gè)數(shù)據(jù)庫(kù)的存儲(chǔ)過(guò)程，實(shí)際即是一個(gè)方法函數(shù)，因此可以將API接口定義的輸入和輸出和數(shù)據(jù)庫(kù)存儲(chǔ)過(guò)程的輸入和輸出進(jìn)行映射綁定。

要注意的是針對(duì)不同的數(shù)據(jù)庫(kù)存儲(chǔ)過(guò)程schema信息獲取和適配本身有差異，這也是在上圖中構(gòu)建一個(gè)獨(dú)立的統(tǒng)一數(shù)據(jù)庫(kù)適配層的原因。

規(guī)則處理

在API接口開(kāi)發(fā)過(guò)程中，可以進(jìn)行一些簡(jiǎn)單的規(guī)則處理。具體如下：

輸入數(shù)據(jù)完整性校驗(yàn)

對(duì)輸入數(shù)據(jù)進(jìn)行完整性校驗(yàn)，其中包括場(chǎng)景的數(shù)據(jù)類型，長(zhǎng)度，范圍約束等，這些都是屬于比較容易通過(guò)配置進(jìn)行實(shí)現(xiàn)的內(nèi)容。

數(shù)據(jù)項(xiàng)間規(guī)則處理

可以對(duì)多個(gè)數(shù)據(jù)項(xiàng)進(jìn)行簡(jiǎn)單規(guī)則處理，其中包括了場(chǎng)景的數(shù)據(jù)映射，數(shù)據(jù)豐富，數(shù)據(jù)截取等。這些本身也是在主流的傳統(tǒng)ESB總線產(chǎn)品中都支持的內(nèi)容。

自定義腳本語(yǔ)言

對(duì)于API快速開(kāi)發(fā)平臺(tái)本身可以作為低代碼開(kāi)發(fā)平臺(tái)的一個(gè)子類，因此如果能夠支持自定義腳本語(yǔ)言進(jìn)行規(guī)則處理，那么整體擴(kuò)展性和靈活性也會(huì)得到大幅度提升。

消息頭和輸出預(yù)留

對(duì)于API開(kāi)發(fā)平臺(tái)發(fā)布的API接口，需要對(duì)輸入消息頭，輸出的異常類型，異常編碼，信息等字段進(jìn)行提前約定。

在輸入的消息頭中往往包括了類似用戶名，Token等用于訪問(wèn)安全校驗(yàn)的字段，也包括了類似路由，分頁(yè)等相關(guān)擴(kuò)展字段信息。對(duì)于輸出字段，需要對(duì)返回的異常類型，編碼，異常信息等進(jìn)行約定。特別是涉及到數(shù)據(jù)CUD操作的時(shí)候，需要按約定的輸出字段進(jìn)行輸出。

服務(wù)組合和編排

對(duì)于API開(kāi)發(fā)平臺(tái)還可以進(jìn)一步提供服務(wù)組合和服務(wù)編排的能力。這個(gè)能力的實(shí)現(xiàn)也不適合放在API網(wǎng)關(guān)來(lái)完成，而是應(yīng)該規(guī)劃到API開(kāi)發(fā)平臺(tái)來(lái)實(shí)現(xiàn)。

服務(wù)組合編排是服務(wù)組合，服務(wù)組裝等，希望通過(guò)服務(wù)編排能夠完成這些事情，而不是簡(jiǎn)單的完成單一服務(wù)的設(shè)計(jì)和開(kāi)發(fā)。**即將多個(gè)原子服務(wù)組合或組裝在一起，最終形成一個(gè)新的服務(wù)并提供的能力。**我們舉例來(lái)說(shuō)明下。

比如存在A，B，C三個(gè)原子服務(wù)，我們通過(guò)服務(wù)編排形成一個(gè)新的D服務(wù)。

三個(gè)原子服務(wù)全部是查詢服務(wù)，希望組裝一個(gè)新服務(wù)，一次返回A，B，C三個(gè)服務(wù)查詢結(jié)果

這個(gè)即我們說(shuō)的服務(wù)組合能力，比如我們可以對(duì)合同基本信息查詢，合同條款信息查詢，合同執(zhí)行信息查詢?nèi)齻€(gè)基本原子服務(wù)進(jìn)行組合，最終返回一個(gè)服務(wù)綜合信息查詢的服務(wù)，一次返回三個(gè)查詢結(jié)果。

在這種場(chǎng)景下我們需要考慮查詢結(jié)果是并行返回還是按層次返回即可。

二個(gè)查詢類的原子服務(wù)，最終需要返回兩個(gè)數(shù)據(jù)集關(guān)聯(lián)查詢的結(jié)果集

這個(gè)在微服務(wù)架構(gòu)做了底層數(shù)據(jù)庫(kù)拆分后經(jīng)常會(huì)遇到，比如對(duì)于物料基本信息查詢，和采購(gòu)訂單明細(xì)查詢是在兩個(gè)獨(dú)立的數(shù)據(jù)庫(kù)獨(dú)立服務(wù)提供。而我們希望返回的查詢結(jié)果集是物料編碼，名稱，型號(hào)，單位，價(jià)格，采購(gòu)數(shù)量的復(fù)合結(jié)果集。

這種場(chǎng)景下往往一般都是在前端功能開(kāi)發(fā)的時(shí)候進(jìn)行組裝，而實(shí)際上可以考慮是否可以在服務(wù)編排層解決這個(gè)問(wèn)題，該問(wèn)題寫(xiě)代碼來(lái)解決容易，但是要做為可視化服務(wù)編排組態(tài)方式來(lái)做實(shí)際上有一定的難度。

對(duì)單個(gè)已有服務(wù)進(jìn)行裁剪和豐富并形成一個(gè)新服務(wù)輸出

這個(gè)暫時(shí)也將其納入到服務(wù)編排的范疇，即仍然是輸入服務(wù)，但是輸出是提供了一個(gè)新服務(wù)。

即對(duì)單個(gè)已有的服務(wù)進(jìn)行服務(wù)裁剪和豐富，比如對(duì)于輸出結(jié)果過(guò)濾掉一些數(shù)據(jù)項(xiàng)，對(duì)于輸入固定輸入一些數(shù)據(jù)項(xiàng)等。這些簡(jiǎn)單的服務(wù)裁剪，豐富，或簡(jiǎn)單的數(shù)據(jù)轉(zhuǎn)換可以在服務(wù)編排的時(shí)候完成，并提供一個(gè)新服務(wù)。

對(duì)多個(gè)原子服務(wù)進(jìn)行流程式的前后串接并形成服務(wù)提供

這個(gè)是我們經(jīng)?？吹降囊环N服務(wù)編排場(chǎng)景，即A，B，C三個(gè)服務(wù)直接進(jìn)行編排，即A服務(wù)的輸出直接變?yōu)锽服務(wù)的輸入，B服務(wù)的輸出又變?yōu)镃服務(wù)的輸出。如果僅僅是上面假設(shè)的這樣，那么這種流程式的服務(wù)編排仍然很簡(jiǎn)單，也很容易去實(shí)現(xiàn)。

但是實(shí)際上的難點(diǎn)在于A服務(wù)的輸出本身也需要作為C服務(wù)的輸出，同時(shí)A，B服務(wù)的輸出也可能是整體輸出的一部分，這本身就加大了服務(wù)編排可視化設(shè)計(jì)的難度。

單一業(yè)務(wù)服務(wù)為主體服務(wù)，但是編排多個(gè)業(yè)務(wù)規(guī)則邏輯處理類服務(wù)

這也是經(jīng)常會(huì)遇到的場(chǎng)景，比如我們?cè)谶M(jìn)行合同信息導(dǎo)入的時(shí)候，首先要調(diào)用合同有效性校驗(yàn)服務(wù)，同時(shí)還有調(diào)用預(yù)算信息檢查和扣減服務(wù)進(jìn)行相關(guān)的完整性和業(yè)務(wù)規(guī)則校驗(yàn)。在這些校驗(yàn)完成后再調(diào)用實(shí)際的合同信息導(dǎo)入服務(wù)，如果校驗(yàn)失敗則直接返回失敗結(jié)果。

這類服務(wù)編排往往也正是我們實(shí)際在進(jìn)行前端功能開(kāi)發(fā)時(shí)候服務(wù)進(jìn)行組裝的邏輯。

多個(gè)導(dǎo)入服務(wù)組裝為一個(gè)導(dǎo)入服務(wù)合并導(dǎo)入并形成一個(gè)新服務(wù)

這個(gè)場(chǎng)景實(shí)際上和場(chǎng)景1是對(duì)應(yīng)的，既然多個(gè)服務(wù)可以組合后形成組合結(jié)果返回，那么自然可以將多個(gè)導(dǎo)入服務(wù)合并為一個(gè)導(dǎo)入服務(wù)，一次性的完成數(shù)據(jù)導(dǎo)入。

比如有項(xiàng)目信息導(dǎo)入和項(xiàng)目WBS信息導(dǎo)入兩個(gè)原子服務(wù)，那么我們就可以提供一個(gè)新的項(xiàng)目信息導(dǎo)入服務(wù)，一次完成項(xiàng)目基本信息和項(xiàng)目WBS信息的導(dǎo)入。

在這些場(chǎng)景里面可以看到，實(shí)際上服務(wù)編排就是服務(wù)串聯(lián)，服務(wù)并聯(lián)下的輸入和輸出合并，服務(wù)內(nèi)容豐富和裁剪等常見(jiàn)場(chǎng)景。在一個(gè)理想的場(chǎng)景下，我們最希望實(shí)現(xiàn)的就是一個(gè)業(yè)務(wù)功能點(diǎn)的實(shí)現(xiàn)完全能夠通過(guò)服務(wù)編排可視化設(shè)計(jì)方式來(lái)完成。

關(guān)于服務(wù)編排詳細(xì)說(shuō)明可以參考下文：

從ESB服務(wù)組合編排到NetflixConductor微服務(wù)編排

源代碼導(dǎo)出

對(duì)于API快速開(kāi)發(fā)平臺(tái)，很難去實(shí)現(xiàn)復(fù)雜的業(yè)務(wù)規(guī)則編碼。因此在存在復(fù)雜業(yè)務(wù)規(guī)則實(shí)現(xiàn)的時(shí)候仍然是建議開(kāi)發(fā)人員自己開(kāi)發(fā)代碼來(lái)完成。因此整個(gè)平臺(tái)應(yīng)該提供源代碼導(dǎo)出功能，導(dǎo)出的源代碼應(yīng)該直接能夠編譯通過(guò)，脫離API開(kāi)發(fā)平臺(tái)部署和運(yùn)行。

對(duì)于導(dǎo)出的源代碼，考慮到后續(xù)API接口變更的場(chǎng)景，建議是對(duì)擴(kuò)展部分進(jìn)行約定。

比如一個(gè)標(biāo)準(zhǔn)的API接口服務(wù)實(shí)現(xiàn)方法，可以在前后增加擴(kuò)展處理。

//BeforeDo();
//ProcessAPI();
//AfterDo();

這樣在接口實(shí)現(xiàn)前可以進(jìn)行額外的業(yè)務(wù)規(guī)則處理和完整性校驗(yàn)，在接口返回?cái)?shù)據(jù)前還可以對(duì)輸出的數(shù)據(jù)進(jìn)一步進(jìn)行處理和加工。

微服務(wù)應(yīng)用

可以將多個(gè)對(duì)象或多個(gè)API接口服務(wù)打包到一個(gè)微服務(wù)應(yīng)用再進(jìn)行部署和發(fā)布。因此在這里引入一個(gè)微服務(wù)集的概念，對(duì)微服務(wù)API進(jìn)行打包處理。

打包完成的微服務(wù)可以導(dǎo)出為獨(dú)立的JAR包進(jìn)行部署，也可以直接在API開(kāi)發(fā)平臺(tái)進(jìn)行托管部署。對(duì)于API開(kāi)發(fā)平臺(tái)本身應(yīng)該對(duì)接到微服務(wù)運(yùn)行平臺(tái)。

摘要: 原創(chuàng)出處 toutiao.com/i6914469326074479108 「人月聊IT」歡迎轉(zhuǎn)載，保留摘要，謝謝！

逆鋒起筆是一個(gè)專注于程序員圈子的技術(shù)平臺(tái)，你可以收獲最新技術(shù)動(dòng)態(tài)、最新內(nèi)測(cè)資格、BAT等大廠大佬的經(jīng)驗(yàn)、增長(zhǎng)自身、學(xué)習(xí)資料、職業(yè)路線、賺錢(qián)思維，微信搜索逆鋒起筆關(guān)注！

老舊的 API，該如何處理？

瞧瞧，人家那后端 API 接口寫(xiě)得多優(yōu)雅！

公司接口裸奔 10 年了，有必要用 API 接口簽名驗(yàn)證嗎？

App 開(kāi)放接口 api 安全：Token 簽名 sign 的設(shè)計(jì)與實(shí)現(xiàn)

徒手?jǐn)]了一個(gè) API 網(wǎng)關(guān)，理解更透徹了，代碼已上傳github，自取~