[[441661]]

【51CTO.com快譯】您一定對(duì)RESTful API并不陌生吧。它為客戶端應(yīng)用提供了一種能夠滿足業(yè)務(wù)需求的、訪問(wèn)數(shù)據(jù)資源的簡(jiǎn)單方式。事實(shí)上，Angular、React和Vue等都是依賴RESTful API的Javascript框架，它們引領(lǐng)著Web應(yīng)用的市場(chǎng)。

從效果上說(shuō)，此類RESTful服務(wù)類型的API和前端Javascript框架模式的配合，激發(fā)了許多組織從單一(monolithic)或過(guò)時(shí)的應(yīng)用程序，遷移到新項(xiàng)目中的愿望。當(dāng)然，凡事都有利與弊，RESTful API在助推敏捷迭代式開(kāi)發(fā)的同時(shí)，也帶來(lái)了一個(gè)問(wèn)題：在傳統(tǒng)的應(yīng)用設(shè)計(jì)中，我們雖然可以使用多個(gè)RESTful API和Javascript框架的組件化客戶端，但是也使用著單一的數(shù)據(jù)庫(kù)。這種設(shè)計(jì)的結(jié)果往往會(huì)導(dǎo)致數(shù)據(jù)所有權(quán)的沖突、高于預(yù)期的數(shù)據(jù)庫(kù)連接數(shù)、以及對(duì)大型數(shù)據(jù)庫(kù)過(guò)高的支持與維護(hù)成本。

下圖展示了多個(gè)服務(wù)競(jìng)爭(zhēng)來(lái)自單個(gè)數(shù)據(jù)庫(kù)資源的情況：

而且，此類現(xiàn)象在開(kāi)發(fā)領(lǐng)域十分常見(jiàn)。大家會(huì)傾向于將單個(gè)數(shù)據(jù)庫(kù)作用并服務(wù)于整個(gè)微服務(wù)的集合。

微服務(wù)應(yīng)該從數(shù)據(jù)庫(kù)開(kāi)始

在大多數(shù)編程語(yǔ)言中，我們通?？梢允褂脝蝹€(gè)的文件，去創(chuàng)建功能齊全的應(yīng)用程序。例如在Java中，一切都可以被放置在同一個(gè)類的文件中，并且由簡(jiǎn)單的main()方法實(shí)現(xiàn)統(tǒng)領(lǐng)和調(diào)用：

Java 
public class SingleClassApplication { 
    public static void main(String[] args) { 
        // Start doing something really cool here 
    } 
} 

但是，這種方法并不利于多個(gè)開(kāi)發(fā)人員通過(guò)協(xié)作的方式貢獻(xiàn)代碼。就應(yīng)用程序的各個(gè)方面而言，我們需要關(guān)注“所有權(quán)”(或系統(tǒng)記錄)的概念。如果不止一項(xiàng)服務(wù)或功能對(duì)賬戶等組件存在著交叉所有權(quán)的話，那么我們的業(yè)務(wù)規(guī)則可能會(huì)在不同的場(chǎng)景下出現(xiàn)混亂的局面。例如，在RESTful API聲明對(duì)于某個(gè)給定對(duì)象的所有權(quán)時(shí)，就可能發(fā)生類似的情況。而且，當(dāng)我們采取RESTful API的設(shè)計(jì)模式時(shí)，這些概念都需要被轉(zhuǎn)化到數(shù)據(jù)庫(kù)的層面上。對(duì)此，我們需要遵從如下規(guī)則：

將單個(gè)RESTful API視為某個(gè)應(yīng)用在給定方面的記錄系統(tǒng)(system of record)，以便相應(yīng)的數(shù)據(jù)層僅專注和使用應(yīng)用在該方面的數(shù)據(jù)存儲(chǔ)。

下圖展示了遵循該規(guī)則的微服務(wù)設(shè)計(jì)：

