摘要：分散式系統無疑是持久的熱門話題，但其實如果不是一定有必要，強烈建議不要進入分散式領域，在集中式的情況下很多問題都會簡單不少，技術人員千萬不要因為外界火熱的例如微服務，就把自己的產品的也去做改造，一定要仔細判斷是否有必要，不要為了技術而技術，那麼在必須分散式的情況下（訪問量、儲存量或開發人數），一個分散式領域的合格的架構師要掌握哪些技術呢，這篇文章就聊聊這個話題。
分散式系統無疑是持久的熱門話題，但其實如果不是一定有必要，強烈建議不要進入分散式領域，在集中式的情況下很多問題都會簡單不少，技術人員千萬不要因為外界火熱的例如微服務，就把自己的產品的也去做改造，一定要仔細判斷是否有必要，不要為了技術而技術，那麼在必須分散式的情況下（訪問量、儲存量或開發人數），一個分散式領域的合格的架構師要掌握哪些技術呢，這篇文章就聊聊這個話題。
簡單重複下我對架構師的標準，一個架構師最重要的不是畫幾個框，連幾條線（這是基本要求），而是控制技術風險，要控制技術風險顯然不是看幾個結構性的ppt就能學會的。
通訊
既然是分散式系統，系統間通訊的技術就不可避免的要掌握。
首先要掌握一些基礎知識，例如網路通訊協議（諸如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執行緒池的時間佔用。
低資源消耗這點的話NonBlocking-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的實現。
可維護性
維護性是很容易被遺漏的部分，但對分散式系統來說其實是很重要的部分，例如整個系統環境應該怎麼搭建，部署，配套的維護工具、監控點、報警點、問題定位、問題處理策略等等。
從上面要掌握的這些技術，就可以知道為什麼要找到一個合格的分散式領域的架構師那麼的難，何況上面這些提到的還只是通用的分散式領域的技術點，但通常其實需要的都是特定分散式領域的架構師，例如分散式檔案系統、分散式cache等，特定領域的架構師需要在具備上面的這些技術點的基礎上還具備特定領域的知識技能，這就更不容易了。
隨著網際網路的發展，分散式領域的很多技術都在成熟化，想想在8年或9年前，一個大規模的網站的伸縮性是怎麼設計的還是很熱門的探討話題，但是到了今天基本的結構大家其實都清楚，並且還有很多不錯的系統開源出來，使得很多需要經驗的東西也被沉澱下去了，在有了各種不錯的開源產品的支撐下以後要做一個分散式系統的難度一定會越來越大幅降低，雲更是會加速這個過程。
ps: 在寫這篇文章的過程中，發現要判斷一個技術人的功底有多厚，其實還真不難，就是請TA寫或者講自己覺得懂的所有技術，看看能寫多厚或講多久…要寫厚或講很久其實都不容易，儘管我也不否認要很簡潔的寫明白或講清楚也不容易，但一定是先厚然後薄。
作者：阿里畢玄