你在分布式系統上工作嗎？微服務，Web API，SOA，Web 服務器，應用服務器，數據庫服務器，緩存服務器，負載均衡器 - 如果這些描述了系統設計中的組件，那么答案是肯定的。分布式系統由許多計算機組成，這些計算機協調以實現共同的目標。

20 多年前，Peter Deutsch 和 James Gosling 定義了分布式計算的 8 個謬誤。這些是許多開發人員對分布式系統做出的錯誤假設。從長遠來看，這些通常被證明是錯誤的，導致難以修復錯誤。

八個謬誤是：

• 網絡可靠。
• 延遲為零。
• 帶寬是無限的。
• 網絡是安全的。
• 拓撲不會改變。
• 有一個管理員。
• 運輸成本為零。
• 網絡是同質的。

讓我們來看看每個謬誤，討論問題和潛在的解決方案。

1、網絡可靠

問題

通過網絡呼叫將失敗。

今天的大多數系統都會調用其他系統。您是否正在與第三方系統（支付網關，會計系統，CRM）集成？你在做網絡服務電話嗎？如果呼叫失敗會發生什么？如果您要查詢數據，則可以進行簡單的重試。但是如果您發送命令會發生什么？我們舉一個簡單的例子：

var creditCardProcessor = new CreditCardPaymentService();
creditCardProcessor.Charge(chargeRequest);

如果我們收到 HTTP 超時異常會怎么樣？如果服務器沒有處理請求，那么我們可以重試。但是，如果它確實處理了請求，我們需要確保我們不會對客戶進行雙重收費。您可以通過使服務器具有冪等性來實現此目的。這意味著如果您使用相同的收費請求撥打 10 次，則客戶只需支付一次費用。如果您沒有正確處理這些錯誤，那么您的系統是不確定的。處理所有這些情況可能會非常復雜。

解決方案

因此，如果網絡上的呼叫失敗，我們能做什么？好吧，我們可以自動重試。排隊系統非常擅長這一點。它們通常使用稱為存儲和轉發的模式。它們在將消息轉發給收件人之前在本地存儲消息。如果收件人處于脫機狀態，則排隊系統將重試發送郵件。MSMQ 是這種排隊系統的一個例子。

但是這種變化將對您的系統設計產生重大影響。您正在從請求/響應模型轉移到觸發并忘記。由于您不再等待響應，因此您需要更改系統中的用戶行程。您不能只使用隊列發送替換每個 Web 服務調用。

結論

你可能會說網絡現在更可靠 - 而且它們是。但事情發生了。硬件和軟件可能會出現故障 - 電源，路由器，更新或補丁失敗，無線信號弱，網絡擁塞，嚙齒動物或鯊魚。是的，鯊魚：在一系列鯊魚叮咬之后，谷歌正在加強與 Kevlar 的海底數據線。

還有人為因素。人們可以開始 DDOS 攻擊，也可以破壞物理設備。

這是否意味著您需要刪除當前的技術堆棧并使用消息傳遞系統？并不是的！您需要權衡失敗的風險與您需要進行的投資。您可以通過投資基礎架構和軟件來最小化失敗的可能性。在許多情況下，失敗是一種選擇。但在設計分布式系統時，您確實需要考慮失敗的問題。

2、延遲是零

問題

通過網絡撥打電話不是即時的。

內存呼叫和互聯網呼叫之間存在七個數量級的差異。您的應用程序應該是網絡感知。這意味著您應該清楚地將本地呼叫與遠程呼叫分開。讓我們看看我在代碼庫中看到的一個例子：

var viewModel = new ViewModel();
var documents = new DocumentsCollection();
foreach (var document in documents)
{
 var snapshot = document.GetSnapshot();
 viewModel.Add(snapshot);
}

沒有進一步檢查，這看起來很好。但是，有兩個遠程呼叫。第 2 行進行一次調用以獲取文檔摘要列表。在第 5 行，還有另一個調用，它檢索有關每個文檔的更多信息。這是一個經典的 Select n + 1 問題。為了解決網絡延遲問題，您應該在一次調用中返回所有必需的數據。一般的建議是本地調用可以細粒度，但遠程調用應該更粗粒度。這就是為什么分布式對象和網絡透明度的想法死了。但是，即使每個人都同意分布式對象是一個壞主意，有些人仍然認為延遲加載總是一個好主意：

