分布式領域架構師要掌握的技術分布式系統無疑是持久的熱門話題，但其實如果不是一定有必要，強烈建議不要進入分布式領域，在集中式的情況下很多問題都會簡單不少，技術人員千萬不要因為外界火熱的例如微服務，就把自己的産品的也去做改造，一定要仔細判斷是否有必要，不要為了技術而技術，那麼在必須分布式的情況下（通路量、存儲量或開發人數），一個分布式領域的合格的架構師要掌握哪些技術呢，這篇文章就聊聊這個話題。

簡單重複下我對架構師的标準，一個架構師最重要的不是畫幾個框，連幾條線（這是基本要求），而是控制技術風險，要控制技術風險顯然不是看幾個結構性的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方式下的伸縮性問題仍然是很大的挑戰，非常不好做。

上面所寫的基本都還隻是解決的方向，到細節點基本就很容易判斷是一個解決過多大規模場景問題的架構師，:)

穩定性

作為分布式系統，必須要考慮清楚整個系統中任何一個點挂掉應該怎麼處理（到了一定機器規模，每天挂掉一些機器很正常），同樣主要還是分成了無狀态和有狀态：

對于無狀态場景，通常好辦，隻用節點發現的機制上具備心跳等檢測機制就ok，經驗上來說無非就是純粹靠4層的檢測對業務不太夠，通常得做成7層的，當然，做成7層的就得處理好規模大了後的問題。

對于有狀态場景，就比較麻煩了，對資料一緻性要求不高的還ok，主備類型的方案基本也可以用，當然，主備方案要做的很好也非常不容易，有各種各樣的方案，對于主備方案又覺得不太爽的情況下，例如hbase這樣的，就意味着挂掉一台，另外一台接管的話是需要一定時間的，這個對可用性還是有一定影響的；

全局一緻類型的場景中，如果一台挂了，就通常意味着得有選舉機制來決定其他機器哪台成為主，常見的例如基于paxos的實作。

可維護性

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

從上面要掌握的這些技術，就可以知道為什麼要找到一個合格的分布式領域的架構師那麼的難，何況上面這些提到的還隻是通用的分布式領域的技術點，但通常其實需要的都是特定分布式領域的架構師，例如分布式檔案系統、分布式cache等，特定領域的架構師需要在具備上面的這些技術點的基礎上還具備特定領域的知識技能，這就更不容易了。

随着網際網路的發展，分布式領域的很多技術都在成熟化，想想在8年或9年前，一個大規模的網站的伸縮性是怎麼設計的還是很熱門的探讨話題，但是到了今天基本的結構大家其實都清楚，并且還有很多不錯的系統開源出來，使得很多需要經驗的東西也被沉澱下去了，在有了各種不錯的開源産品的支撐下以後要做一個分布式系統的難度一定會越來越大幅降低，雲更是會加速這個過程。

ps: 在寫這篇文章的過程中，發現要判斷一個技術人的功底有多厚，其實還真不難，就是請ta寫或者講自己覺得懂的所有技術，看看能寫多厚或講多久…要寫厚或講很久其實都不容易，盡管我也不否認要很簡潔的寫明白或講清楚也不容易，但一定是先厚然後薄。

作者：阿裡畢玄

轉載自：微信公衆号：hellojavacases