據(jù)此，那些為了滿足客戶需求，而對(duì)給定服務(wù)采取的擴(kuò)展，不會(huì)對(duì)任何其他的服務(wù)產(chǎn)生影響。這便是優(yōu)秀的、針對(duì)微服務(wù)的數(shù)據(jù)庫(kù)設(shè)計(jì)實(shí)踐。

數(shù)據(jù)庫(kù)的各種約束

在開(kāi)發(fā)過(guò)程中，我力推將給定的微服務(wù)與專用數(shù)據(jù)庫(kù)相隔離。這能夠保證相關(guān)組件的數(shù)量和大小，能夠與用戶需求相匹配，同時(shí)避免具有不同需求水平的元素產(chǎn)生額外的成本。

數(shù)據(jù)庫(kù)管理員往往會(huì)發(fā)現(xiàn)，當(dāng)應(yīng)用程序的所有元素都駐留在單個(gè)數(shù)據(jù)庫(kù)中時(shí)，各種約束和關(guān)系能夠很好地在單個(gè)數(shù)據(jù)庫(kù)的設(shè)計(jì)模式中發(fā)揮作用。例如，如果有與客戶相關(guān)聯(lián)的訂單在排隊(duì)等待刪除的話，那么單一數(shù)據(jù)庫(kù)的設(shè)計(jì)就會(huì)阻止刪除某個(gè)客戶的請(qǐng)求，畢竟該用戶的訂單尚未“結(jié)清”。

雖然這絕對(duì)是擁有單個(gè)數(shù)據(jù)庫(kù)的好處，但在選擇為所有微服務(wù)使用單個(gè)數(shù)據(jù)庫(kù)之前，您需要考慮如下幾點(diǎn)：

• 將使用單個(gè)數(shù)據(jù)庫(kù)可能獲得的長(zhǎng)期價(jià)值，與擴(kuò)展單個(gè)大型數(shù)據(jù)庫(kù)的相關(guān)成本進(jìn)行比較，以了解未來(lái)擴(kuò)展和支持單一數(shù)據(jù)庫(kù)設(shè)計(jì)的預(yù)期成本。
• 在API層強(qiáng)制實(shí)施各類約束的利與弊。請(qǐng)記住，由于單個(gè)微服務(wù)將被視為給定數(shù)據(jù)庫(kù)的所有者，因此在業(yè)務(wù)邏輯上可能會(huì)出現(xiàn)上述提到的，不允許刪除帶有活躍訂單的客戶的情況。
• 對(duì)于事件驅(qū)動(dòng)(或基于消息)的設(shè)計(jì)而言，某個(gè)微服務(wù)如何處理請(qǐng)求，取決于來(lái)自另一個(gè)微服務(wù)的響應(yīng)情況。雖然這與單個(gè)應(yīng)用程序+單個(gè)數(shù)據(jù)庫(kù)的設(shè)計(jì)有著相似之處，但需要在隔離和控制時(shí)，具有一定的擴(kuò)展和分配專用處理算力的能力。

當(dāng)然，做為一種良好的開(kāi)發(fā)習(xí)慣，即使是數(shù)據(jù)庫(kù)僅支持某個(gè)專用的服務(wù)實(shí)例，我們也應(yīng)該實(shí)施和強(qiáng)制執(zhí)行對(duì)應(yīng)的約束關(guān)系。

公共元素應(yīng)該被抽象出來(lái)

如果規(guī)劃不當(dāng)，采用真正的微服務(wù)設(shè)計(jì)也可能會(huì)產(chǎn)生副作用。例如在微服務(wù)中，包括認(rèn)證、緩存、日志記錄、監(jiān)控、以及安全在內(nèi)的各個(gè)公共組件元素，可能會(huì)與服務(wù)層相重復(fù)。

