你在分布式系統(tǒng)上工作嗎？微服務(wù)，Web API，SOA，Web 服務(wù)器，應(yīng)用服務(wù)器，數(shù)據(jù)庫服務(wù)器，緩存服務(wù)器，負(fù)載均衡器 - 如果這些描述了系統(tǒng)設(shè)計(jì)中的組件，那么答案是肯定的。分布式系統(tǒng)由許多計(jì)算機(jī)組成，這些計(jì)算機(jī)協(xié)調(diào)以實(shí)現(xiàn)共同的目標(biāo)。

20 多年前，Peter Deutsch 和 James Gosling 定義了分布式計(jì)算的 8 個(gè)謬誤。這些是許多開發(fā)人員對(duì)分布式系統(tǒng)做出的錯(cuò)誤假設(shè)。從長遠(yuǎn)來看，這些通常被證明是錯(cuò)誤的，導(dǎo)致難以修復(fù)錯(cuò)誤。

八個(gè)謬誤是：

• 網(wǎng)絡(luò)可靠。
• 延遲為零。
• 帶寬是無限的。
• 網(wǎng)絡(luò)是安全的。
• 拓?fù)洳粫?huì)改變。
• 有一個(gè)管理員。
• 運(yùn)輸成本為零。
• 網(wǎng)絡(luò)是同質(zhì)的。

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

1、網(wǎng)絡(luò)可靠

問題

通過網(wǎng)絡(luò)呼叫將失敗。

今天的大多數(shù)系統(tǒng)都會(huì)調(diào)用其他系統(tǒng)。您是否正在與第三方系統(tǒng)（支付網(wǎng)關(guān)，會(huì)計(jì)系統(tǒng)，CRM）集成？你在做網(wǎng)絡(luò)服務(wù)電話嗎？如果呼叫失敗會(huì)發(fā)生什么？如果您要查詢數(shù)據(jù)，則可以進(jìn)行簡單的重試。但是如果您發(fā)送命令會(huì)發(fā)生什么？我們舉一個(gè)簡單的例子：

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

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

解決方案

因此，如果網(wǎng)絡(luò)上的呼叫失敗，我們能做什么？好吧，我們可以自動(dòng)重試。排隊(duì)系統(tǒng)非常擅長這一點(diǎn)。它們通常使用稱為存儲(chǔ)和轉(zhuǎn)發(fā)的模式。它們?cè)趯⑾⑥D(zhuǎn)發(fā)給收件人之前在本地存儲(chǔ)消息。如果收件人處于脫機(jī)狀態(tài)，則排隊(duì)系統(tǒng)將重試發(fā)送郵件。MSMQ 是這種排隊(duì)系統(tǒng)的一個(gè)例子。

但是這種變化將對(duì)您的系統(tǒng)設(shè)計(jì)產(chǎn)生重大影響。您正在從請(qǐng)求/響應(yīng)模型轉(zhuǎn)移到觸發(fā)并忘記。由于您不再等待響應(yīng)，因此您需要更改系統(tǒng)中的用戶行程。您不能只使用隊(duì)列發(fā)送替換每個(gè) Web 服務(wù)調(diào)用。

結(jié)論

你可能會(huì)說網(wǎng)絡(luò)現(xiàn)在更可靠 - 而且它們是。但事情發(fā)生了。硬件和軟件可能會(huì)出現(xiàn)故障 - 電源，路由器，更新或補(bǔ)丁失敗，無線信號(hào)弱，網(wǎng)絡(luò)擁塞，嚙齒動(dòng)物或鯊魚。是的，鯊魚：在一系列鯊魚叮咬之后，谷歌正在加強(qiáng)與 Kevlar 的海底數(shù)據(jù)線。

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

這是否意味著您需要?jiǎng)h除當(dāng)前的技術(shù)堆棧并使用消息傳遞系統(tǒng)？并不是的！您需要權(quán)衡失敗的風(fēng)險(xiǎn)與您需要進(jìn)行的投資。您可以通過投資基礎(chǔ)架構(gòu)和軟件來最小化失敗的可能性。在許多情況下，失敗是一種選擇。但在設(shè)計(jì)分布式系統(tǒng)時(shí)，您確實(shí)需要考慮失敗的問題。

2、延遲是零

問題

通過網(wǎng)絡(luò)撥打電話不是即時(shí)的。

內(nèi)存呼叫和互聯(lián)網(wǎng)呼叫之間存在七個(gè)數(shù)量級(jí)的差異。您的應(yīng)用程序應(yīng)該是網(wǎng)絡(luò)感知。這意味著您應(yīng)該清楚地將本地呼叫與遠(yuǎn)程呼叫分開。讓我們看看我在代碼庫中看到的一個(gè)例子：

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

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

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

