看懂架構設計中的服務隔離

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

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

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

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

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

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

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

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

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

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

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

按服務/功能做隔離

按使用者分類隔離

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

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

比如上圖裡面，微博專案可以把 Feed資訊流、使用者系統、評論系統 都分拆為獨立業務模組，這些模組無論是對外的介面應用、還是到資料庫、到底層硬體資源都是完全隔離的。其中任何一個模組的故障，理論上都不會影響到其它模組。

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

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

當我們某個功能操作需要關聯多個服務模組或者同時查詢所個模組資料的時候，程式碼寫起來就會相對麻煩一些了，其中涉及到多模組呼叫的效能問題、資料一致性問題、事物問題等。

不同服務模組之間的互動也會比較複雜一些，因為要做服務隔離，避免服務強依賴，所以模組之間的互動呼叫最好是走非同步模式，需要通過非同步執行緒或訊息中介軟體來傳遞實現。

在進行運營大資料分析的時候，由於資料是散落在不同服務模組的，因此需要做額外的匯聚操作，還得有唯一欄位保證資料在不同模組產生的先後順序。

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

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

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

怎麼給使用者分類？

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

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

多租戶模式有三種形式：

完全的隔離，即服務和資料都是完全獨立的。

公共服務、獨立資料來源，即多個租戶是用的同一臺服務程式，但是底層的資料來源是獨立的。

公用服務、公用資料來源，即多個租戶的服務程式與資料庫源都是共享的，不同資料可能會做分割槽分表來獨立。

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

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

三、服務隔離的注意事項

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

不可越界：能在隔離模組內完成的邏輯，就儘量不要跨模組呼叫，減少依賴。

不可共享：資料和資源能獨享的就儘量不要共享，不然很容易造成隔離失效。

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

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

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

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

歡迎工作一到五年的Java工程師朋友們加入Java架構開發：744677563

本群提供免費的學習指導 架構資料 以及免費的解答

不懂得問題都可以在本群提出來 之後還會有職業生涯規劃以及面試指導