我們在做系統(tǒng)架構(gòu)設(shè)計的時候熄攘，經(jīng)常離不開的一個話題就是進行服務(wù)的隔離設(shè)計。
那什么是「服務(wù)隔離」呢？
顧名思義县匠，它是指將系統(tǒng)按照一定的原則劃分為若干個服務(wù)模塊，各個模塊之間相對獨立撒轮，無強依賴乞旦。當有故障發(fā)生時，能將問題和影響隔離在某個模塊內(nèi)部题山，而不擴散風(fēng)險兰粉，不波及其它模塊，不影響整體的系統(tǒng)服務(wù)顶瞳。
其實隔離設(shè)計并非軟件行業(yè)獨創(chuàng)玖姑，它是借鑒于造船行業(yè)愕秫。
如上圖，造船行業(yè)有一個專業(yè)術(shù)語叫做「艙壁隔離」焰络。利用艙壁將不同的船艙隔離起來戴甩，如果某一個船艙進了水，那么就可以立即封閉艙門舔琅，形成艙壁隔離等恐，只損失那一個船艙，其他船艙不受影響备蚓，整個船只還是可以正常航行课蔬。
一、為什么要做服務(wù)隔離設(shè)計呢郊尝？
我們在做系統(tǒng)設(shè)計的時候二跋，必須有一個清楚的認知是：任何軟件系統(tǒng)，故障是不可避免的流昏，并且大多數(shù)還是不可預(yù)測的扎即，因此，我們只能在系統(tǒng)的設(shè)計之初就充分的考慮好應(yīng)對措施况凉，如何在故障發(fā)生時谚鄙，去盡最大可能的止損和減少故障范圍。
沒有人敢說他的系統(tǒng)是百分百可用刁绒，我們能做的就是闷营，使用一切方法去減少故障的影響面，盡可能的去提高系統(tǒng)的整體可用率知市。
而把系統(tǒng)分離成子服務(wù)傻盟，將子服務(wù)進行一定程度隔離的做法，能保證在有不可預(yù)測的故障發(fā)生時嫂丙，縮小故障范圍的最佳手段娘赴。
二、服務(wù)隔離應(yīng)該怎么做跟啤？
那在實際項目中诽表，一般通過什么方法去做服務(wù)隔離呢？主要有以下兩種：
按服務(wù)/功能做隔離
按用戶分類隔離
首先說一下按照服務(wù)進行隔離的做法隅肥。
網(wǎng)上找了一張圖关顷，雖然原圖的作用不是用來表述這個的，但是也類似武福，將就看吧。
比如上圖里面痘番，微博項目可以把 Feed信息流捉片、用戶系統(tǒng)平痰、評論系統(tǒng) 都分拆為獨立業(yè)務(wù)模塊，這些模塊無論是對外的接口應(yīng)用伍纫、還是到數(shù)據(jù)庫宗雇、到底層硬件資源都是完全隔離的。其中任何一個模塊的故障莹规，理論上都不會影響到其它模塊赔蒲。
再舉個例子，如果我們要設(shè)計個電商平臺良漱，可以將其中的 用戶系統(tǒng)舞虱、訂單系統(tǒng)、支付系統(tǒng)母市、倉儲系統(tǒng) 都分別進行獨立隔離矾兜，這樣做就是從服務(wù)層面實現(xiàn)了故障的隔離效果。
那按照服務(wù)隔離有沒有弊端呢患久？有椅寺，肯定有。
當我們某個功能操作需要關(guān)聯(lián)多個服務(wù)模塊或者同時查詢所個模塊數(shù)據(jù)的時候蒋失，代碼寫起來就會相對麻煩一些了返帕，其中涉及到多模塊調(diào)用的性能問題、數(shù)據(jù)一致性問題篙挽、事物問題等荆萤。
不同服務(wù)模塊之間的交互也會比較復(fù)雜一些，因為要做服務(wù)隔離嫉髓，避免服務(wù)強依賴观腊，所以模塊之間的交互調(diào)用最好是走異步模式，需要通過異步線程或消息中間件來傳遞實現(xiàn)算行。
在進行運營大數(shù)據(jù)分析的時候梧油，由于數(shù)據(jù)是散落在不同服務(wù)模塊的，因此需要做額外的匯聚操作州邢，還得有唯一字段保證數(shù)據(jù)在不同模塊產(chǎn)生的先后順序儡陨。
接下來說一下按用戶隔離的做法。
繼續(xù)網(wǎng)上找圖量淌，雖然原圖的作用不是用來表述這個的骗村，但是也類似。粉絲又不多呀枢，我又懶得畫圖胚股，將就看吧，多發(fā)揮一下想象力裙秋，哈哈琅拌。
簡單一句話解釋就是：我們先部署多套一模一樣的業(yè)務(wù)服務(wù)缨伊，然后將用戶根據(jù)一定的特征去做分類，讓不同分類的用戶去訪問不同的業(yè)務(wù)實例进宝，達到分流和隔離的效果刻坊。
怎么給用戶分類？
可以用按照用戶是否VIP党晋、用戶等級谭胚、用戶IP等等，方法很多未玻，要結(jié)合自己實際業(yè)務(wù)的特性來做灾而。
其實這也是一種「多租戶架構(gòu)」，在SaaS服務(wù)中用得比較多深胳。
多租戶模式有三種形式：
完全的隔離绰疤，即服務(wù)和數(shù)據(jù)都是完全獨立的。
公共服務(wù)舞终、獨立數(shù)據(jù)源轻庆，即多個租戶是用的同一臺服務(wù)程序，但是底層的數(shù)據(jù)源是獨立的敛劝。
公用服務(wù)余爆、公用數(shù)據(jù)源，即多個租戶的服務(wù)程序與數(shù)據(jù)庫源都是共享的夸盟，不同數(shù)據(jù)可能會做分區(qū)分表來獨立蛾方。
上述三種方式，從下到上上陕，獨立性和安全性越來越高桩砰，資源利用率越來越低，根據(jù)業(yè)務(wù)特性去選擇释簿，一般選擇折中方案亚隅。
另外，功能隔離和用戶隔離 兩種方式并非互斥的庶溶，是可以結(jié)合在一起使用的煮纵。
三、服務(wù)隔離的注意事項
我們在做服務(wù)隔離的時候偏螺，還是有一些原則和事項需要注意的：
不可越界：能在隔離模塊內(nèi)完成的邏輯行疏，就盡量不要跨模塊調(diào)用，減少依賴套像。
不可共享：數(shù)據(jù)和資源能獨享的就盡量不要共享酿联，不然很容易造成隔離失效。
考慮效率：設(shè)計隔離模塊的時候，要根據(jù)業(yè)務(wù)情況而定贞让，充分的考慮到未來的拓補結(jié)構(gòu)采幌，減少調(diào)用效率的損失。
考慮顆粒度：隔離模塊設(shè)計的大小問題震桶，過大和過小都不合適，需充分考慮征绎。
服務(wù)的全面監(jiān)控：既然服務(wù)或用戶進行隔離了蹲姐，那么系統(tǒng)的復(fù)雜度肯定是比之前要高了，那么針對多服務(wù)的全鏈路監(jiān)控是必不可少的人柿。
服務(wù)隔離的設(shè)計模式能降低依賴服務(wù)對整個系統(tǒng)的影響柴墩，保護有限的資源不被耗盡，提高了整個系統(tǒng)的可用性凫岖。本文參考了很多其它資料江咳，屬于拋磚引玉，希望大家能一起交流哥放，提出更好的架構(gòu)設(shè)計思路歼指。