var employee = EmployeeRepository.GetBy(someCriteria)
var department = employee.Department;
var manager = department.Manager;
foreach (var peer in manager.Employees;)
{
// do something
}

您不希望財產獲取者進行網絡呼叫。但是，每個。在上面的代碼中調用實際上可以觸發數據庫之旅。

解決方案

帶回您可能需要的所有數據

如果您進行遠程呼叫，請確保恢復可能需要的所有數據。網絡通信不應該是嘮叨的。

將 Data Closer 移動到客戶端

另一種可能的解決方案是將數據移近客戶端。如果您正在使用云，請根據客戶的位置仔細選擇可用區。緩存還可以幫助最小化網絡呼叫的數量。對于靜態內容，內容交付網絡（CDN）是另一個不錯的選擇。

反轉數據流

刪除遠程調用的另一個選項是反轉數據流。我們可以使用 Pub / Sub 并在本地存儲數據，而不是查詢其他服務。這樣，我們就可以在需要時獲取數據。當然，這會帶來一些復雜性，但它可能是工具箱中的一個很好的工具。

結論

雖然延遲可能不是 LAN 中的問題，但當您轉移到 WAN 或 Internet 時，您會注意到延遲。這就是為什么將網絡呼叫與內存中的呼叫明確分開是很重要的。在采用微服務架構模式時，您應該牢記這一點。您不應該只使用遠程調用替換本地呼叫。這可能會使你的系統變成分布式的大泥球。

3、帶寬是無限的

問題

帶寬是有限的。

帶寬是網絡在一段時間內發送數據的容量。到目前為止，我還沒有發現它是一個問題，但我可以看到為什么它在某些條件下可能是一個問題。雖然帶寬隨著時間的推移而有所改善，但我們發送的數據量也有所增加。與通過網絡傳遞簡單 DTO 的應用相比，視頻流或 VoIP 需要更多帶寬。帶寬對于移動應用程序來說更為重要，因此開發人員在設計后端 API 時需要考慮它。

錯誤地使用 ORM 也會造成傷害。我見過開發人員在查詢中過早調用.ToList（）的示例，因此在內存中加載整個表。

解決方案

領域驅動的設計模式

那么我們怎樣才能確保我們不會帶來太多數據呢？域驅動設計模式可以幫助：

首先，您不應該爭取單一的企業級域模型。您應該將域劃分為有界上下文。

要避免有界上下文中的大型復雜對象圖，可以使用聚合模式。聚合確保一致性并定義事務邊界。

命令和查詢責任隔離

我們有時會加載復雜的對象圖，因為我們需要在屏幕上顯示它的一部分。如果我們在很多地方這樣做，我們最終會得到一個龐大而復雜的模型，對于寫作和閱讀來說都是次優的。另一種方法可以是使用命令和查詢責任隔離 - CQRS。這意味著將域模型分為兩部分：

• 在寫模式將確保不變保持真實的數據是一致的。由于寫模型不關心視圖問題，因此可以保持較小且集中。
• 該讀取模型是視圖的擔憂進行了優化，所以我們可以獲取所有所需的特定視圖中的數據（例如，我們的應用程序的屏幕）。

結論

在第二個謬誤（延遲不是 0）和第三個謬誤（帶寬是無限的）之間有延伸，您應該傳輸更多數據，以最大限度地減少網絡往返次數。您應該傳輸較少的數據以最小化帶寬使用。您需要平衡這兩種力量，并找到通過線路發送的 正確 數據量。

雖然您可能不會經常遇到帶寬限制，但考慮傳輸的數據非常重要。更少的數據更容易理解。數據越少意味著耦合越少。因此，只傳輸您可能需要的數據。

4、網絡是安全的

問題

網絡并不安全。

這是一個比其他人更多的媒體報道的假設。您的系統僅與最薄弱的鏈接一樣安全。壞消息是分布式系統中有很多鏈接。您正在使用 HTTPS，除非與不支持它的第三方遺留系統進行通信。您正在查看自己的代碼，尋找安全問題，但正在使用可能存在風險的開源庫。一個 OpenSSL 的漏洞允許人們通過盜取 SSL / TLS 保護的數據。Apache Struts 中的一個錯誤允許攻擊者在服務器上執行代碼。即使你正在抵御所有這些，仍然存在人為因素。惡意 DBA 可能錯放數據庫備份。今天的攻擊者掌握著大量的計算能力和耐心。所以問題不在于他們是否會攻擊你的系統，而是什么時候。