您不希望財(cái)產(chǎn)獲取者進(jìn)行網(wǎng)絡(luò)呼叫。但是，每個(gè)。在上面的代碼中調(diào)用實(shí)際上可以觸發(fā)數(shù)據(jù)庫之旅。

解決方案

帶回您可能需要的所有數(shù)據(jù)

如果您進(jìn)行遠(yuǎn)程呼叫，請(qǐng)確?；謴?fù)可能需要的所有數(shù)據(jù)。網(wǎng)絡(luò)通信不應(yīng)該是嘮叨的。

將 Data Closer 移動(dòng)到客戶端

另一種可能的解決方案是將數(shù)據(jù)移近客戶端。如果您正在使用云，請(qǐng)根據(jù)客戶的位置仔細(xì)選擇可用區(qū)。緩存還可以幫助最小化網(wǎng)絡(luò)呼叫的數(shù)量。對(duì)于靜態(tài)內(nèi)容，內(nèi)容交付網(wǎng)絡(luò)（CDN）是另一個(gè)不錯(cuò)的選擇。

反轉(zhuǎn)數(shù)據(jù)流

刪除遠(yuǎn)程調(diào)用的另一個(gè)選項(xiàng)是反轉(zhuǎn)數(shù)據(jù)流。我們可以使用 Pub / Sub 并在本地存儲(chǔ)數(shù)據(jù)，而不是查詢其他服務(wù)。這樣，我們就可以在需要時(shí)獲取數(shù)據(jù)。當(dāng)然，這會(huì)帶來一些復(fù)雜性，但它可能是工具箱中的一個(gè)很好的工具。

結(jié)論

雖然延遲可能不是 LAN 中的問題，但當(dāng)您轉(zhuǎn)移到 WAN 或 Internet 時(shí)，您會(huì)注意到延遲。這就是為什么將網(wǎng)絡(luò)呼叫與內(nèi)存中的呼叫明確分開是很重要的。在采用微服務(wù)架構(gòu)模式時(shí)，您應(yīng)該牢記這一點(diǎn)。您不應(yīng)該只使用遠(yuǎn)程調(diào)用替換本地呼叫。這可能會(huì)使你的系統(tǒng)變成分布式的大泥球。

3、帶寬是無限的

問題

帶寬是有限的。

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

錯(cuò)誤地使用 ORM 也會(huì)造成傷害。我見過開發(fā)人員在查詢中過早調(diào)用.ToList（）的示例，因此在內(nèi)存中加載整個(gè)表。

解決方案

領(lǐng)域驅(qū)動(dòng)的設(shè)計(jì)模式

那么我們?cè)鯓硬拍艽_保我們不會(huì)帶來太多數(shù)據(jù)呢？域驅(qū)動(dòng)設(shè)計(jì)模式可以幫助：

首先，您不應(yīng)該爭取單一的企業(yè)級(jí)域模型。您應(yīng)該將域劃分為有界上下文。

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

命令和查詢責(zé)任隔離

我們有時(shí)會(huì)加載復(fù)雜的對(duì)象圖，因?yàn)槲覀冃枰谄聊簧巷@示它的一部分。如果我們?cè)诤芏嗟胤竭@樣做，我們最終會(huì)得到一個(gè)龐大而復(fù)雜的模型，對(duì)于寫作和閱讀來說都是次優(yōu)的。另一種方法可以是使用命令和查詢責(zé)任隔離 - CQRS。這意味著將域模型分為兩部分：

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

結(jié)論

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

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

4、網(wǎng)絡(luò)是安全的

問題

網(wǎng)絡(luò)并不安全。

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

解決方案

深度防御

您應(yīng)該使用分層方法來保護(hù)您的系統(tǒng)。您需要在網(wǎng)絡(luò)，基礎(chǔ)架構(gòu)和應(yīng)用程序級(jí)別進(jìn)行不同的安全檢查。

安全心態(tài)

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

威脅建模

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

結(jié)論

唯一安全的系統(tǒng)是關(guān)閉電源的系統(tǒng)，不連接到任何網(wǎng)絡(luò)（理想情況下是在一個(gè)有形模塊中）。它是多么有用的系統(tǒng)！事實(shí)是，安全是艱難而昂貴的。分布式系統(tǒng)中有許多組件和鏈接，每個(gè)組件和鏈接都是惡意用戶的可能目標(biāo)。企業(yè)需要平衡攻擊的風(fēng)險(xiǎn)和概率與實(shí)施預(yù)防機(jī)制的成本。

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

5、拓?fù)洳粫?huì)改變

問題

網(wǎng)絡(luò)拓?fù)洳粩嘧兓?/p>

