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

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

API全生命周期管理

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

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

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

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

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

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

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

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

對象建模和API接口契約

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

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

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

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

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

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

前面講到了，既可以是數(shù)據(jù)庫直接逆向?qū)ο?，也可以是在對象建模完成后，將對象適配到數(shù)據(jù)庫。完成對象和數(shù)據(jù)庫表之間的映射。一個對象可以映射到多張數(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ù)項信息。很多時候我們對數(shù)據(jù)對象的操作，并不是操作整個對象全集，而僅僅是部分?jǐn)?shù)據(jù)項。

API接口模擬測試和驗證

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

API接口文檔生成

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

對象常用接口操作

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

在GtiHub里面開源又一個xmysql的工具，可以直接將整個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)限控制，因此該開源工具也僅僅用于自己測試和驗證使用。但是生成的方法和API可以作為API開發(fā)工具時候參考。

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

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

比如將訂單作為一個對象，實際包括了訂單頭和訂單明細(xì)表，而在進(jìn)行API生成時候可以一次生成基于訂單對象的插入操作，查詢操作。最終查詢出來的是一個訂單復(fù)合實體Json數(shù)據(jù)。而對于訂單插入，也是先準(zhǔn)備好整個訂單實體信息，一次調(diào)用API接口完成數(shù)據(jù)插入，也方便在API接口實現(xiàn)的時候進(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ù)查詢類接口等并不能簡單的通過對象來自動生成。

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

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

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

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

實現(xiàn)和動態(tài)SQL的綁定

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

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

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

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

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

規(guī)則處理

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

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

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

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

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

自定義腳本語言

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

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

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

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

服務(wù)組合和編排

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

源代碼導(dǎo)出

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

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

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

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

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

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

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

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