分佈式系統架構師必需要考慮的四個方面

剛看了阿里技術大牛畢玄《分佈式領域架構師要掌握的技術》，裏面講到，架構師在設計分佈式系統須要重點考慮如下四方面：

一、通訊

首先要掌握一些基礎知識，例如網絡通訊協議（諸如TCP/UDP等等）、網絡IO（Blocking-IO，NonBlocking-IO、Asyn-IO）、網卡（多隊列等）；更偏應用的層面，須要瞭解例如鏈接複用、序列化/反序列化、RPC、負載均衡等。

學了這些基本知識後，基本上能夠寫一個簡單的分佈式系統裏的通訊模塊，但這其實遠遠不夠，既然進入了分佈式領域，對規模其實就已經有了不低的要求，一般也就意味着須要的是能支持大量鏈接、高併發、低資源消耗的通訊程序。

 

大量的鏈接一般會有兩種方式：

1. 大量client連一個server

   在現現在NonBlocking-IO這麼成熟的狀況下，一個支持大量client的server已經不那麼難寫了，但在大規模，而且一般長鏈接的狀況下，有一個點要特別注意，就是當server掛掉的時候，不能出現全部client都在一個時間點發起重連，那樣基本就是災難，在沒有經驗的狀況下我看過好幾起相似的case，到client規模上去後，server一重啓基本就直接被衝進來的大量建連沖垮了（固然，server的backlog隊列首先應該稍微設置大一些），一般能夠採用的方法是client重連前都作隨機時間的sleep，另外就是重連的間隔採起避讓算法。

 

2. 一個client連大量的server

   有些場景也會出現須要連大量server的現象，在這種狀況下，一樣要注意的也是不要併發同時去建全部的鏈接，而是在能力範圍內分批去建。

   除了建鏈接外，另外還要注意的地方是併發發送請求也一樣，必定要作好限流，不然很容易會由於一些點慢致使內存爆掉。

 

這些問題在技術風險上得考慮進去，並在設計和代碼實現上體現，不然一旦隨着規模上去了，問題一時半會還真不太好解。

 

高併發這個點須要掌握CAS、常見的lock-free算法、讀寫鎖、線程相關知識（例如線程交互、線程池）等，通訊層面的高併發在NonBlocking-IO的狀況下，最重要的是要注意在總體設計和代碼實現上儘可能減小對io線程池的時間佔用。

二、伸縮性

伸縮性的問題圍繞着如下兩種場景在解決：

1. 無狀態場景

   對於無狀態場景，要實現隨量增加而加機器支撐會比較簡單，這種狀況下只用解決節點發現的問題，一般只要基於負載均衡就能夠搞定，硬件或軟件方式都有；

   無狀態場景一般會把不少狀態放在db，當量到必定階段後會須要引入服務化，去緩解對db鏈接數太多的狀況。

2. 有狀態場景

   所謂狀態其實就是數據，一般採用Sharding來實現伸縮性，Sharding有多種的實現方式，常見的有這麼一些：

   2.1 規則Sharding

       基於必定規則把狀態數據進行Sharding，例如分庫分表不少時候採用的就是這樣的，這種方式支持了伸縮性，但一般也帶來了很複雜的管理、狀態數據搬遷，甚至業務功能很難實現的問題，例如全局join，跨表事務等。

   2.2 一致性Hash

       一致性Hash方案會使得加機器代價更低一些，另外就是壓力能夠更爲均衡，例如分佈式cache常常採用，和規則Sharding帶來的問題基本同樣。

   2.3 Auto Sharding

       Auto Sharding的好處是基本上不用管數據搬遷，並且隨着量上漲加機器就OK，但一般Auto Sharding的狀況下對如何使用會有比較高的要求，而這個一般也就會形成一些限制，這種方案例如HBase。

   2.4 Copy

       Copy這種常見於讀遠多於寫的狀況，實現起來又會有最終一致的方案和全局一致的方案，最終一致的多數可經過消息機制等，全局一致的例如zookeeper/etcd之類的，既要全局一致又要作到很高的寫支撐能力就很難實現了。   

即便發展到今天，Sharding方式下的伸縮性問題仍然是很大的挑戰，很是很差作。

三、穩定性

做爲分佈式系統，必需要考慮清楚整個系統中任何一個點掛掉應該怎麼處理（到了必定機器規模，天天掛掉一些機器很正常），一樣主要仍是分紅了無狀態和有狀態：

1. 無狀態場景

   對於無狀態場景，一般好辦，只用節點發現的機制上具有心跳等檢測機制就OK，經驗上來講無非就是純粹靠4層的檢測對業務不太夠，一般得作成7層的，固然，作成7層的就得處理好規模大了後的問題。

2. 有狀態場景

   對於有狀態場景，就比較麻煩了，對數據一致性要求不高的還OK，主備類型的方案基本也能夠用，固然，主備方案要作的很好也很是不容易，有各類各樣的方案，對於主備方案又以爲不太爽的狀況下，例如HBase這樣的，就意味着掛掉一臺，另一臺接管的話是須要必定時間的，這個對可用性仍是有必定影響的；

   全局一致類型的場景中，若是一臺掛了，就一般意味着得有選舉機制來決定其餘機器哪臺成爲主，常見的例如基於paxos的實現。

四、可維護性

維護性是很容易被遺漏的部分，但對分佈式系統來講實際上是很重要的部分，例如整個系統環境應該怎麼搭建，部署，配套的維護工具、監控點、報警點、問題定位、問題處理策略等等。