如何理解文檔驅(qū)動(dòng)開發(fā)模式在AIMS中的應(yīng)用

本篇內(nèi)容主要講解“如何理解文檔驅(qū)動(dòng)開發(fā)模式在AIMS中的應(yīng)用”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“如何理解文檔驅(qū)動(dòng)開發(fā)模式在AIMS中的應(yīng)用”吧!

1. AI接口開發(fā)的特點(diǎn)

不同于傳統(tǒng)API的CRUD接口的開發(fā)，AI的開發(fā)模式通常包含了以下步驟：

• 數(shù)據(jù)清洗；

• 模型訓(xùn)練；

• 參數(shù)調(diào)優(yōu)；

• API上線。

前三項(xiàng)都是我們組的強(qiáng)項(xiàng)，也是我們的工作重點(diǎn)。但是在實(shí)際工作中，卻是API上線消耗了我們的大部分精力。AIMS項(xiàng)目組大都從事的是AI方向相關(guān)的工作，對(duì)于API的相關(guān)庫(kù)flask、tornado也不是很熟悉，這就導(dǎo)致開發(fā)人員需要花大量時(shí)間去了解網(wǎng)絡(luò)編程相關(guān)內(nèi)容，開發(fā)出來(lái)的程序質(zhì)量可能也不是很高。而且，在接口開發(fā)后，還需要準(zhǔn)備一份Swagger UI給前端的開發(fā)人員，這又是一項(xiàng)繁重的工作。為了解決如上所述的痛點(diǎn)問題，AI接口開發(fā)就需要滿足以下兩個(gè)特點(diǎn)和需求：

• API的核心函數(shù)是現(xiàn)成的；

• 需要將API開發(fā)工作量降到最低。

2. 文檔驅(qū)動(dòng)的開發(fā)模式

我們發(fā)現(xiàn)API的接口文檔中已經(jīng)包含了實(shí)現(xiàn)API接口的所有信息。也就是說(shuō)，API接口文檔的信息熵和API接口代碼的信息熵是一樣的。因此，我們只需要完成代碼或者文檔中的一項(xiàng)即可，另外一項(xiàng)可以交給框架自動(dòng)生成，這就避免了把同樣一件事情重復(fù)做兩遍的問題?？紤]到文檔不論從可讀性、易寫性還是可維護(hù)性都勝過(guò)代碼，我們決定寫文檔，然后根據(jù)文檔生成對(duì)應(yīng)的代碼。

我們參考了OpenAPI Specification3.0.1標(biāo)準(zhǔn)，以及JSON Schema定義了一套API描述語(yǔ)言，開發(fā)者基于這個(gè)API描述語(yǔ)言撰寫API文檔。當(dāng)完成文檔時(shí)，API的開發(fā)工作也隨之完成，大大節(jié)省了API接口的開發(fā)工作量。經(jīng)過(guò)初步估計(jì)，使用文檔驅(qū)動(dòng)模式開發(fā)一個(gè)API接口，通常可以減少40%–70%的工作量。

3. AIMS框架介紹

為了實(shí)現(xiàn)文檔驅(qū)動(dòng)的開發(fā)模式，AIMS基于tornado實(shí)現(xiàn)了一套Web后端框架，如下圖所示。

3.1. Application Router組件

每一個(gè)API都會(huì)有一個(gè)路徑，即一個(gè)正則表達(dá)式[1]。一個(gè)微服務(wù)中的多個(gè)API的所有路徑會(huì)組成一個(gè)API路徑列表。

當(dāng)Application Router接收到請(qǐng)求時(shí)，會(huì)根據(jù)請(qǐng)求中的URI在路由表中查找。如果匹配到某一個(gè)Request Handler，路由模塊會(huì)將請(qǐng)求轉(zhuǎn)發(fā)給響應(yīng)的Request Handler。如果所有的路徑都不匹配，則返回404結(jié)果[2]。

3.2. Request Handler組件

Request Handler處理來(lái)自Application Router的響應(yīng)，是AIMS架構(gòu)的核心，而Document則是Request Handler的核心。在AIMS架構(gòu)中，Document是指函數(shù)的文檔，即__doc__。Request Handler是在服務(wù)的啟動(dòng)階段動(dòng)態(tài)生成的。

