我們在做系統架構設計的時候，經常離不開的一個話題就是進行服務的隔離設計。

那什麽是「服務隔離」呢？

顧名思義，它是指將系統按照一定的原則劃分為若幹個服務模塊，各個模塊之間相對獨立，無強依賴。當有故障發生時，能將問題和影響隔離在某個模塊內部，而不擴散風險，不波及其它模塊，不影響整體的系統服務。

其實隔離設計並非軟件行業獨創，它是借鑒於造船行業。

如上圖，造船行業有一個專業術語叫做「艙壁隔離」。利用艙壁將不同的船艙隔離起來，如果某一個船艙進了水，那麽就可以立即封閉艙門，形成艙壁隔離，只損失那一個船艙，其他船艙不受影響，整個船只還是可以正常航行。

一、為什麽要做服務隔離設計呢？

我們在做系統設計的時候，必須有一個清楚的認知是：任何軟件系統，故障是不可避免的，並且大多數還是不可預測的，因此，我們只能在系統的設計之初就充分的考慮好應對措施，如何在故障發生時，去盡最大可能的止損和減少故障範圍。

沒有人敢說他的系統是百分百可用，我們能做的就是，使用一切方法去減少故障的影響面，盡可能的去提高系統的整體可用率。

而把系統分離成子服務，將子服務進行一定程度隔離的做法，能保證在有不可預測的故障發生時，縮小故障範圍的最佳手段。

二、服務隔離應該怎麽做？

那在實際項目中，一般通過什麽方法去做服務隔離呢？主要有以下兩種：

按服務/功能做隔離

按用戶分類隔離

首先說一下按照服務進行隔離的做法。

網上找了一張圖，雖然原圖的作用不是用來表述這個的，但是也類似，將就看吧。

比如上圖裏面，微博項目可以把 Feed信息流、用戶系統、評論系統 都分拆為獨立業務模塊，這些模塊無論是對外的接口應用、還是到數據庫、到底層硬件資源都是完全隔離的。其中任何一個模塊的故障，理論上都不會影響到其它模塊。

再舉個例子，如果我們要設計個電商平臺，可以將其中的 用戶系統、訂單系統、支付系統、倉儲系統 都分別進行獨立隔離，這樣做就是從服務層面實現了故障的隔離效果。

那按照服務隔離有沒有弊端呢？有，肯定有！

1、當我們某個功能操作需要關聯多個服務模塊或者同時查詢所個模塊數據的時候，代碼寫起來就會相對麻煩一些了，其中涉及到多模塊調用的性能問題、數據一致性問題、事物問題等。

2、不同服務模塊之間的交互也會比較復雜一些，因為要做服務隔離，避免服務強依賴，所以模塊之間的交互調用最好是走異步模式，需要通過異步線程或消息中間件來傳遞實現。

3、在進行運營大數據分析的時候，由於數據是散落在不同服務模塊的，因此需要做額外的匯聚操作，還得有唯一字段保證數據在不同模塊產生的先後順序。

接下來說一下按用戶隔離的做法。

繼續網上找圖，雖然原圖的作用不是用來表述這個的，但是也類似。粉絲又不多，我又懶得畫圖，將就看吧，多發揮一下想象力，哈哈。

簡單一句話解釋就是：我們先部署多套一模一樣的業務服務，然後將用戶根據一定的特征去做分類，讓不同分類的用戶去訪問不同的業務實例，達到分流和隔離的效果。

怎麽給用戶分類？

可以用按照用戶是否VIP、用戶等級、用戶IP等等，方法很多，要結合自己實際業務的特性來做。

其實這也是一種「多租戶架構」，在SaaS服務中用得比較多。

多租戶模式有三種形式：

1、完全的隔離，即服務和數據都是完全獨立的。

2、公共服務、獨立數據源，即多個租戶是用的同一臺服務程序，但是底層的數據源是獨立的。

3、公用服務、公用數據源，即多個租戶的服務程序與數據庫源都是共享的，不同數據可能會做分區分表來獨立。

上述三種方式，從下到上，獨立性和安全性越來越高，資源利用率越來越低，根據業務特性去選擇，一般選擇折中方案。

另外，功能隔離和用戶隔離 兩種方式並非互斥的，是可以結合在一起使用的。

三、服務隔離的註意事項

我們在做服務隔離的時候，還是有一些原則和事項需要註意的：

1、不可越界：能在隔離模塊內完成的邏輯，就盡量不要跨模塊調用，減少依賴。

2、不可共享：數據和資源能獨享的就盡量不要共享，不然很容易造成隔離失效。

3、考慮效率：設計隔離模塊的時候，要根據業務情況而定，充分的考慮到未來的拓補結構，減少調用效率的損失。

4、考慮顆粒度：隔離模塊設計的大小問題，過大和過小都不合適，需充分考慮。

5、服務的全面監控：既然服務或用戶進行隔離了，那麽系統的復雜度肯定是比之前要高了，那麽針對多服務的全鏈路監控是必不可少的。

總結

服務隔離的設計模式能降低依賴服務對整個系統的影響，保護有限的資源不被耗盡，提高了整個系統的可用性。本文參考了很多其它資料，屬於拋磚引玉，希望大家能一起交流，提出更好的架構設計思路。

為什麽架構設計要進行服務隔離？