分散式計算的八個謬誤 - Ably

1. 網路是可靠的。
2. 延遲為零。
3. 頻寬是無限的。
4. 網路是安全的。
5. 拓撲不會改變。
6. 有一名管理員。
7. 運輸成本為零。
8. 網路是同質的。

1.網路可靠
網路是複雜的、動態的，而且通常是不可預測的。許多原因可能導致網路故障或網路相關問題：交換機或電源故障、配置錯誤、整個資料中心變得不可用、DDoS 攻擊等。由於這種複雜性和普遍的不可預測性，網路是不可靠的。
從基礎架構的角度來看，您需要將系統設計為具有容錯性和高度冗餘性。
除了基礎設施方面的問題，您還需要考慮由於網路故障導致的連線斷開以及訊息和 API 呼叫丟失的問題。對於某些用例（例如，實時聊天應用程式），資料完整性至關重要，並且所有訊息都必須準確傳遞一次，以便終端使用者始終（即使涉及失敗）。為確保資料完整性，您的系統必須表現出有狀態的特徵。此外，您還需要自動重新連線和重試、重複資料刪除（或冪等性 ）等機制，以及強制執行訊息排序和保證交付的方法。

 

2.延遲為零
在設計系統時，您應該牢記延遲是網路的固有限制。我們永遠不應該假設傳送資料和接收資料之間不會有延遲或零延遲。
考慮到延遲，這裡還有其他幾件事需要考慮：

• 快取。 瀏覽器快取可以幫助改善延遲並減少傳送到伺服器的請求數量。您還可以使用 CDN 在全球多個位置快取資源。快取後，它們可以透過資料中心或最靠近客戶端的存在點進行檢索（而不是由源伺服器提供服務）。
• 使用事件驅動協議。根據您的用例的性質，您可能會考慮使用WebSockets 之類的通訊協議。與 HTTP 相比，WebSockets 的往返時間要短得多（一旦建立連線）。此外，WebSocket連線保持開啟狀態，允許資料被伺服器端和客戶端之間儘快來回傳遞變得可用，在實時-透過HTTP請求-響應模型顯著的改善。
• 伺服器效能。伺服器效能（處理速度、使用的硬體、可用 RAM）和延遲之間存在很強的相關性。為防止網路擁塞和伺服器超載，您需要能夠（動態）增加伺服器層的容量並重新分配負載。

3. 頻寬無限
網路的容量也不是無限的（部分原因是我們對生成和消費資料的需求也增加了）。當大量資料試圖流經網路，而頻寬支援不足時，可能會出現各種問題：

• 排隊延遲、瓶頸和網路擁塞。
• 導致服務質量低劣的資料包丟失，即訊息丟失或無序傳送。
• 糟糕的網路效能甚至整個系統的不穩定。

• 全面監測。跟蹤和檢查網路中的使用情況至關重要，這樣您就可以快速識別問題（例如，誰或什麼佔用了您的頻寬）並採取適當的補救措施。
• 多路複用。協議，如HTTP / 2，HTTP / 3，和的WebSockets所有支援複用，透過允許將資料從幾個來源結合併傳送它透過相同的通訊通道/介質提高頻寬利用率的技術。
• 輕量級資料格式。您可以使用為速度和效率而構建的資料交換格式（如JSON ）來保留網路頻寬。另一種選擇是MessagePack，這是一種緊湊的二進位制序列化格式，可以建立比 JSON 更小的訊息。
• 網路流量控制。您需要考慮使用諸如節流/速率限制、擁塞控制、指數退避等機制。

4. 網路安全
網路受到攻擊或破壞的方式有很多：漏洞、作業系統和庫中的漏洞、未加密的通訊、導致資料被未經授權方訪問的疏忽、病毒和惡意軟體、跨站點指令碼 (XSS) 和 DDoS 攻擊，僅舉幾例（但列表是無窮無盡的）。
這裡有幾件事情需要考慮：

