分布式系統無疑是持久的熱門話題，但其實如果不是一定有必要，強烈建議不要進入分布式領域，在集中式的情況下很多問題都會簡單不少，技術人員千萬不要因為外界火熱的例如微服務，就把自己的產品的也去做改造，一定要仔細判斷是否有必要，不要為了技術而技術，那么在必須分布式的情況下（訪問量、存儲量或開發人數），一個分布式領域的合格的架構師要掌握哪些技術呢，這篇文章就聊聊這個話題。
簡單重復下我對架構師的標準，一個架構師最重要的不是畫幾個框，連幾條線（這是基本要求），而是控制技術風險，要控制技術風險顯然不是看幾個結構性的ppt就能學會的。
通信
既然是分布式系統，系統間通信的技術就不可避免的要掌握。
首先要掌握一些基礎知識，例如網絡通信協議（諸如TCP/UDP等等）、網絡IO（Blocking-IO，NonBlocking-IO、Asyn-IO）、網卡（多隊列等）；更偏應用的層面，需要了解例如連接復用、序列化/反序列化、RPC、負載均衡等。
學了這些基本知識后，基本上可以寫一個簡單的分布式系統里的通信模塊，但這其實遠遠不夠，既然進入了分布式領域，對規模其實就已經有了不低的要求，通常也就意味著需要的是能支持大量連接、高并發、低資源消耗的通信程序。
大量的連接通常會有兩種方式：
大量client連一個server
在現如今NonBlocking-IO這么成熟的情況下，一個支持大量client的server已經不那么難寫了，但在大規模，并且通常長連接的情況下，有一個點要特別注意，就是當server掛掉的時候，不能出現所有client都在一個時間點發起重連，那樣基本就是災難，在沒有經驗的情況下我看過好幾起類似的case，到client規模上去后，server一重啟基本就直接被沖進來的大量建連沖垮了（當然，server的backlog隊列首先應該稍微設置大一些），通常可以采用的方法是client重連前都做隨機時間的sleep，另外就是重連的間隔采取避讓算法。一個client連大量的server
有些場景也會出現需要連大量server的現象，在這種情況下，同樣要注意的也是不要并發同時去建所有的連接，而是在能力范圍內分批去建。
除了建連接外，另外還要注意的地方是并發發送請求也同樣，一定要做好限流，否則很容易會因為一些點慢導致內存爆掉。
這些問題在技術風險上得考慮進去，并在設計和代碼實現上體現，否則一旦隨著規模上去了，問題一時半會還真不太好解。
高并發這個點需要掌握CAS、常見的lock-free算法、讀寫鎖、線程相關知識（例如線程交互、線程池）等，通信層面的高并發在NonBlocking-IO的情況下，最重要的是要注意在整體設計和代碼實現上盡量減少對io線程池的時間占用。
低資源消耗這點的話NonBlocking-IO本身基本已經做到。
伸縮性
分布式系統基本就意味著規模不小了，對于這類系統在設計的時候必須考慮伸縮性問題，架構圖上畫的任何一個點，如果請求量或者是數據量不斷增大，怎么做到可以通過加機器的方式來解決，當然，這個過程也不用考慮無限大的場景，如果經歷過從比較小到非常大規模的架構師，顯然優勢是不小的，同樣也會是越來越稀缺的。
橫向可擴展性（Scale Out）是指通過增加服務器數量來提升集群整體性能。縱向可擴展性（Scale Up）是指提升每臺服務器性能進而提升集群整體性能?？v向可擴展性的上限非常明顯，分布式系統強調橫向可擴展性。
分布式系統應用服務最好做成無狀態的
應用服務的狀態是指運行時程序因為處理服務請求而存在內存的數據。分布式應用服務最好是設計成無狀態。因為如果應用程序是有狀態的，那么一旦服務器宕機就會使得應用服務程序受影響而掛掉，那存在內存的數據也就丟失了，這顯然不是高可靠的服務。把應用服務設計成無狀態的，讓程序把需要保存的數據都保存在專門的存儲上(eg. 數據庫)，這樣應用服務程序可以任意重啟而不丟失數據，方便分布式系統在服務器宕機后恢復應用服務。
伸縮性的問題圍繞著以下兩種場景在解決：
- 無狀態場景
對于無狀態場景，要實現隨量增長而加機器支撐會比較簡單，這種情況下只用解決節點發現的問題，通常只要基于負載均衡就可以搞定，硬件或軟件方式都有；
無狀態場景通常會把很多狀態放在db，當量到一定階段后會需要引入服務化，去緩解對db連接數太多的情況。 - 有狀態場景
所謂狀態其實就是數據，通常采用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寫或者講自己覺得懂的所有技術，看看能寫多厚或講多久…要寫厚或講很久其實都不容易，盡管我也不否認要很簡潔的寫明白或講清楚也不容易，但一定是先厚然后薄。
