分布式系統漫談

分布式系統漫談--微服務的挑戰和解決方案。

微服務的挑戰

在使用微服務架構後，由於服務間的呼叫不再是程序內的呼叫而是通過輕量級的網路協議通訊，而眾所周知網路不不可信的，因此服務可能出現出錯、超時或宕機等問題。因此在微服務架構設計時，我們就要把這部分問題考慮進去，下面說說我們應該採取哪些措施和方案去解決。

艙壁模式

艙壁模式是指，當一艘船沉了，某個艙壁淹水不要影響其他艙壁。由此可見，艙壁的設計主要是為了隔離。在微服務設計中，我們可以考慮使用如下方案來舒心啊艙壁模式：

一、微服務容器分組

將微服務系統分為測試環境、灰度環境和生產環境。使用灰度環境去跑一些普通使用者的流量，相當於內測，沒問題後，再全量放開到生產環境。

以微博為例。據說某浪微博把名人的流量放到核心池子中，普通使用者流量路由到另外乙個池子。核心池子的容量以及機器配置都高於另外的普通池子(沒錯，就是這樣區分對待的)。通過這樣的實現了隔離普通使用者和重要使用者的負載。

二、執行緒池隔離

在搭建微服務系統時，由於團隊和財務等因素我們不一定把每個服務拆分到很微小的粒度。所以多個功能可能部署在乙個微服務例項中，使用同乙個執行緒池。如果乙個功能流程增加耗盡執行緒池的執行緒，可能阻塞其他功能的服務。

因此我們盡量讓核心的服務享有單獨的執行緒池，將一些邊緣的和不重要的服務共享乙個執行緒池。

熔斷模式

類似於家裡的保險絲原理。當乙個服務請求量過大幾乎要超過機器效能瓶頸時，我們需要設定乙個斷路器，讓其請求快速返回失敗，避免發生系統雪崩效應。熔斷模式的大概流程圖如下：

限流模式

控制訪問的併發量，比如每秒允許處理的併發使用者數及查詢量、請求量等。主流的方法如下幾種：

一、計數器

通過原子變數計算單位時間內的訪問次數，超出閾值，拒絕後面請求，等到下乙個單位時間重新計數。

二、令牌桶

通過乙個執行緒在單位時間內生產固定數量的令牌，然後把令牌放入佇列，每次請求呼叫需要從桶中拿去乙個令牌，有令牌才有資格執行請求呼叫，否則只能等到拿到令牌再執行，或直接丟棄。

三、漏桶

類似漏斗，請求可以任意速率流入，但流出的流量是有限的。桶容量也有限，當滿了後新來的請求被丟棄(或進入等待佇列)，可考慮使用semaphore實現。

四、失效轉移模式

如果微服務系統中已發生了熔斷和限流，可通過如下方式處理已拒絕請求：

1.快速失敗策略，直接返回使用方錯誤，讓呼叫方知道發生問題；

2.切換到備份服務；

3.採用重試機制，但是注意冪等性；

降級模式

在流量高峰到來的時候，可以考慮將一些非核心的服務停掉，或者換成非同步處理，來保證核心服務的穩定性以及主業務流程可以跑的通。對於服務的降級，有如下幾個要點：

1.設定全域性降級開關，可以推送至各個微服務應用，並應用中將服務讀取開關的邏輯盡量前置；

2.對讀服務的降級，開關開啟後可設定為唯讀本地快取、分布式快取或降級資料；

3.對寫服務的降級，開關開啟後可考慮將服務改為非同步呼叫，直接返回給呼叫方成功；