從分層架構(gòu)到微服務(wù)架構(gòu)介紹（五）

本文要介紹的是 服務(wù)化架構(gòu) （Service-Based Architecture， SBA ）。

SBA 可以看成是單體架構(gòu)和微服務(wù)架構(gòu)之間的一個(gè)折中方案，它也是按照業(yè)務(wù)領(lǐng)域進(jìn)行服務(wù)劃分，但服務(wù)劃分的粒度相比微服務(wù)要更粗。SBA 與微服務(wù)架構(gòu)一大不同是， 它允許各個(gè)服務(wù)間共享同一個(gè)數(shù)據(jù)庫實(shí)例 ，這也使得 SBA 在架構(gòu)上既有單體架構(gòu)的特點(diǎn)，也有分布式架構(gòu)的特點(diǎn)，顯得更加的靈活。因此， 從單體架構(gòu)演進(jìn)到 SBA，會(huì)比直接演進(jìn)到微服務(wù)架構(gòu)更加容易 。

架構(gòu)視圖

基礎(chǔ)視圖

SBA 的基礎(chǔ)架構(gòu)視圖分成 3 部分：

• User Interface ，作為系統(tǒng)的接入口，接收客戶端的請(qǐng)求，并轉(zhuǎn)發(fā)到業(yè)務(wù)服務(wù)。。
• Domain Services ，業(yè)務(wù)服務(wù)按照領(lǐng)域進(jìn)行劃分，分開部署、業(yè)務(wù)獨(dú)立。
• Database ，服務(wù)間共享的數(shù)據(jù)庫實(shí)例，因?yàn)閿?shù)據(jù)庫實(shí)例只有一個(gè)，所以可以支持 ACID 事務(wù)。

使用 SBA 的系統(tǒng)通常只會(huì)劃分 4 ～ 12 個(gè)服務(wù)，避免產(chǎn)生過多的數(shù)據(jù)庫連接。服務(wù)數(shù)量不多，也決定了 SBA 中的服務(wù)相比微服務(wù)架構(gòu)中的服務(wù)有著更粗的粒度。User Interface 與服務(wù)間通過遠(yuǎn)程通信協(xié)議來完成業(yè)務(wù)往來，常見的通信方式有REST、RPC、消息隊(duì)列等。需要注意的是， SBA 是不允許服務(wù)間通信的 ，這與微服務(wù)架構(gòu)有著本質(zhì)的區(qū)別。

大多數(shù)情況下， SBA 中的服務(wù)只有一個(gè)或者少量實(shí)例 ，與微服務(wù)動(dòng)輒成百上千個(gè)實(shí)例有著很大的區(qū)別。主要是因?yàn)?SBA 服務(wù)粒度更粗，無法做到像微服務(wù)那樣精準(zhǔn)的按需擴(kuò)容，擴(kuò)容太多反而會(huì)導(dǎo)致資源的浪費(fèi)。

SBA 的另一大特點(diǎn)是允許所有服務(wù)共享同一數(shù)據(jù)庫實(shí)例 ，使得它能夠直接將傳統(tǒng)單體架構(gòu)的那一套 SQL 查詢邏輯、ACID 事務(wù)搬過來，讓架構(gòu)的演進(jìn)更加的平滑。不過，共享數(shù)據(jù)也會(huì)帶來一些問題，比如數(shù)據(jù)模型變更的影響范圍更大，后面會(huì)在“ 數(shù)據(jù)拆分” 一節(jié)詳細(xì)講述。

拆分 User Interface

在大型系統(tǒng)中，單一的 User Interface 可能導(dǎo)致代碼耦合、性能瓶頸等問題，這時(shí)候我們可以進(jìn)一步對(duì)它進(jìn)行拆分。拆分的方法可以是 基于業(yè)務(wù)領(lǐng)域的拆分 ，業(yè)務(wù)相關(guān)的幾個(gè)服務(wù)使用同一個(gè) User Interface；或者 基于服務(wù)的拆分 ，為每個(gè)服務(wù)都配備一個(gè) User Interface。

拆分 Database

