任何事物都有兩面性。你只有瞭解了分散式系統背後的“暗流湧動”現象是什麼，才能避免掉到“坑”裡去。暗流的含義是流動的地下水，是潛伏在“深層”的，我們往往過度地沉迷於表面的美好，而忽略了它。在分散式系統當中，最容易被我們忽略的是本文將介紹的這六大“暗流”。
1網路並不是可靠的
你應該明白，分散式系統中不同節點間的通訊是基於網路的。網路使得它們連線起來共同協作。
然而，光纜被挖斷的事件相信你也看到過不是一兩次了。除此之外，網絡卡異常、交換機故障、遭受惡意攻擊等導致的網路擁塞、網路中斷、報文丟失的種種跡象皆意味著網路隨時可能無法正常運作，是不可靠的。
此時，需要在你的系統設計中，儘可能地考慮到：當前節點所依賴的其他節點由於各種原因無法與之正常通訊時，該如何保證其依然能夠提供部分或者完整的服務。這個概念在軟體領域被定義為“魯棒性”。
2不同節點之間的通訊是存在延遲的
網路連線的是處於不同物理位置上的節點，學過物理和數學你的應該明白，兩點之間是存在“距離”的，而我們的分散式系統需要在這個距離之上進行資料的傳遞，本質上就是物質的傳遞。同時應該你也知道，物質的運動速度不會超過光速。所以，不同節點之間的通訊是需要經過一段時間的，也就意味著會存在延遲。具體的延遲是由所用的傳輸介質、節點當前的負載大小所決定的。另外，不容被忽視是為了通訊所做的額外工作也是耗時的，而且還不小，下圖的橙色部分就是為了兩個遠端節點的通訊額外做的事情。
所以我們不能以呼叫本地方法一樣的認知去理解遠端呼叫(RPC)。在目前的技術環境下，CPU 的運算能力長期保持高速增長，因此兩個節點間通訊的大部分場景中，延遲的耗時總是大於目標節點進行邏輯運算的耗時。
由此可得，並不是將一個集中式系統拆分得越散，系統就越快。當中存在的延遲，不容忽視。如果是基於提速為目的的拆分，至少是滿足下面這樣的條件的。
因為如果無法並行處理，反而會更慢，就像下面這樣。
關於這點，我們還需要慎重考慮是否有必要進行“同步”的 RPC 呼叫，以及儘量的降低呼叫次數等。這就是為什麼我們說，迴圈呼叫不如一次批次呼叫，反覆呼叫不如呼叫一次做程序內快取，同步呼叫比如非同步呼叫的道理。
3頻寬是有上限的
這個點，我相信你是知道的，因為當你透過 QQ、釘釘之類的工具傳輸或者下載一個大檔案時候，就發現它是存在上限的，這個上限是根據你的網路頻寬大小決定的。但是，為什麼你還是有可能會掉入這個陷阱裡呢?這往往由於你對所傳輸的資料的大小和頻率沒有充分的認識，導致了你覺得達到上限是一個很久遠的事情，不用考慮它。
舉個例子，你的網路都是基於 100M 頻寬標準搭建的。那麼此時如果每一秒會產生 10240 次資料傳輸，平均每個資料包大小是 10KB，我們來看下是否會遇到瓶頸。
100M 頻寬的理論傳輸速率是 12.5MB/ 秒。那麼現在每一秒需要傳輸：10240 次 / 秒 * 10KB = 100MB/ 秒。很明顯，頻寬遠遠不夠了。
關於頻寬上限，你需要明白這幾點：
1.實際環境中的傳輸速率大小，是由服務商所提供的頻寬大小，以及網絡卡、網絡卡、交換機、路由器所支援的傳輸速率中的最小值決定的。
2.內網與外網傳輸速率是不同的，一般都是內網大於外網。因為服務商所提供的頻寬成本更高。
3.同一個區域網內的節點是公用外網出入口的，所以儘可能的縮小在外網傳輸的資料，以降低佔用“獨木橋”外網的空間。
4分散式並不直接意味著是“敏捷”了
可能你曾經有過這樣的想法，當在規模較大的集中式系統中工作的時候，每次和許多人在一個程式碼庫裡提交程式碼，老是遇到衝突、排隊等待上游模組先開發等等。這時你會想，如果改造成分散式系統，這些問題都沒了，工作效率高多了。
答案是否定的，在前兩篇文章中也有提到一些。拆分後需要做的額外工作如果沒做好，可能會導致不是更快，而是更慢。最典型的現象如：
•釋出更麻煩了。原先雖然開發麻煩，但是釋出簡單啊，哪怕用最原始的方式：編譯一次，登上伺服器，複製黏貼，秒秒鐘搞定。而現在需要釋出 10 個、20 個、幾十個，再這樣操作很明顯要把人逼瘋。
•排查問題更難了。原本出了問題，不是在程式就是在資料庫。現在還得判斷在哪個程式，哪個資料庫，是不是要抓狂?
關於這點，你需要秉持著工欲善其事必先利其器的思想。將建設協作相關的輔助性工作與分散式系統同時進行。比如：監控告警系統、配置中心、服務發現，以及批次部署、持續整合，甚至 DevOps 等。
5資料由一份冗餘成多份後如何保持一致
這點其實是由於前面提到的網路因素產生的連帶效應。
當遇到資料庫壓力增大，響應開始變慢的時候，你可能會很容易想到，讓 DBA 來做個主從啊。但是，由於網路不可靠、存在延遲、頻寬有上限這一系列因素。所以，這個看似只是 Copy 一下工作，需要我們花大量的精力去解決。如何保證在使用不同副本上的資料的時候，都是符合應有的預期的。
關於這點，業界已經研究了幾十年，同時得出了許多具有指導意義的理論和思想。你需要充分的理解這些，並且能夠識別出合適的運用場景，就可以解決這個問題。這個概念在軟體領域被定義為「資料一致性」。
6整個系統的不同部分可能是異構的
先來看下「異構」的定義：
形容一個包含或者組成“異構網路”的產品，所謂的“異構網路”通常指不同廠家的產品所組成的網路。
比如，可以是裝有不同作業系統的伺服器、不同的資料庫產品、用不同的語言開發的產品等等。我們所處的整個全球網際網路就是“異構”的。
在系統初期，同類技術下的差異往往不太被關注。但是隨著分散式系統規模的逐漸擴大，在進入到成熟期的過程中，往往不可避免的會使系統成為異構的，有主動的，也有被動的。
•被動的。往往需要引入一些新的技術棧或者解決方案來解決當前的問題，因為很多時候不會有資源，也沒有必要去“重複造每一個輪子”。
•主動的。由於規模效應的影響越來越大，某些技術更適合在特定場景下發揮，因此能夠降低同等壓力下對資源的消耗，就可以明顯的降低成本。
關於這點，你要思考如何透過專制的方式進行標準化，來遮蔽這些差異帶來的複雜度影響，使得有更多的精力投入到有價值的地方去。專制的特點是“約束”效果，標準化透過專制來進行可以降低許多為了方便而妥協問題。比如每個節點都透過統一的遠端呼叫(RPC)中介軟體來做“連線”，就將如何連線異構節點的問題交由這個中介軟體來全權負責，而不是不同的團隊各自實現一套。
7總結
這次我們深入講解了分散式系統當中常見的一些“暗流”，而上面列舉的這些只能說是最常見的一些典型。在後續的文章中你會跟著我一起發現更多類似的“坑”，讓我們一起來尋找避開它們的方式吧。
希望你能時刻保持警惕之心，帶著沒有“完美方案”的心態在分散式系統中前行。
