分散式系統中最容易被忽視的六大「暗流」

作者 | 張帆

編輯 | 小智

任何事物都有兩面性。你只有了解了分散式系統背後的「暗流涌動」現象是什麼，才能避免掉到「坑」里去。暗流的含義是流動的地下水，是潛伏在「深層」的，我們往往過度地沉迷於表面的美好，而忽略了它。在分散式系統當中，最容易被我們忽略的是本文將介紹的這六大「暗流」。

本文是分散式系統系列第三篇文章，前兩篇傳送門：

1

網路並不是可靠的

你應該明白，分散式系統中不同節點間的通信是基於網路的。網路使得它們連接起來共同協作。

然而，光纜被挖斷的事件相信你也看到過不是一兩次了。除此之外，網卡異常、交換機故障、遭受惡意攻擊等導致的網路擁塞、網路中斷、報文丟失的種種跡象皆意味著網路隨時可能無法正常運作，是不可靠的。

此時，需要在你的系統設計中，儘可能地考慮到：當前節點所依賴的其他節點由於各種原因無法與之正常通信時，該如何保證其依然能夠提供部分或者完整的服務。這個概念在軟體領域被定義為「魯棒性」。

2

不同節點之間的通信是存在延遲的

網路連接的是處於不同物理位置上的節點，學過物理和數學你的應該明白，兩點之間是存在「距離」的，而我們的分散式系統需要在這個距離之上進行數據的傳遞，本質上就是物質的傳遞。同時應該你也知道，物質的運動速度不會超過光速。所以，不同節點之間的通信是需要經過一段時間的，也就意味著會存在延遲。具體的延遲是由所用的傳輸介質、節點當前的負載大小所決定的。另外，不容被忽視是為了通訊所做的額外工作也是耗時的，而且還不小，下圖的橙色部分就是為了兩個遠程節點的通訊額外做的事情。

所以我們不能以調用本地方法一樣的認知去理解遠程調用（RPC）。在目前的技術環境下，CPU 的運算能力長期保持高速增長，因此兩個節點間通訊的大部分場景中，延遲的耗時總是大於目標節點進行邏輯運算的耗時。

由此可得，並不是將一個集中式系統拆分得越散，系統就越快。當中存在的延遲，不容忽視。如果是基於提速為目的的拆分，至少是滿足下面這樣的條件的。

因為如果無法並行處理，反而會更慢，就像下面這樣。

關於這點，我們還需要慎重考慮是否有必要進行「同步」的 RPC 調用，以及盡量的降低調用次數等。這就是為什麼我們說，循環調用不如一次批量調用，反覆調用不如調用一次做進程內緩存，同步調用比如非同步調用的道理。

3

帶寬是有上限的

這個點，我相信你是知道的，因為當你通過 QQ、釘釘之類的工具傳輸或者下載一個大文件時候，就發現它是存在上限的，這個上限是根據你的網路帶寬大小決定的。但是，為什麼你還是有可能會掉入這個陷阱里呢？這往往由於你對所傳輸的數據的大小和頻率沒有充分的認識，導致了你覺得達到上限是一個很久遠的事情，不用考慮它。

舉個例子，你的網路都是基於 100M 帶寬標準搭建的。那麼此時如果每一秒會產生 10240 次數據傳輸，平均每個數據包大小是 10KB，我們來看下是否會遇到瓶頸。

100M 帶寬的理論傳輸速率是 12.5MB/ 秒。那麼現在每一秒需要傳輸：10240 次 / 秒 * 10KB = 100MB/ 秒。很明顯，帶寬遠遠不夠了。

關於帶寬上限，你需要明白這幾點：

實際環境中的傳輸速率大小，是由服務商所提供的帶寬大小，以及網卡、網卡、交換機、路由器所支持的傳輸速率中的最小值決定的。

內網與外網傳輸速率是不同的，一般都是內網大於外網。因為服務商所提供的帶寬成本更高。

同一個區域網內的節點是公用外網出入口的，所以儘可能的縮小在外網傳輸的數據，以降低佔用「獨木橋」外網的空間。