網(wǎng)絡(luò)拓?fù)涫冀K在變化。有時(shí)它會(huì)因意外原因而發(fā)生變化 - 當(dāng)您的應(yīng)用服務(wù)器出現(xiàn)故障并需要更換時(shí)。很多時(shí)候它是故意的 - 在新服務(wù)器上添加新進(jìn)程。如今，隨著云和容器的增加，這一點(diǎn)更加明顯。彈性擴(kuò)展 - 根據(jù)工作負(fù)載添加或刪除服務(wù)器的能力 - 需要一定程度的網(wǎng)絡(luò)靈活性。

解決方案

摘要網(wǎng)絡(luò)的物理結(jié)構(gòu)

您需要做的第一件事是抽象網(wǎng)絡(luò)的物理結(jié)構(gòu)。有幾種方法可以做到這一點(diǎn)：

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

無價(jià)值的，而非重要的

通過將您的服務(wù)器視為沒有價(jià)值的，而不是很重要的，您確保沒有服務(wù)器是不可替代的。這一點(diǎn)智慧可以幫助您進(jìn)入正確的思維模式：任何服務(wù)器都可能出現(xiàn)故障（從而改變拓?fù)浣Y(jié)構(gòu)），因此您應(yīng)該盡可能地自動(dòng)化。

測試

最后一條建議是測試你的假設(shè)。停止服務(wù)或關(guān)閉服務(wù)器，看看您的系統(tǒng)是否仍在運(yùn)行。像 Netflix 的 Chaos Monkey 這樣的工具可以通過隨機(jī)關(guān)閉生產(chǎn)環(huán)境中的 VM 或容器來實(shí)現(xiàn)這一目標(biāo)。通過帶來痛苦，您更有動(dòng)力構(gòu)建一個(gè)可以處理拓?fù)涓牡母邚椥缘南到y(tǒng)。

結(jié)論

十年前，大多數(shù)拓?fù)浣Y(jié)構(gòu)并沒有經(jīng)常改變。但是當(dāng)它發(fā)生時(shí)，它可能發(fā)生在生產(chǎn)中并引入了一些停機(jī)時(shí)間。如今，隨著云和容器的增加，很難忽視這種謬誤。你需要為失敗做好準(zhǔn)備并進(jìn)行測試。不要等到它在生產(chǎn)中發(fā)生！

6、有一位管理員

問題

這個(gè)知道一切的并不存在。

嗯，這個(gè)看起來很明顯。當(dāng)然，沒有一個(gè)人知道一切。這是一個(gè)問題嗎？只要應(yīng)用程序運(yùn)行順利，它就不是。但是，當(dāng)出現(xiàn)問題時(shí)，您需要修復(fù)它。因?yàn)楹芏嗳擞|摸了應(yīng)用程序，知道如何解決問題的人可能不在那里。

有很多事情可能會(huì)出錯(cuò)。一個(gè)例子是配置。今天的應(yīng)用程序在多個(gè)商店中存儲(chǔ)配置：配置文件，環(huán)境變量，數(shù)據(jù)庫，命令行參數(shù)。沒有人知道每個(gè)可能的配置值的影響是什么。

另一件可能出錯(cuò)的事情是系統(tǒng)升級(jí)。分布式應(yīng)用程序有許多移動(dòng)部件，您需要確保它們是同步的。例如，您需要確保當(dāng)前版本的代碼適用于當(dāng)前版本的數(shù)據(jù)庫。如今，人們關(guān)注 DevOps 和持續(xù)交付。但支持零停機(jī)部署并非易事。

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

解決方案

每個(gè)人都應(yīng)對(duì)釋放過程負(fù)責(zé)

這意味著從一開始就涉及 Ops 人員或系統(tǒng)管理員。理想情況下，他們將成為團(tuán)隊(duì)的一員。盡早讓系統(tǒng)管理員了解您的進(jìn)度可以幫助您發(fā)現(xiàn)限制因素。例如，生產(chǎn)環(huán)境可能具有與開發(fā)環(huán)境不同的配置，安全限制，防火墻規(guī)則或可用端口。

記錄和監(jiān)控

系統(tǒng)管理員應(yīng)該擁有用于錯(cuò)誤報(bào)告和管理問題的正確工具。你應(yīng)該從一開始就考慮監(jiān)控。分布式系統(tǒng)應(yīng)具有集中式日志。訪問十個(gè)不同服務(wù)器上的日志以調(diào)查問題是不可接受的方法。

解耦

您應(yīng)該在系統(tǒng)升級(jí)期間爭取最少的停機(jī)時(shí)間。這意味著您應(yīng)該能夠獨(dú)立升級(jí)系統(tǒng)的不同部分。通過使組件向后兼容，您可以在不同時(shí)間更新服務(wù)器和客戶端。

通過在組件之間放置隊(duì)列，您可以暫時(shí)將它們分離。這意味著，例如，即使后端關(guān)閉，Web 服務(wù)器仍然可以接受請(qǐng)求。

隔離第三方依賴關(guān)系