解決方案

深度防御

您應該使用分層方法來保護您的系統。您需要在網絡，基礎架構和應用程序級別進行不同的安全檢查。

安全心態

在設計系統時要牢記安全性。十大漏洞列表在過去 5 年中沒有發生太大變化。您應遵循安全軟件設計的最佳實踐，并檢查常見安全漏洞的代碼。您應該定期搜索第三方庫以查找新漏洞。常見漏洞和暴露列表可以提供幫助。

威脅建模

威脅建模是一種識別系統中可能存在的安全威脅的系統方法。首先確定系統中的所有資產（數據庫中的用戶數據，文件等）以及如何訪問它們。之后，您可以識別可能的攻擊并開始執行它們。我建議閱讀高級 API 安全性的第 2 章，以便更好地概述威脅建模。

結論

唯一安全的系統是關閉電源的系統，不連接到任何網絡（理想情況下是在一個有形模塊中）。它是多么有用的系統！事實是，安全是艱難而昂貴的。分布式系統中有許多組件和鏈接，每個組件和鏈接都是惡意用戶的可能目標。企業需要平衡攻擊的風險和概率與實施預防機制的成本。

攻擊者手上有很多耐心和計算能力。我們可以通過使用威脅建模來防止某些類型的攻擊，但我們無法保證 100％的安全性。因此，向業務部門明確表示這一點是個好主意，共同決定投資安全性的程度，并制定安全漏洞何時發生的計劃。

5、拓撲不會改變

問題

網絡拓撲不斷變化。

網絡拓撲始終在變化。有時它會因意外原因而發生變化 - 當您的應用服務器出現故障并需要更換時。很多時候它是故意的 - 在新服務器上添加新進程。如今，隨著云和容器的增加，這一點更加明顯。彈性擴展 - 根據工作負載添加或刪除服務器的能力 - 需要一定程度的網絡靈活性。

解決方案

摘要網絡的物理結構

您需要做的第一件事是抽象網絡的物理結構。有幾種方法可以做到這一點：

• 停止硬編碼 IP - 您應該更喜歡使用主機名。通過使用 URI，我們依靠 DNS 將主機名解析為 IP。
• 當 DNS 不夠時（例如，當您需要映射 IP 和端口時），則使用發現服務。
• Service Bus 框架還可以提供位置透明性。

無價值的，而非重要的

通過將您的服務器視為沒有價值的，而不是很重要的，您確保沒有服務器是不可替代的。這一點智慧可以幫助您進入正確的思維模式：任何服務器都可能出現故障（從而改變拓撲結構），因此您應該盡可能地自動化。

測試

最后一條建議是測試你的假設。停止服務或關閉服務器，看看您的系統是否仍在運行。像 Netflix 的 Chaos Monkey 這樣的工具可以通過隨機關閉生產環境中的 VM 或容器來實現這一目標。通過帶來痛苦，您更有動力構建一個可以處理拓撲更改的更具彈性的系統。

結論

十年前，大多數拓撲結構并沒有經常改變。但是當它發生時，它可能發生在生產中并引入了一些停機時間。如今，隨著云和容器的增加，很難忽視這種謬誤。你需要為失敗做好準備并進行測試。不要等到它在生產中發生！

6、有一位管理員

問題

這個知道一切的并不存在。

嗯，這個看起來很明顯。當然，沒有一個人知道一切。這是一個問題嗎？只要應用程序運行順利，它就不是。但是，當出現問題時，您需要修復它。因為很多人觸摸了應用程序，知道如何解決問題的人可能不在那里。

有很多事情可能會出錯。一個例子是配置。今天的應用程序在多個商店中存儲配置：配置文件，環境變量，數據庫，命令行參數。沒有人知道每個可能的配置值的影響是什么。

另一件可能出錯的事情是系統升級。分布式應用程序有許多移動部件，您需要確保它們是同步的。例如，您需要確保當前版本的代碼適用于當前版本的數據庫。如今，人們關注 DevOps 和持續交付。但支持零停機部署并非易事。

