微服務現在有多火，應該不需要我過多解釋了。
現在可以確定，只要有點規模的公司，肯定是跑微服務架構。簡單來說下背景，隨着業務量越來越大，一臺機器的性能已經無法滿足了，我們需要多臺機器才能應對大規模的應用場景。同時，我們也需要通過分佈式架構來冗餘系統以消除單點故障，從而提高系統的可用性。
拆完微服務之後，我個人覺得比較難的一個知識點就是微服務的可用性設計。
提到可用性，一般情況下，就會跟着出來這些詞：隔離、超時、限流、降級、重試。我一般面試的時候，都會挑着拿出來一個問題來問候選人，以看他的技術深度。
就拿隔離來說，隔離設計對應的單詞是 Bulkheads，中文翻譯爲隔板。但其實，這個術語是用在造船上的，也就是船艙裏防漏水的隔板。一般的船無論大小都會有這個東西，大一點的船都會把船艙隔成若干個空間。這樣，如果船艙漏水，只會進到一個小空間裏，不會讓整個船艙都進水而導致整艘船都沉了。
在分佈式軟件架構中，我們同樣需要使用類似的技術來讓我們的故障得到隔離。這就需要我們對系統進行分離。一般來說，對於系統的分離有兩種方式，一種是以服務的種類來做分離，一種是以用戶來做分離。
服務隔離舉個例子，我們可以將系統分成了用戶、商品、社區三個板塊。這三個塊分別使用不同的域名、服務器和數據庫，做到從接入層到應用層再到數據層三層完全隔離。這樣一來，在物理上來說，一個板塊的故障就不會影響到另一板塊。
用戶隔離舉個例子，我們將用戶分成不同的組，並把後端的同一個服務根據這些不同的組分成不同的實例。讓同一個服務對於不同的用戶進行冗餘和隔離，這樣一來，當服務實例掛掉時，只會影響其中一部分用戶，而不會導致所有的用戶無法訪問。
這其實就是隔離大致的原理。在隔離設計上也有一些考量，比如，我們需要定義好隔離業務的大小和粒度，過大和過小都不好。這就需要認真地做業務上的需求和系統分析。另外，隔離模式需要配置一些高可用、重試、異步、消息中間件，流控、熔斷等設計模式的方式配套使用。
如果你對這塊感興趣的話，我向你推薦毛劍的一個分享，這應該是我見過的講的最全面的內容了，不說別的，人家這是直接講案例啊！
《Go 微服務架構實踐 - 可用性設計原則》，該課程是 3 天視頻課 + 1 天直播課，全方面的講解微服務的可用性設計。現在直接掃描下圖的二維碼添加學習助理，就可以免費領取。
以下是本次課程的具體大綱內容和直播安排。不只是圖中的課程內容，每天還會有大廠助教老師在社羣裏佈置作業和互動答疑，最後一天是毛劍老師來直播講解授課。學、問、答、練全都有了。
這麼幹貨的課程，現在限時免費可以領取！0 元來收穫毛劍大佬的硬核分享，非常超值！有需要的掃描下邊的二維碼添加學習助理即可。
限時 0 元
本文分享自微信公衆號 - Python爬蟲與數據挖掘（crawler_python）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。