如上圖所示，在軟件開(kāi)發(fā)的生命周期中，人們往往會(huì)用不同的語(yǔ)言，去重復(fù)相同的軟件模式。對(duì)此，我們需要通過(guò)在應(yīng)用程序棧的公共級(jí)別、或不同級(jí)別，抽象和處理某些元素，來(lái)盡可能地避免DRY(不要重復(fù)自己)。在此，我推薦使用Kong的情況，進(jìn)而提供分布式的微服務(wù)抽象層。

將Kong置于理想的設(shè)計(jì)中心

Kong Gateway(允許開(kāi)發(fā)者將服務(wù)層API的復(fù)雜性，降低到專注于滿足業(yè)務(wù)需求和功能集合的各個(gè)端點(diǎn)(或 URI)處。由網(wǎng)關(guān)處理的諸如：身份驗(yàn)證、日志記錄和安全性等重復(fù)性組件，可以被Kong Gateway從服務(wù)層的設(shè)計(jì)中移出。

如下圖所示，每個(gè)RESTful微服務(wù)都維護(hù)著一個(gè)專用的數(shù)據(jù)庫(kù)實(shí)例，并且抽象出了各個(gè)重復(fù)的組件。這里所展示的便是一組以目的為驅(qū)動(dòng)(purpose-driven)的微服務(wù)：

開(kāi)發(fā)人員可以通過(guò)使用各種常見(jiàn)的企業(yè)集成模式(enterprise integration patterns)的消息傳遞層來(lái)，去處理服務(wù)間的通信，其中包括：

• 命令消息- 調(diào)用另一個(gè)服務(wù)來(lái)執(zhí)行后臺(tái)操作
• 文檔消息- 從另一個(gè)服務(wù)處請(qǐng)求信息
• 事件消息- 向偵聽(tīng)給定主題的任何一方，廣播信息
• 請(qǐng)求-回復(fù)- 向另一個(gè)服務(wù)發(fā)出請(qǐng)求，并偵聽(tīng)響應(yīng)

這樣的設(shè)計(jì)會(huì)給我們的應(yīng)用開(kāi)發(fā)帶來(lái)如下好處：

• 如果Node.js服務(wù)的使用率高于預(yù)期的話，則可以通過(guò)擴(kuò)展，來(lái)低成本地實(shí)現(xiàn)服務(wù)與專用數(shù)據(jù)庫(kù)的相互隔離。
• 如果任何服務(wù)發(fā)現(xiàn)了數(shù)據(jù)存儲(chǔ)模式從SQL更改為NoSQL，則可以在不更改RESTful API的URI的前提下，部署新的設(shè)計(jì)，而不會(huì)對(duì)任何其他服務(wù)產(chǎn)生影響。
• 任何抽象層組件的更改(例如，使用新的日志記錄方法)都可以在Kong Gateway層進(jìn)行，而不會(huì)影響到底層服務(wù)。

小結(jié)

開(kāi)發(fā)人員往往利用包和類，來(lái)對(duì)他們的程序代碼進(jìn)行分組，以實(shí)現(xiàn)可支持性和可維護(hù)性。在這些類中，定義方法和函數(shù)的規(guī)則是，每個(gè)代碼塊應(yīng)當(dāng)小且易于理解。這也正是“微服務(wù)”的“微”字的體現(xiàn)。其實(shí)不只是微服務(wù)，程序員也需要讓數(shù)據(jù)庫(kù)持續(xù)以微小、高效、以及目標(biāo)驅(qū)動(dòng)的方式進(jìn)行擴(kuò)展。

通過(guò)上述討論可知，Kong真正為微服務(wù)的設(shè)計(jì)提供了可擴(kuò)展、且易于采用的核心方式。而Kong Gateway則允許開(kāi)發(fā)人員引入通用組件，并駐留在分布式微服務(wù)的抽象層，以實(shí)現(xiàn)DRY。

原文標(biāo)題：Breaking Up a Monolithic Database with Kong，作者：John Vester

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】