4

分散式並不直接意味著是「敏捷」了

可能你曾經有過這樣的想法，當在規模較大的集中式系統中工作的時候，每次和許多人在一個代碼庫里提交代碼，老是遇到衝突、排隊等待上游模塊先開發等等。這時你會想，如果改造成分散式系統，這些問題都沒了，工作效率高多了。

答案是否定的，在前兩篇文章中也有提到一些。拆分後需要做的額外工作如果沒做好，可能會導致不是更快，而是更慢。最典型的現象如：

發布更麻煩了。原先雖然開發麻煩，但是發布簡單啊，哪怕用最原始的方式：編譯一次，登上伺服器，複製黏貼，秒秒鐘搞定。而現在需要發布 10 個、20 個、幾十個，再這樣操作很明顯要把人逼瘋。

排查問題更難了。原本出了問題，不是在程序就是在資料庫。現在還得判斷在哪個程序，哪個資料庫，是不是要抓狂？

關於這點，你需要秉持著工欲善其事必先利其器的思想。將建設協作相關的輔助性工作與分散式系統同時進行。比如：監控告警系統、配置中心、服務發現，以及批量部署、持續集成，甚至 DevOps 等。

5

數據由一份冗餘成多份後如何保持一致

這點其實是由於前面提到的網路因素產生的連帶效應。

當遇到資料庫壓力增大，響應開始變慢的時候，你可能會很容易想到，讓 DBA 來做個主從啊。但是，由於網路不可靠、存在延遲、帶寬有上限這一系列因素。所以，這個看似只是 Copy 一下工作，需要我們花大量的精力去解決如何保證在使用不同副本上的數據的時候，都是符合應有的預期的。

關於這點，業界已經研究了幾十年，同時得出了許多具有指導意義的理論和思想。你需要充分的理解這些，並且能夠識別出合適的運用場景，就可以解決這個問題。這個概念在軟體領域被定義為「數據一致性」。

6

整個系統的不同部分可能是異構的

先來看下「異構」的定義：

形容一個包含或者組成「異構網路」的產品，所謂的「異構網路」通常指不同廠家的產品所組成的網路。

比如，可以是裝有不同操作系統的伺服器、不同的資料庫產品、用不同的語言開發的產品等等。我們所處的整個全球互聯網就是「異構」的。

在系統初期，同類技術下的差異往往不太被關注。但是隨著分散式系統規模的逐漸擴大，在進入到成熟期的過程中，往往不可避免的會使系統成為異構的，有主動的，也有被動的。

被動的。往往需要引入一些新的技術棧或者解決方案來解決當前的問題，因為很多時候不會有資源，也沒有必要去「重複造每一個輪子」。

主動的。由於規模效應的影響越來越大，某些技術更適合在特定場景下發揮，因此能夠降低同等壓力下對資源的消耗，就可以明顯的降低成本。

關於這點，你要思考如何通過專制的方式進行標準化，來屏蔽這些差異帶來的複雜度影響，使得有更多的精力投入到有價值的地方去。專制的特點是「約束」效果，標準化通過專制來進行可以降低許多為了方便而妥協問題。比如每個節點都通過統一的遠程調用（RPC）中間件來做「連接」，就將如何連接異構節點的問題交由這個中間件來全權負責，而不是不同的團隊各自實現一套。

7

總結

這次我們深入講解了分散式系統當中常見的一些「暗流」，而上面列舉的這些只能說是最常見的一些典型。在後續的文章中你會跟著我一起發現更多類似的「坑」，讓我們一起來尋找避開它們的方式吧。

希望你能時刻保持警惕之心，帶著沒有「完美方案」的心態在分散式系統中前行。

從下一篇文章起，將正式開始講解做好分散式系統需要掌握的一個個核心要點，我會力爭儘可能的深入淺出，讓你能夠深刻理解每個要點的作用，如何用好它，以及最佳實踐等等。

8

Q 言 Q 語時刻

你在平時的項目開發中有遇到過哪些「坑」嗎？可以在下方評論框給我們留言。

9

本文彩蛋

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！