您應(yīng)該以不同于您擁有的組件的方式處理控制之外的系統(tǒng)。這意味著使您的系統(tǒng)更能適應(yīng)第三方故障。您可以通過引入抽象層來減少外部依賴的影響。這意味著當(dāng)?shù)谌较到y(tǒng)出現(xiàn)故障時(shí)，您將找到更少的地方來查找錯(cuò)誤。

結(jié)論

要解決這個(gè)謬論，您需要使系統(tǒng)易于管理。DevOps，日志記錄和監(jiān)控可以提供幫助。您還需要考慮系統(tǒng)的升級(jí)過程。如果升級(jí)需要數(shù)小時(shí)的停機(jī)時(shí)間，則無法部署每個(gè) sprint。沒有一個(gè)管理員，所以每個(gè)人都應(yīng)該對(duì)發(fā)布過程負(fù)責(zé)。

7、運(yùn)輸成本為零

問題

運(yùn)輸成本 不是 零。

這種謬論與第二個(gè)謬誤有關(guān)，即 延遲為零。通過網(wǎng)絡(luò)傳輸內(nèi)容在時(shí)間和資源上都有代價(jià)。如果第二個(gè)謬誤討論了時(shí)間方面，那么謬誤＃7 就會(huì)解決資源消耗問題。

這種謬論有兩個(gè)不同的方面：

網(wǎng)絡(luò)基礎(chǔ)設(shè)施的成本

網(wǎng)絡(luò)基礎(chǔ)設(shè)施需要付出代價(jià)。服務(wù)器，SAN，網(wǎng)絡(luò)交換機(jī)，負(fù)載平衡器以及負(fù)責(zé)此設(shè)備的人員 - 所有這些都需要花錢。如果您的系統(tǒng)是在內(nèi)部部署的，那么您需要預(yù)先支付這個(gè)價(jià)格。如果您正在使用云，那么您只需為您使用的內(nèi)容付費(fèi)，但您仍然需要付費(fèi)。

序列化/反序列化的成本

這種謬誤的第二個(gè)方面是在傳輸級(jí)別和應(yīng)用程序級(jí)別之間傳輸數(shù)據(jù)的成本。序列化和反序列化會(huì)消耗 CPU 時(shí)間，因此需要花錢。如果您的應(yīng)用程序是內(nèi)部部署的，那么如果您不主動(dòng)監(jiān)視資源消耗，則會(huì)隱藏此成本。但是，如果您的應(yīng)用程序部署在云端，那么這筆費(fèi)用就會(huì)非常明顯，因?yàn)槟枰獮槭褂玫膬?nèi)容付費(fèi)。

解決方案

關(guān)于基礎(chǔ)設(shè)施的成本，你無能為力。您只能確保盡可能高效地使用它。SOAP 或 XML 比 JSON 更昂貴。JSON 比像 Google 的 Protocol Buffers 這樣的二進(jìn)制協(xié)議更昂貴。根據(jù)系統(tǒng)的類型，這可能或多或少重要。例如，對(duì)于與視頻流或 VoIP 有關(guān)的應(yīng)用，傳輸成本更為重要。

結(jié)論

您應(yīng)該注意運(yùn)輸成本以及應(yīng)用程序正在執(zhí)行的序列化和反序列化程度。這并不意味著您應(yīng)該優(yōu)化，除非需要它。您應(yīng)該對(duì)資源消耗進(jìn)行基準(zhǔn)測試和監(jiān)控，并確定運(yùn)輸成本是否對(duì)您有用。

8、網(wǎng)絡(luò)是同質(zhì)的

問題

網(wǎng)絡(luò) 不是 同質(zhì)的。

同質(zhì)網(wǎng)絡(luò)是使用類似配置和相同通信協(xié)議的計(jì)算機(jī)網(wǎng)絡(luò)。擁有類似配置的計(jì)算機(jī)是一項(xiàng)艱巨的任務(wù)。例如，您幾乎無法控制哪些移動(dòng)設(shè)備可以連接到您的應(yīng)用。這就是為什么重點(diǎn)關(guān)注標(biāo)準(zhǔn)協(xié)議。

解決方案

您應(yīng)該選擇標(biāo)準(zhǔn)格式以避免供應(yīng)商鎖定。這可能意味著 XML，JSON 或協(xié)議緩沖區(qū)。有很多選擇可供選擇。

結(jié)論

您需要確保系統(tǒng)的組件可以相互通信。使用專有協(xié)議會(huì)損害應(yīng)用程序的互操作性。

設(shè)計(jì)分布式系統(tǒng)很難

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

我們必須接受這些事實(shí)：網(wǎng)絡(luò)不可靠，不安全并且需要花錢。帶寬有限。網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)將發(fā)生變化。其組件的配置方式不同。意識(shí)到這些限制將有助于我們?cè)O(shè)計(jì)更好的分布式系統(tǒng)。