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

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

API全生命周期管理

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

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

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

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

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

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

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

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

對象建模和API接口契約

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

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

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

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

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

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

前面講到了，既可以是數(shù)據(jù)庫直接逆向?qū)ο螅部梢允窃趯ο蠼Ｍ瓿珊?，將對象適配到數(shù)據(jù)庫。完成對象和數(shù)據(jù)庫表之間的映射。一個(gè)對象可以映射到多張數(shù)據(jù)庫表，因此在映射過程中除了完成數(shù)據(jù)庫表和字段映射外，還需要完成主外鍵關(guān)聯(lián)關(guān)系的映射操作。

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

API接口發(fā)布

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

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

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

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

API接口文檔生成

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

對象常用接口操作

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

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

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

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

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

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

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

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

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

分頁支持

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

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

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

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

即在API快速開發(fā)平臺(tái)能夠進(jìn)行API接口的自定義，詳細(xì)的定義API接口的輸入?yún)?shù)和輸出參數(shù)信息。同時(shí)對于定義完成的接口實(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語句查詢的輸出結(jié)果和API接口定義的輸出字段進(jìn)行映射。

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

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

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

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

規(guī)則處理

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

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

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

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

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

自定義腳本語言

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

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

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

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

服務(wù)組合和編排

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

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

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

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

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

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

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

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

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

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

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

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

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

這個(gè)是我們經(jīng)常看到的一種服務(wù)編排場景，即A，B，C三個(gè)服務(wù)直接進(jìn)行編排，即A服務(wù)的輸出直接變?yōu)锽服務(wù)的輸入，B服務(wù)的輸出又變?yōu)镃服務(wù)的輸出。如果僅僅是上面假設(shè)的這樣，那么這種流程式的服務(wù)編排仍然很簡單，也很容易去實(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ì)遇到的場景，比如我們在進(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)行前端功能開發(fā)時(shí)候服務(wù)進(jìn)行組裝的邏輯。

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

這個(gè)場景實(shí)際上和場景1是對應(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)入。

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

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

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

源代碼導(dǎo)出

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

對于導(dǎo)出的源代碼，考慮到后續(xù)API接口變更的場景，建議是對擴(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ù)前還可以對輸出的數(shù)據(jù)進(jìn)一步進(jìn)行處理和加工。

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

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

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

END



歷史推薦
Elasticsearch用得好，下班下得早！攜程、滴滴、今日頭條、餓了么、360、小米、Vivo 應(yīng)用實(shí)踐合集！
愛奇藝的 "數(shù)據(jù)庫" 選型到底有多牛？
京東推出輕量級(jí)分布式 RPC 框架 — EasyRPC
點(diǎn)個(gè)在看吧