類似地，我們也可以對(duì)數(shù)據(jù)庫進(jìn)行拆分，可以拆分成幾個(gè)服務(wù)共享一個(gè)實(shí)例；也可以像微服務(wù)架構(gòu)中那樣，每個(gè)服務(wù)獨(dú)享一個(gè)實(shí)例。數(shù)據(jù)庫拆分的原則就是： 確保數(shù)據(jù)是解耦的，不會(huì)被其他服務(wù)所依賴 ，避免出現(xiàn)跨庫查詢或服務(wù)間通信。

增加 API 網(wǎng)關(guān)

我們也可以在 User Interface 和 Domain Services 之間增加一個(gè) API 網(wǎng)關(guān)層，提供流控、鑒權(quán)、指標(biāo)統(tǒng)計(jì)、服務(wù)發(fā)現(xiàn)等公共能力，進(jìn)一步提升系統(tǒng)架構(gòu)的安全性、可靠性、可維護(hù)性。

業(yè)務(wù)服務(wù)的設(shè)計(jì)

SBA 中的服務(wù)具有較粗的粒度，因此在業(yè)務(wù)服務(wù)的架構(gòu)設(shè)計(jì)上通常也會(huì)用到一些單體架構(gòu)模式，常見的有分層架構(gòu)和基于領(lǐng)域的 組件化架構(gòu) 。

不管是分層架構(gòu)還是組件化架構(gòu)，通常都需要增加一個(gè) API 層，負(fù)責(zé)編排和轉(zhuǎn)發(fā)來自 User Interface 的業(yè)務(wù)請(qǐng)求。下面以訂單創(chuàng)建流程作為示例。

假設(shè)現(xiàn)在有一個(gè)訂單服務(wù) OrderService，當(dāng)它的 API 層接收到來自 User Interface 的訂單創(chuàng)建請(qǐng)求時(shí)，API 層協(xié)調(diào)會(huì)各個(gè)組件依次完成如下的幾個(gè)業(yè)務(wù)流程 ：

1. 調(diào)用訂單組件，完成訂單ID、訂單內(nèi)容的生成。
2. 調(diào)用支付組件，完成用戶的扣款。
3. 調(diào)用庫存組件，更新商品的庫存數(shù)量。

因?yàn)檫@些業(yè)務(wù)流程都是在同一個(gè)服務(wù)內(nèi)完成，當(dāng)其中的某個(gè)流程異常后，我們很容易通過數(shù)據(jù)庫的 ACID 事務(wù)來完成回滾，從而能夠確保 數(shù)據(jù)的強(qiáng)一致性 。

相比在微服務(wù)架構(gòu)之下，訂單創(chuàng)建請(qǐng)求往往需要訂單微服務(wù)、支付微服務(wù)、庫存微服務(wù)之間協(xié)作來完成，這就涉及到分布式事務(wù)，也即 BASE（Basic Availability, Soft state, Eventual consistency） 事務(wù)。BASE 事務(wù)更加的復(fù)雜，而且無法保證數(shù)據(jù)的強(qiáng)一致性。

當(dāng)然，更粗的服務(wù)粒度也會(huì)帶來 服務(wù)可用性問題 ，比如在訂單服務(wù)例子中，你會(huì)因?yàn)橛唵蜪D生成邏輯的變更而升級(jí)整個(gè)服務(wù)，也會(huì)因?yàn)閹齑娼M件中的一個(gè)BUG導(dǎo)致整個(gè)服務(wù)的故障。

所以，服務(wù)粒度的粗與細(xì)，實(shí)際上也是數(shù)據(jù)一致性和服務(wù)可用性的一次 trade-off 。

數(shù)據(jù)拆分

服務(wù)間共享數(shù)據(jù)庫使得系統(tǒng)具有更強(qiáng)的數(shù)據(jù)完整性和一致性，但簡(jiǎn)單的單庫單表數(shù)據(jù)模型會(huì)帶來耦合的問題。

在單庫單表的模型下，我們大概率會(huì)這么實(shí)現(xiàn)，將與數(shù)據(jù)庫操作相關(guān)的實(shí)體對(duì)象、SQL 邏輯全部封裝在一個(gè)共享的 shared lib 庫上，供所有業(yè)務(wù)服務(wù)復(fù)用：