• 威脅建模。建議使用結構化流程來識別潛在的安全威脅和漏洞，量化每個威脅和漏洞的嚴重性，並確定緩解攻擊的技術的優先順序。
• 縱深防禦。您應該使用分層方法，在網路、基礎設施和應用程式級別進行不同的安全檢查。
• 安全心態。在設計您的系統時，您應該牢記安全並遵循最佳實踐和行業建議和建議，例如  OWASP 的 Top 10 列表，其中涵蓋了您的系統應該配備以應對的最常見的 Web 應用程式安全風險。

5. 拓撲不變
網路拓撲是指網路的鏈路和節點的排列方式和相互關聯的方式。在分散式系統中，網路拓撲一直在變化。有時，這是出於意外原因或由於伺服器崩潰等問題。其他時候是故意的——我們新增、升級或刪除伺服器。
您可以為您的特定用例選擇最佳網路拓撲。請記住，您的系統需要能夠快速適應網路拓撲的變化，而不會影響服務可用性和正常執行時間。考慮到這一點，您不應將任何給定節點視為不可或缺的。
 

6. 管理員一名
在非常小的系統中，或者在個人專案的上下文中，可能只有一個管理員。除此之外，在幾乎所有現實生活場景中，分散式系統通常都有不止一個管理員。例如，考慮由不同團隊開發和管理的許多服務組成的現代雲原生系統。或者考慮使用您的系統的客戶也需要他們身邊的管理員來管理整合。
當你設計你的系統時，你應該讓不同的管理員能夠輕鬆（嗯，儘可能簡單）來管理它。您還需要考慮系統的彈性，並確保它不會受到與其互動的不同人員的影響。這裡有幾件事情需要考慮：

• 解耦系統元件。確保適當的解耦可以在計劃升級導致問題或計劃外事件（例如故障）的情況下提供更大的彈性。促進解耦（或鬆散耦合）的最流行的選項之一是pub/sub 模式。
• 使故障排除變得容易。提供對系統的可見性至關重要，以便管理員可以診斷和解決可能發生的問題。返回錯誤訊息並丟擲異常，以便管理員瞭解上下文並採取適當的措施來解決問題。此外，日誌記錄、指標和跟蹤（通常稱為可觀察性的三大支柱）應該是系統設計的關鍵方面。

7.運輸成本為零
首先，網路基礎設施是有成本的。伺服器、網路交換機、負載平衡器、代理、防火牆、操作和維護網路，使其安全，更不用說員工保持網路平穩執行——所有這些都需要花錢。網路越大，財務成本就越大。
除了財務，我們還必須考慮構建一個在高度可用、可靠和容錯的網路上工作的分散式系統所涉及的時間、精力和難度。將這種複雜性轉移到專門為此目的而設計的完全託管且經過實戰測試的解決方案中通常風險更小、更簡單且更具成本效益。
除了基礎設施方面，還有與透過網路傳輸資料相關的成本。從應用層到傳輸層需要時間和 CPU 資源。資訊需要在伺服器端進行處理和序列化（編組），然後再傳輸到客戶端，在客戶端需要進行反序列化。如果您希望降低傳輸成本，請避免使用 XML 或基於 XML 的選項，並改用輕量級序列化和反序列化格式，例如JSON、MessagePack或Protocol Buffers (Protobuf)。

 

8. 網路同質化
通常，甚至您的家庭網路也不是同質的。只要有兩個配置不同的裝置（例如，膝上型電腦或移動裝置）並使用不同的傳輸協議就足夠了，而且您的網路是異構的。
大多數分散式系統需要與多種型別的裝置整合，適應各種作業系統，與不同的瀏覽器一起工作，並與其他系統互動。因此，關注互操作性至關重要，從而確保所有這些元件儘管不同，但可以相互“交談”。
在可能的情況下，使用廣泛支援的開放標準協議，而不是專有協議。示例包括HTTP、WebSockets、SSE或MQTT。相同的邏輯適用於資料格式，其中 JSON 或 MessagePack 等選項通常是最佳選擇。