事實(shí)上，在AIMS架構(gòu)圖中，只有Document是開發(fā)者必須寫的[3]。其它的組件都是由AIMS提供的，或者是由Document自動(dòng)生成的，所以AIMS開發(fā)模式也被稱為文檔驅(qū)動(dòng)型開發(fā)模式。開發(fā)者只需要維護(hù)Document即可，從而實(shí)現(xiàn)減少開發(fā)者工作量的目的。

3.3. Watchman組件

Watchman組件可以通過(guò)設(shè)置來(lái)訂閱某些接口的異常，當(dāng)被訂閱接口出現(xiàn)任何異常時(shí)，Exception Handler便會(huì)觸發(fā)Watchman組件。

因?yàn)镽ecorder組件記錄了Arguments，Watchman甚至可以自動(dòng)產(chǎn)生一個(gè)可以復(fù)現(xiàn)該問題的測(cè)試用例，方便開發(fā)人員定位問題。

3.4. Recorder組件

Recorder是一個(gè)采集器，可以采集每一次請(qǐng)求的所有細(xì)節(jié)信息，包括請(qǐng)求ID、請(qǐng)求參數(shù)、遠(yuǎn)程IP、被調(diào)用的接口、響應(yīng)時(shí)間、工作目錄和進(jìn)程號(hào)等各種信息。這些數(shù)據(jù)具有以下兩個(gè)作用:

• 系統(tǒng)的維護(hù)者可以利用Recorder中的數(shù)據(jù)快速定位，復(fù)現(xiàn)現(xiàn)網(wǎng)問題，可以看做是一個(gè)更強(qiáng)大的日志系統(tǒng)。

• 通過(guò)請(qǐng)求ID，訓(xùn)練數(shù)據(jù)收集系統(tǒng)可以將請(qǐng)求參數(shù)、響應(yīng)數(shù)據(jù)與用戶反饋數(shù)據(jù)關(guān)聯(lián)起來(lái)，這就相當(dāng)于是一條有標(biāo)記的數(shù)據(jù)。

3.5. Logger組件

Logger是AIMS封裝的日志模塊，用法和python自帶的logging.Logger使用方式一致，最大限度地降低開發(fā)者的學(xué)習(xí)成本。

4. 補(bǔ)充說(shuō)明

我們注意到，在AIMS架構(gòu)圖中，Argument Parser、Schema Checker、Swagger UI和OpenAPI Specification是同源的，即都是來(lái)自Document。這就不會(huì)出現(xiàn)文檔(Swagger UI、OpenAPI Specification)與函數(shù)實(shí)現(xiàn)(Argument Parser、Schema Checker)不一致的情況。開發(fā)者也不需要同時(shí)維護(hù)Argument Parser、Schema Checker、Swagger UI和OpenAPI Specification相關(guān)代碼。

以上就是文檔驅(qū)動(dòng)開發(fā)在AIMS框架中的優(yōu)勢(shì)，既降低了開發(fā)者的工作量，又解決了一致性的問題。事實(shí)證明，自動(dòng)產(chǎn)生的組件質(zhì)量也是優(yōu)于開發(fā)者自行開發(fā)的代碼，并且不易出錯(cuò)，從而提升整體服務(wù)的質(zhì)量以及穩(wěn)定性。

[1] 在AIMS開發(fā)中，這個(gè)字段是寫在__doc__中的api_path字段中。
[2] 事實(shí)上，路由模塊會(huì)將請(qǐng)求轉(zhuǎn)發(fā)給NotFoundRequestHandler，然后由NotFoundRequestHandler進(jìn)行響應(yīng)。
[3] 在AI相關(guān)微服務(wù)開發(fā)過(guò)程中，F(xiàn)unction，也就是核心功能函數(shù)，是已經(jīng)準(zhǔn)備好的。

到此，相信大家對(duì)“如何理解文檔驅(qū)動(dòng)開發(fā)模式在AIMS中的應(yīng)用”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！