但是，至少這些東西都在你的控制之下。許多應用程序與第三方系統交互。這意味著，如果它們失效，你可以做的事情就不多了。因此，即使您的系統有一名管理員，您仍然無法控制第三方系統。

解決方案

每個人都應對釋放過程負責

這意味著從一開始就涉及 Ops 人員或系統管理員。理想情況下，他們將成為團隊的一員。盡早讓系統管理員了解您的進度可以幫助您發現限制因素。例如，生產環境可能具有與開發環境不同的配置，安全限制，防火墻規則或可用端口。

記錄和監控

系統管理員應該擁有用于錯誤報告和管理問題的正確工具。你應該從一開始就考慮監控。分布式系統應具有集中式日志。訪問十個不同服務器上的日志以調查問題是不可接受的方法。

解耦

您應該在系統升級期間爭取最少的停機時間。這意味著您應該能夠獨立升級系統的不同部分。通過使組件向后兼容，您可以在不同時間更新服務器和客戶端。

通過在組件之間放置隊列，您可以暫時將它們分離。這意味著，例如，即使后端關閉，Web 服務器仍然可以接受請求。

隔離第三方依賴關系

您應該以不同于您擁有的組件的方式處理控制之外的系統。這意味著使您的系統更能適應第三方故障。您可以通過引入抽象層來減少外部依賴的影響。這意味著當第三方系統出現故障時，您將找到更少的地方來查找錯誤。

結論

要解決這個謬論，您需要使系統易于管理。DevOps，日志記錄和監控可以提供幫助。您還需要考慮系統的升級過程。如果升級需要數小時的停機時間，則無法部署每個 sprint。沒有一個管理員，所以每個人都應該對發布過程負責。

7、運輸成本為零

問題

運輸成本 不是 零。

這種謬論與第二個謬誤有關，即 延遲為零。通過網絡傳輸內容在時間和資源上都有代價。如果第二個謬誤討論了時間方面，那么謬誤＃7 就會解決資源消耗問題。

這種謬論有兩個不同的方面：

網絡基礎設施的成本

網絡基礎設施需要付出代價。服務器，SAN，網絡交換機，負載平衡器以及負責此設備的人員 - 所有這些都需要花錢。如果您的系統是在內部部署的，那么您需要預先支付這個價格。如果您正在使用云，那么您只需為您使用的內容付費，但您仍然需要付費。

序列化/反序列化的成本

這種謬誤的第二個方面是在傳輸級別和應用程序級別之間傳輸數據的成本。序列化和反序列化會消耗 CPU 時間，因此需要花錢。如果您的應用程序是內部部署的，那么如果您不主動監視資源消耗，則會隱藏此成本。但是，如果您的應用程序部署在云端，那么這筆費用就會非常明顯，因為您需要為使用的內容付費。

解決方案

關于基礎設施的成本，你無能為力。您只能確保盡可能高效地使用它。SOAP 或 XML 比 JSON 更昂貴。JSON 比像 Google 的 Protocol Buffers 這樣的二進制協議更昂貴。根據系統的類型，這可能或多或少重要。例如，對于與視頻流或 VoIP 有關的應用，傳輸成本更為重要。

結論

您應該注意運輸成本以及應用程序正在執行的序列化和反序列化程度。這并不意味著您應該優化，除非需要它。您應該對資源消耗進行基準測試和監控，并確定運輸成本是否對您有用。

8、網絡是同質的

問題

網絡 不是 同質的。

同質網絡是使用類似配置和相同通信協議的計算機網絡。擁有類似配置的計算機是一項艱巨的任務。例如，您幾乎無法控制哪些移動設備可以連接到您的應用。這就是為什么重點關注標準協議。

解決方案

您應該選擇標準格式以避免供應商鎖定。這可能意味著 XML，JSON 或協議緩沖區。有很多選擇可供選擇。

結論

您需要確保系統的組件可以相互通信。使用專有協議會損害應用程序的互操作性。

設計分布式系統很難

這些謬論發表于 20 多年前。但他們今天仍然堅持，其中一些比其他人更多。我認為今天許多開發人員都知道它們，但我們編寫的代碼并沒有顯示出來。

我們必須接受這些事實：網絡不可靠，不安全并且需要花錢。帶寬有限。網絡的拓撲結構將發生變化。其組件的配置方式不同。意識到這些限制將有助于我們設計更好的分布式系統。