這樣的實(shí)現(xiàn)方式雖然簡(jiǎn)單，但是會(huì)帶來“ 牽一發(fā)而動(dòng)全身 ”的問題。假設(shè)某個(gè)服務(wù)所用到的某個(gè)字段類型需要變化，勢(shì)必會(huì)修改表結(jié)構(gòu)和 shared lib 庫，而這兩者是所有服務(wù)共用的，因此也就會(huì)導(dǎo)致所有服務(wù)都需要升級(jí)重新上線。這樣的耦合會(huì)給 SRE 帶來極大的困擾，一點(diǎn)也不 敏捷 。

更好的方法是 根據(jù)業(yè)務(wù)對(duì)數(shù)據(jù)進(jìn)行拆分 ，將相對(duì)獨(dú)立的數(shù)據(jù)拆分成多個(gè)表，每個(gè)表都有一個(gè)獨(dú)立的 lib 庫，對(duì)于公共表，則有一個(gè) common lib 庫，各服務(wù)按需依賴。對(duì)于 common lib 庫的變更，我們還可以通過版本控制來盡量降低影響范圍，但必須在 common lib 進(jìn)行版本升級(jí)時(shí) 保持向后兼容 。

SBA 雖然是分布式架構(gòu)，但是也保留了單體架構(gòu)下的一些特點(diǎn)，在架構(gòu)上具有較高的靈活性，也使得它在各方面的評(píng)分都比較高，沒有明顯的缺點(diǎn)。

SBA 是一個(gè) domain-partitioned 的架構(gòu)，因此適合使用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)來進(jìn)行領(lǐng)域限界上下文的劃分，進(jìn)而規(guī)劃出業(yè)務(wù)獨(dú)立的服務(wù)。服務(wù)間業(yè)務(wù)獨(dú)立，而且不會(huì)相互間通信，也就意味著具有更好的 Testability 。

前文有提到過，SBA 雖然支持服務(wù)實(shí)例擴(kuò)容，但是更粗的服務(wù)粒度會(huì)導(dǎo)致擴(kuò)容的性價(jià)比并不高，因此 Scalability 和 Elasticity 得分不高。

Scalability 和 Elasticity的差異：

• Scalability 通常指軟件系統(tǒng)在不中斷業(yè)務(wù)的前提下，通過 scale-up 或 scale-out 等手段來應(yīng)對(duì)更高業(yè)務(wù)負(fù)載，強(qiáng)調(diào)的是軟件系統(tǒng)應(yīng)對(duì)高負(fù)載的能力。
• Elasticity 通常指硬件系統(tǒng)能夠根據(jù)實(shí)際的業(yè)務(wù)負(fù)載情況，適時(shí)增加或減少硬件資源，強(qiáng)調(diào)的是硬件資源的高效利用。

總結(jié)

如果你打算從單體架構(gòu)演進(jìn)到分布式架構(gòu)，SBA 會(huì)是一個(gè)不錯(cuò)的選擇 ：

• 相比單體架構(gòu)，SBA 按照業(yè)務(wù)進(jìn)行服務(wù)拆分，在業(yè)務(wù)解耦、開發(fā)流程敏捷等方面有著明顯的優(yōu)勢(shì)。
• 相比其他分布式架構(gòu)，SBA 有著更粗的服務(wù)粒度，因此也得以減少了服務(wù)間的遠(yuǎn)程調(diào)用、網(wǎng)絡(luò)帶寬消耗，受網(wǎng)絡(luò)故障的影響更小。
• 服務(wù)間共享數(shù)據(jù)庫使得 SBA 支持 ACID 事務(wù)，在數(shù)據(jù)一致性方面具有良好的表現(xiàn)，但我們還是應(yīng)該盡量按照業(yè)務(wù)進(jìn)行分表，避免出現(xiàn)嚴(yán)重的數(shù)據(jù)耦合。
• 在架構(gòu)評(píng)分上，SBA 各方面評(píng)分都不錯(cuò)，沒有明顯的缺點(diǎn)，是典型的“ 六邊形戰(zhàn)士 ”。