本文要介紹的是 服務化架構 （Service-Based Architecture， SBA ）。

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

架構視圖

基礎視圖

SBA 的基礎架構視圖分成 3 部分：

• User Interface ，作為系統的接入口，接收客戶端的請求，并轉發到業務服務。。
• Domain Services ，業務服務按照領域進行劃分，分開部署、業務獨立。
• Database ，服務間共享的數據庫實例，因為數據庫實例只有一個，所以可以支持 ACID 事務。

使用 SBA 的系統通常只會劃分 4 ～ 12 個服務，避免產生過多的數據庫連接。服務數量不多，也決定了 SBA 中的服務相比微服務架構中的服務有著更粗的粒度。User Interface 與服務間通過遠程通信協議來完成業務往來，常見的通信方式有REST、RPC、消息隊列等。需要注意的是， SBA 是不允許服務間通信的 ，這與微服務架構有著本質的區別。

大多數情況下， SBA 中的服務只有一個或者少量實例 ，與微服務動輒成百上千個實例有著很大的區別。主要是因為 SBA 服務粒度更粗，無法做到像微服務那樣精準的按需擴容，擴容太多反而會導致資源的浪費。

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

拆分 User Interface

在大型系統中，單一的 User Interface 可能導致代碼耦合、性能瓶頸等問題，這時候我們可以進一步對它進行拆分。拆分的方法可以是 基于業務領域的拆分 ，業務相關的幾個服務使用同一個 User Interface；或者 基于服務的拆分 ，為每個服務都配備一個 User Interface。

拆分 Database

類似地，我們也可以對數據庫進行拆分，可以拆分成幾個服務共享一個實例；也可以像微服務架構中那樣，每個服務獨享一個實例。數據庫拆分的原則就是： 確保數據是解耦的，不會被其他服務所依賴 ，避免出現跨庫查詢或服務間通信。

增加 API 網關

我們也可以在 User Interface 和 Domain Services 之間增加一個 API 網關層，提供流控、鑒權、指標統計、服務發現等公共能力，進一步提升系統架構的安全性、可靠性、可維護性。

業務服務的設計

SBA 中的服務具有較粗的粒度，因此在業務服務的架構設計上通常也會用到一些單體架構模式，常見的有分層架構和基于領域的 組件化架構 。

不管是分層架構還是組件化架構，通常都需要增加一個 API 層，負責編排和轉發來自 User Interface 的業務請求。下面以訂單創建流程作為示例。

假設現在有一個訂單服務 OrderService，當它的 API 層接收到來自 User Interface 的訂單創建請求時，API 層協調會各個組件依次完成如下的幾個業務流程 ：

1. 調用訂單組件，完成訂單ID、訂單內容的生成。
2. 調用支付組件，完成用戶的扣款。
3. 調用庫存組件，更新商品的庫存數量。

因為這些業務流程都是在同一個服務內完成，當其中的某個流程異常后，我們很容易通過數據庫的 ACID 事務來完成回滾，從而能夠確保 數據的強一致性 。

相比在微服務架構之下，訂單創建請求往往需要訂單微服務、支付微服務、庫存微服務之間協作來完成，這就涉及到分布式事務，也即 BASE（Basic Availability, Soft state, Eventual consistency） 事務。BASE 事務更加的復雜，而且無法保證數據的強一致性。

當然，更粗的服務粒度也會帶來 服務可用性問題 ，比如在訂單服務例子中，你會因為訂單ID生成邏輯的變更而升級整個服務，也會因為庫存組件中的一個BUG導致整個服務的故障。

所以，服務粒度的粗與細，實際上也是數據一致性和服務可用性的一次 trade-off 。

數據拆分

服務間共享數據庫使得系統具有更強的數據完整性和一致性，但簡單的單庫單表數據模型會帶來耦合的問題。

在單庫單表的模型下，我們大概率會這么實現，將與數據庫操作相關的實體對象、SQL 邏輯全部封裝在一個共享的 shared lib 庫上，供所有業務服務復用：

這樣的實現方式雖然簡單，但是會帶來“ 牽一發而動全身 ”的問題。假設某個服務所用到的某個字段類型需要變化，勢必會修改表結構和 shared lib 庫，而這兩者是所有服務共用的，因此也就會導致所有服務都需要升級重新上線。這樣的耦合會給 SRE 帶來極大的困擾，一點也不 敏捷 。

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

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

SBA 是一個 domain-partitioned 的架構，因此適合使用領域驅動設計來進行領域限界上下文的劃分，進而規劃出業務獨立的服務。服務間業務獨立，而且不會相互間通信，也就意味著具有更好的 Testability 。

前文有提到過，SBA 雖然支持服務實例擴容，但是更粗的服務粒度會導致擴容的性價比并不高，因此 Scalability 和 Elasticity 得分不高。

Scalability 和 Elasticity的差異：

• Scalability 通常指軟件系統在不中斷業務的前提下，通過 scale-up 或 scale-out 等手段來應對更高業務負載，強調的是軟件系統應對高負載的能力。
• Elasticity 通常指硬件系統能夠根據實際的業務負載情況，適時增加或減少硬件資源，強調的是硬件資源的高效利用。

總結

如果你打算從單體架構演進到分布式架構，SBA 會是一個不錯的選擇 ：

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