Go 可用性 -一- 隔離設計

序

隔離設計源於船舶行業，一般而言無論大船還是小船，都會有一些隔板，將船分爲不同的空間，這樣如果有船艙漏水一般只會影響這一小塊空間，不至於把整個船都給搞沉了。

同樣我們的軟件服務也是一個道理，我們要儘量避免出現一個問題就把這個業務給搞掛的情況出現。


一般而言類似的文章都會告訴大家服務隔離應該分爲哪裏類型，或者那些級別，然後一般分別怎麼做，今天我們換一個套路，我們從一個服務演進的角度來看，我們服務隔離是怎麼做的

服務的演進

PS: 接下來的部分架構純屬瞎扯，但是道理是差不多的，辛苦各位湊合看一下了

如下圖，今天天氣不錯，我們開始創業（天氣和創業有啥關係？？？），搞了一個電商網站，由於前期人手不足技術也不夠，就一個服務和一個數據庫就開始對外提供服務了

隨着貨物的不斷上架，我們發現產品相關介紹的圖片、視頻等信息佔用了我們服務的大部分帶寬，並且也不太好管理，用戶訪問呢也比較慢，影響了剁手的體驗，這時候我們做了一波優化，把靜態資源的數據使用雲服務商提供的對象存儲給保存了起來，然後在前面接入了一個 CDN 給用戶提供更好的體驗。

這就是第一次隔離，動靜隔離，我們使用對象存儲和 CDN 將靜態資源和動態 API 進行了隔離

然後突然有一天我們發現，用戶大量投訴說什麼垃圾網站，突然訪問這麼慢，進過緊鑼密鼓的排查發現，原來是我們的運營同學在後臺進行數據統計準備出報告的時候影響了生產的數據庫，導致影響了我們的用戶。

這怎麼能行呢，怎麼可以影響我們的衣食父母，所以我們有進行了一波優化，我們對數據庫進行了主從分離，然後將運營後臺和我們的商城主服務做了拆分，後續所有的統計查詢請求我們都從從庫查詢，其他請求才會去修改主庫。

是滴，我們又做了一次隔離，一個是將數據庫做了主從隔離，另外一個按照不同的用戶屬性，做了用戶隔離。當然這是比較宏觀的在這過程中我們肯定也會對數據中的表進行一些拆分設計，例如將經常變化的數據和不太經常變化的數據分配到兩張表等。

不知道是隨着一些爆款活動的退出，以及不知名大 V 的推廣使得我們的業務欣欣向上，還是我們新來的技術總監爲了 KPI 我們進行了轟轟烈烈的微服務改造的活動，最後經過長達一年多的改造，我們的服務架構改造成了下面這個模樣。

我們的請求才訪問之前都會先經過 WAF 防火牆，然後在到對應的 CDN 節點然後經過我們的 API 網關到 BFF 層。然後 BFF 層再去調用各種服務聚合成業務數據並且返回。

我們其實又做了一層按照服務的隔離，我們將一個單體服務拆分成了一個個的小服務，就不會出現評論掛掉了導致整個服務掛掉無法下單的情況。

微服務改造完成之後我們發現，的確整體的服務質量都好了很多，但是突如其來的一個 bug 導致我們的監控大量告警，這是爲什麼呢，原來是我們的推薦服務出現了一個內存泄漏的問題，然後我們的服務限制做的不夠好根本沒有設置任何限制，這就導致它佔用了資源池中的大量資源，讓我們的其他服務資源緊缺。

然後我們就又做了一個改造，我們把支付和商城這種最重要的業務單獨放在了一個池子裏面，對於像評論推薦這種沒有那麼重要的業務放在共享的資源池當中。

所以這一次我們按照服務的優先級進行了隔離

然後突然有一天，我們的一個商品成爲了爆款，大量用戶湧入訪問，成功將我們的 cache 打掛，後續我們做了什麼改動呢，我們將 remote cache 提升爲了 local cache，在 sdk 當中自動識別出熱點流量，然後將其緩存，大大減少了 redis 的壓力

這一次我們就將熱點數據進行了隔離

好啦，瞎扯結束總結一下吧

總結

通過上面純屬虛構的面向事故驅動的例子，我們可以發現，我們隔離設計一般分爲以下幾種：

今天的內容就到這裏，畫圖真的好費時間，下篇文章講一講過載保護 - 令牌桶，敬請期待

參考文獻

  1. Go 進階訓練營 - 極客時間
  2. 架構設計之「服務隔離」
  3. 42 | 彈力設計篇之 “隔離設計”- 極客時間
  4. 41 | 彈力設計篇之 “認識故障和彈力設計”- 極客時間
  5. 如何設計高可用系統之故障隔離 - 阿里雲開發者社區
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://lailin.xyz/post/go-training-week6-usability-1-bulkhe.html

猜你喜歡