建站
咨詢
售后
建站咨詢
新聞中心
你在分布式系統(tǒng)上工作嗎？微服務(wù)，Web API，SOA，Web 服務(wù)器，應(yīng)用服務(wù)器，數(shù)據(jù)庫服務(wù)器，緩存服務(wù)器，負(fù)載均衡器 - 如果這些描述了系統(tǒng)設(shè)計中的組件，那么答案是肯定的。分布式系統(tǒng)由許多計算機(jī)組成，這些計算機(jī)協(xié)調(diào)以實現(xiàn)共同的目標(biāo)。
為潁上等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及潁上網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都網(wǎng)站設(shè)計、成都網(wǎng)站制作、潁上網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！
20 多年前，Peter Deutsch 和 James Gosling 定義了分布式計算的 8 個謬誤。這些是許多開發(fā)人員對分布式系統(tǒng)做出的錯誤假設(shè)。從長遠(yuǎn)來看，這些通常被證明是錯誤的，導(dǎo)致難以修復(fù)錯誤。
八個謬誤是：
- 網(wǎng)絡(luò)可靠。
- 延遲為零。
- 帶寬是無限的。
- 網(wǎng)絡(luò)是安全的。
- 拓?fù)洳粫淖儭?/li>
- 有一個管理員。
- 運(yùn)輸成本為零。
- 網(wǎng)絡(luò)是同質(zhì)的。
讓我們來看看每個謬誤，討論問題和潛在的解決方案。
1、網(wǎng)絡(luò)可靠
問題
通過網(wǎng)絡(luò)呼叫將失敗。
今天的大多數(shù)系統(tǒng)都會調(diào)用其他系統(tǒng)。您是否正在與第三方系統(tǒng)（支付網(wǎng)關(guān)，會計系統(tǒng)，CRM）集成？你在做網(wǎng)絡(luò)服務(wù)電話嗎？如果呼叫失敗會發(fā)生什么？如果您要查詢數(shù)據(jù)，則可以進(jìn)行簡單的重試。但是如果您發(fā)送命令會發(fā)生什么？我們舉一個簡單的例子：
var creditCardProcessor = new CreditCardPaymentService();
creditCardProcessor.Charge(chargeRequest);
如果我們收到 HTTP 超時異常會怎么樣？如果服務(wù)器沒有處理請求，那么我們可以重試。但是，如果它確實處理了請求，我們需要確保我們不會對客戶進(jìn)行雙重收費(fèi)。您可以通過使服務(wù)器具有冪等性來實現(xiàn)此目的。這意味著如果您使用相同的收費(fèi)請求撥打 10 次，則客戶只需支付一次費(fèi)用。如果您沒有正確處理這些錯誤，那么您的系統(tǒng)是不確定的。處理所有這些情況可能會非常復(fù)雜。
解決方案
因此，如果網(wǎng)絡(luò)上的呼叫失敗，我們能做什么？好吧，我們可以自動重試。排隊系統(tǒng)非常擅長這一點。它們通常使用稱為存儲和轉(zhuǎn)發(fā)的模式。它們在將消息轉(zhuǎn)發(fā)給收件人之前在本地存儲消息。如果收件人處于脫機(jī)狀態(tài)，則排隊系統(tǒng)將重試發(fā)送郵件。MSMQ 是這種排隊系統(tǒng)的一個例子。
但是這種變化將對您的系統(tǒng)設(shè)計產(chǎn)生重大影響。您正在從請求/響應(yīng)模型轉(zhuǎn)移到觸發(fā)并忘記。由于您不再等待響應(yīng)，因此您需要更改系統(tǒng)中的用戶行程。您不能只使用隊列發(fā)送替換每個 Web 服務(wù)調(diào)用。
結(jié)論
你可能會說網(wǎng)絡(luò)現(xiàn)在更可靠 - 而且它們是。但事情發(fā)生了。硬件和軟件可能會出現(xiàn)故障 - 電源，路由器，更新或補(bǔ)丁失敗，無線信號弱，網(wǎng)絡(luò)擁塞，嚙齒動物或鯊魚。是的，鯊魚：在一系列鯊魚叮咬之后，谷歌正在加強(qiáng)與 Kevlar 的海底數(shù)據(jù)線。
還有人為因素。人們可以開始 DDOS 攻擊，也可以破壞物理設(shè)備。
這是否意味著您需要刪除當(dāng)前的技術(shù)堆棧并使用消息傳遞系統(tǒng)？并不是的！您需要權(quán)衡失敗的風(fēng)險與您需要進(jìn)行的投資。您可以通過投資基礎(chǔ)架構(gòu)和軟件來最小化失敗的可能性。在許多情況下，失敗是一種選擇。但在設(shè)計分布式系統(tǒng)時，您確實需要考慮失敗的問題。
2、延遲是零
問題
通過網(wǎng)絡(luò)撥打電話不是即時的。
內(nèi)存呼叫和互聯(lián)網(wǎng)呼叫之間存在七個數(shù)量級的差異。您的應(yīng)用程序應(yīng)該是網(wǎng)絡(luò)感知。這意味著您應(yīng)該清楚地將本地呼叫與遠(yuǎn)程呼叫分開。讓我們看看我在代碼庫中看到的一個例子：
var viewModel = new ViewModel();
var documents = new DocumentsCollection();
foreach (var document in documents)
{
var snapshot = document.GetSnapshot();
viewModel.Add(snapshot);
}
沒有進(jìn)一步檢查，這看起來很好。但是，有兩個遠(yuǎn)程呼叫。第 2 行進(jìn)行一次調(diào)用以獲取文檔摘要列表。在第 5 行，還有另一個調(diào)用，它檢索有關(guān)每個文檔的更多信息。這是一個經(jīng)典的 Select n + 1 問題。為了解決網(wǎng)絡(luò)延遲問題，您應(yīng)該在一次調(diào)用中返回所有必需的數(shù)據(jù)。一般的建議是本地調(diào)用可以細(xì)粒度，但遠(yuǎn)程調(diào)用應(yīng)該更粗粒度。這就是為什么分布式對象和網(wǎng)絡(luò)透明度的想法死了。但是，即使每個人都同意分布式對象是一個壞主意，有些人仍然認(rèn)為延遲加載總是一個好主意：
var employee = EmployeeRepository.GetBy(someCriteria)
var department = employee.Department;
var manager = department.Manager;
foreach (var peer in manager.Employees;)
{
// do something
}
您不希望財產(chǎn)獲取者進(jìn)行網(wǎng)絡(luò)呼叫。但是，每個。在上面的代碼中調(diào)用實際上可以觸發(fā)數(shù)據(jù)庫之旅。
解決方案
帶回您可能需要的所有數(shù)據(jù)
如果您進(jìn)行遠(yuǎn)程呼叫，請確?；謴?fù)可能需要的所有數(shù)據(jù)。網(wǎng)絡(luò)通信不應(yīng)該是嘮叨的。
將 Data Closer 移動到客戶端
另一種可能的解決方案是將數(shù)據(jù)移近客戶端。如果您正在使用云，請根據(jù)客戶的位置仔細(xì)選擇可用區(qū)。緩存還可以幫助最小化網(wǎng)絡(luò)呼叫的數(shù)量。對于靜態(tài)內(nèi)容，內(nèi)容交付網(wǎng)絡(luò)（CDN）是另一個不錯的選擇。
反轉(zhuǎn)數(shù)據(jù)流
刪除遠(yuǎn)程調(diào)用的另一個選項是反轉(zhuǎn)數(shù)據(jù)流。我們可以使用 Pub / Sub 并在本地存儲數(shù)據(jù)，而不是查詢其他服務(wù)。這樣，我們就可以在需要時獲取數(shù)據(jù)。當(dāng)然，這會帶來一些復(fù)雜性，但它可能是工具箱中的一個很好的工具。
結(jié)論
雖然延遲可能不是 LAN 中的問題，但當(dāng)您轉(zhuǎn)移到 WAN 或 Internet 時，您會注意到延遲。這就是為什么將網(wǎng)絡(luò)呼叫與內(nèi)存中的呼叫明確分開是很重要的。在采用微服務(wù)架構(gòu)模式時，您應(yīng)該牢記這一點。您不應(yīng)該只使用遠(yuǎn)程調(diào)用替換本地呼叫。這可能會使你的系統(tǒng)變成分布式的大泥球。
3、帶寬是無限的
問題
帶寬是有限的。
帶寬是網(wǎng)絡(luò)在一段時間內(nèi)發(fā)送數(shù)據(jù)的容量。到目前為止，我還沒有發(fā)現(xiàn)它是一個問題，但我可以看到為什么它在某些條件下可能是一個問題。雖然帶寬隨著時間的推移而有所改善，但我們發(fā)送的數(shù)據(jù)量也有所增加。與通過網(wǎng)絡(luò)傳遞簡單 DTO 的應(yīng)用相比，視頻流或 VoIP 需要更多帶寬。帶寬對于移動應(yīng)用程序來說更為重要，因此開發(fā)人員在設(shè)計后端 API 時需要考慮它。
錯誤地使用 ORM 也會造成傷害。我見過開發(fā)人員在查詢中過早調(diào)用.ToList（）的示例，因此在內(nèi)存中加載整個表。
解決方案
領(lǐng)域驅(qū)動的設(shè)計模式
那么我們怎樣才能確保我們不會帶來太多數(shù)據(jù)呢？域驅(qū)動設(shè)計模式可以幫助：
首先，您不應(yīng)該爭取單一的企業(yè)級域模型。您應(yīng)該將域劃分為有界上下文。
要避免有界上下文中的大型復(fù)雜對象圖，可以使用聚合模式。聚合確保一致性并定義事務(wù)邊界。
命令和查詢責(zé)任隔離
我們有時會加載復(fù)雜的對象圖，因為我們需要在屏幕上顯示它的一部分。如果我們在很多地方這樣做，我們最終會得到一個龐大而復(fù)雜的模型，對于寫作和閱讀來說都是次優(yōu)的。另一種方法可以是使用命令和查詢責(zé)任隔離 - CQRS。這意味著將域模型分為兩部分：
- 在寫模式將確保不變保持真實的數(shù)據(jù)是一致的。由于寫模型不關(guān)心視圖問題，因此可以保持較小且集中。
- 該讀取模型是視圖的擔(dān)憂進(jìn)行了優(yōu)化，所以我們可以獲取所有所需的特定視圖中的數(shù)據(jù)（例如，我們的應(yīng)用程序的屏幕）。
結(jié)論
在第二個謬誤（延遲不是 0）和第三個謬誤（帶寬是無限的）之間有延伸，您應(yīng)該傳輸更多數(shù)據(jù)，以最大限度地減少網(wǎng)絡(luò)往返次數(shù)。您應(yīng)該傳輸較少的數(shù)據(jù)以最小化帶寬使用。您需要平衡這兩種力量，并找到通過線路發(fā)送的 正確 數(shù)據(jù)量。
雖然您可能不會經(jīng)常遇到帶寬限制，但考慮傳輸?shù)臄?shù)據(jù)非常重要。更少的數(shù)據(jù)更容易理解。數(shù)據(jù)越少意味著耦合越少。因此，只傳輸您可能需要的數(shù)據(jù)。
4、網(wǎng)絡(luò)是安全的
問題
網(wǎng)絡(luò)并不安全。
這是一個比其他人更多的媒體報道的假設(shè)。您的系統(tǒng)僅與最薄弱的鏈接一樣安全。壞消息是分布式系統(tǒng)中有很多鏈接。您正在使用 HTTPS，除非與不支持它的第三方遺留系統(tǒng)進(jìn)行通信。您正在查看自己的代碼，尋找安全問題，但正在使用可能存在風(fēng)險的開源庫。一個 OpenSSL 的漏洞允許人們通過盜取 SSL / TLS 保護(hù)的數(shù)據(jù)。Apache Struts 中的一個錯誤允許攻擊者在服務(wù)器上執(zhí)行代碼。即使你正在抵御所有這些，仍然存在人為因素。惡意 DBA 可能錯放數(shù)據(jù)庫備份。今天的攻擊者掌握著大量的計算能力和耐心。所以問題不在于他們是否會攻擊你的系統(tǒng)，而是什么時候。
解決方案
深度防御
您應(yīng)該使用分層方法來保護(hù)您的系統(tǒng)。您需要在網(wǎng)絡(luò)，基礎(chǔ)架構(gòu)和應(yīng)用程序級別進(jìn)行不同的安全檢查。
安全心態(tài)
在設(shè)計系統(tǒng)時要牢記安全性。十大漏洞列表在過去 5 年中沒有發(fā)生太大變化。您應(yīng)遵循安全軟件設(shè)計的最佳實踐，并檢查常見安全漏洞的代碼。您應(yīng)該定期搜索第三方庫以查找新漏洞。常見漏洞和暴露列表可以提供幫助。
威脅建模
威脅建模是一種識別系統(tǒng)中可能存在的安全威脅的系統(tǒng)方法。首先確定系統(tǒng)中的所有資產(chǎn)（數(shù)據(jù)庫中的用戶數(shù)據(jù)，文件等）以及如何訪問它們。之后，您可以識別可能的攻擊并開始執(zhí)行它們。我建議閱讀高級 API 安全性的第 2 章，以便更好地概述威脅建模。
結(jié)論
唯一安全的系統(tǒng)是關(guān)閉電源的系統(tǒng)，不連接到任何網(wǎng)絡(luò)（理想情況下是在一個有形模塊中）。它是多么有用的系統(tǒng)！事實是，安全是艱難而昂貴的。分布式系統(tǒng)中有許多組件和鏈接，每個組件和鏈接都是惡意用戶的可能目標(biāo)。企業(yè)需要平衡攻擊的風(fēng)險和概率與實施預(yù)防機(jī)制的成本。
攻擊者手上有很多耐心和計算能力。我們可以通過使用威脅建模來防止某些類型的攻擊，但我們無法保證 100％的安全性。因此，向業(yè)務(wù)部門明確表示這一點是個好主意，共同決定投資安全性的程度，并制定安全漏洞何時發(fā)生的計劃。
5、拓?fù)洳粫淖?/h3>
問題
網(wǎng)絡(luò)拓?fù)洳粩嘧兓?/p>
網(wǎng)絡(luò)拓?fù)涫冀K在變化。有時它會因意外原因而發(fā)生變化 - 當(dāng)您的應(yīng)用服務(wù)器出現(xiàn)故障并需要更換時。很多時候它是故意的 - 在新服務(wù)器上添加新進(jìn)程。如今，隨著云和容器的增加，這一點更加明顯。彈性擴(kuò)展 - 根據(jù)工作負(fù)載添加或刪除服務(wù)器的能力 - 需要一定程度的網(wǎng)絡(luò)靈活性。
解決方案
摘要網(wǎng)絡(luò)的物理結(jié)構(gòu)
您需要做的第一件事是抽象網(wǎng)絡(luò)的物理結(jié)構(gòu)。有幾種方法可以做到這一點：
- 停止硬編碼 IP - 您應(yīng)該更喜歡使用主機(jī)名。通過使用 URI，我們依靠 DNS 將主機(jī)名解析為 IP。
- 當(dāng) DNS 不夠時（例如，當(dāng)您需要映射 IP 和端口時），則使用發(fā)現(xiàn)服務(wù)。
- Service Bus 框架還可以提供位置透明性。
無價值的，而非重要的
通過將您的服務(wù)器視為沒有價值的，而不是很重要的，您確保沒有服務(wù)器是不可替代的。這一點智慧可以幫助您進(jìn)入正確的思維模式：任何服務(wù)器都可能出現(xiàn)故障（從而改變拓?fù)浣Y(jié)構(gòu)），因此您應(yīng)該盡可能地自動化。
測試
最后一條建議是測試你的假設(shè)。停止服務(wù)或關(guān)閉服務(wù)器，看看您的系統(tǒng)是否仍在運(yùn)行。像 Netflix 的 Chaos Monkey 這樣的工具可以通過隨機(jī)關(guān)閉生產(chǎn)環(huán)境中的 VM 或容器來實現(xiàn)這一目標(biāo)。通過帶來痛苦，您更有動力構(gòu)建一個可以處理拓?fù)涓牡母邚椥缘南到y(tǒng)。
結(jié)論
十年前，大多數(shù)拓?fù)浣Y(jié)構(gòu)并沒有經(jīng)常改變。但是當(dāng)它發(fā)生時，它可能發(fā)生在生產(chǎn)中并引入了一些停機(jī)時間。如今，隨著云和容器的增加，很難忽視這種謬誤。你需要為失敗做好準(zhǔn)備并進(jìn)行測試。不要等到它在生產(chǎn)中發(fā)生！
6、有一位管理員
問題
這個知道一切的并不存在。
嗯，這個看起來很明顯。當(dāng)然，沒有一個人知道一切。這是一個問題嗎？只要應(yīng)用程序運(yùn)行順利，它就不是。但是，當(dāng)出現(xiàn)問題時，您需要修復(fù)它。因為很多人觸摸了應(yīng)用程序，知道如何解決問題的人可能不在那里。
有很多事情可能會出錯。一個例子是配置。今天的應(yīng)用程序在多個商店中存儲配置：配置文件，環(huán)境變量，數(shù)據(jù)庫，命令行參數(shù)。沒有人知道每個可能的配置值的影響是什么。
另一件可能出錯的事情是系統(tǒng)升級。分布式應(yīng)用程序有許多移動部件，您需要確保它們是同步的。例如，您需要確保當(dāng)前版本的代碼適用于當(dāng)前版本的數(shù)據(jù)庫。如今，人們關(guān)注 DevOps 和持續(xù)交付。但支持零停機(jī)部署并非易事。
但是，至少這些東西都在你的控制之下。許多應(yīng)用程序與第三方系統(tǒng)交互。這意味著，如果它們失效，你可以做的事情就不多了。因此，即使您的系統(tǒng)有一名管理員，您仍然無法控制第三方系統(tǒng)。
解決方案
每個人都應(yīng)對釋放過程負(fù)責(zé)
這意味著從一開始就涉及 Ops 人員或系統(tǒng)管理員。理想情況下，他們將成為團(tuán)隊的一員。盡早讓系統(tǒng)管理員了解您的進(jìn)度可以幫助您發(fā)現(xiàn)限制因素。例如，生產(chǎn)環(huán)境可能具有與開發(fā)環(huán)境不同的配置，安全限制，防火墻規(guī)則或可用端口。
記錄和監(jiān)控
系統(tǒng)管理員應(yīng)該擁有用于錯誤報告和管理問題的正確工具。你應(yīng)該從一開始就考慮監(jiān)控。分布式系統(tǒng)應(yīng)具有集中式日志。訪問十個不同服務(wù)器上的日志以調(diào)查問題是不可接受的方法。
解耦
您應(yīng)該在系統(tǒng)升級期間爭取最少的停機(jī)時間。這意味著您應(yīng)該能夠獨(dú)立升級系統(tǒng)的不同部分。通過使組件向后兼容，您可以在不同時間更新服務(wù)器和客戶端。
通過在組件之間放置隊列，您可以暫時將它們分離。這意味著，例如，即使后端關(guān)閉，Web 服務(wù)器仍然可以接受請求。
隔離第三方依賴關(guān)系
您應(yīng)該以不同于您擁有的組件的方式處理控制之外的系統(tǒng)。這意味著使您的系統(tǒng)更能適應(yīng)第三方故障。您可以通過引入抽象層來減少外部依賴的影響。這意味著當(dāng)?shù)谌较到y(tǒng)出現(xiàn)故障時，您將找到更少的地方來查找錯誤。
結(jié)論
要解決這個謬論，您需要使系統(tǒng)易于管理。DevOps，日志記錄和監(jiān)控可以提供幫助。您還需要考慮系統(tǒng)的升級過程。如果升級需要數(shù)小時的停機(jī)時間，則無法部署每個 sprint。沒有一個管理員，所以每個人都應(yīng)該對發(fā)布過程負(fù)責(zé)。
7、運(yùn)輸成本為零
問題
運(yùn)輸成本 不是 零。
這種謬論與第二個謬誤有關(guān)，即 延遲為零。通過網(wǎng)絡(luò)傳輸內(nèi)容在時間和資源上都有代價。如果第二個謬誤討論了時間方面，那么謬誤＃7 就會解決資源消耗問題。
這種謬論有兩個不同的方面：
網(wǎng)絡(luò)基礎(chǔ)設(shè)施的成本
網(wǎng)絡(luò)基礎(chǔ)設(shè)施需要付出代價。服務(wù)器，SAN，網(wǎng)絡(luò)交換機(jī)，負(fù)載平衡器以及負(fù)責(zé)此設(shè)備的人員 - 所有這些都需要花錢。如果您的系統(tǒng)是在內(nèi)部部署的，那么您需要預(yù)先支付這個價格。如果您正在使用云，那么您只需為您使用的內(nèi)容付費(fèi)，但您仍然需要付費(fèi)。
序列化/反序列化的成本
這種謬誤的第二個方面是在傳輸級別和應(yīng)用程序級別之間傳輸數(shù)據(jù)的成本。序列化和反序列化會消耗 CPU 時間，因此需要花錢。如果您的應(yīng)用程序是內(nèi)部部署的，那么如果您不主動監(jiān)視資源消耗，則會隱藏此成本。但是，如果您的應(yīng)用程序部署在云端，那么這筆費(fèi)用就會非常明顯，因為您需要為使用的內(nèi)容付費(fèi)。
解決方案
關(guān)于基礎(chǔ)設(shè)施的成本，你無能為力。您只能確保盡可能高效地使用它。SOAP 或 XML 比 JSON 更昂貴。JSON 比像 Google 的 Protocol Buffers 這樣的二進(jìn)制協(xié)議更昂貴。根據(jù)系統(tǒng)的類型，這可能或多或少重要。例如，對于與視頻流或 VoIP 有關(guān)的應(yīng)用，傳輸成本更為重要。
結(jié)論
您應(yīng)該注意運(yùn)輸成本以及應(yīng)用程序正在執(zhí)行的序列化和反序列化程度。這并不意味著您應(yīng)該優(yōu)化，除非需要它。您應(yīng)該對資源消耗進(jìn)行基準(zhǔn)測試和監(jiān)控，并確定運(yùn)輸成本是否對您有用。
8、網(wǎng)絡(luò)是同質(zhì)的
問題
網(wǎng)絡(luò) 不是 同質(zhì)的。
同質(zhì)網(wǎng)絡(luò)是使用類似配置和相同通信協(xié)議的計算機(jī)網(wǎng)絡(luò)。擁有類似配置的計算機(jī)是一項艱巨的任務(wù)。例如，您幾乎無法控制哪些移動設(shè)備可以連接到您的應(yīng)用。這就是為什么重點關(guān)注標(biāo)準(zhǔn)協(xié)議。
解決方案
您應(yīng)該選擇標(biāo)準(zhǔn)格式以避免供應(yīng)商鎖定。這可能意味著 XML，JSON 或協(xié)議緩沖區(qū)。有很多選擇可供選擇。
結(jié)論
您需要確保系統(tǒng)的組件可以相互通信。使用專有協(xié)議會損害應(yīng)用程序的互操作性。
設(shè)計分布式系統(tǒng)很難
這些謬論發(fā)表于 20 多年前。但他們今天仍然堅持，其中一些比其他人更多。我認(rèn)為今天許多開發(fā)人員都知道它們，但我們編寫的代碼并沒有顯示出來。
我們必須接受這些事實：網(wǎng)絡(luò)不可靠，不安全并且需要花錢。帶寬有限。網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)將發(fā)生變化。其組件的配置方式不同。意識到這些限制將有助于我們設(shè)計更好的分布式系統(tǒng)。
網(wǎng)頁題目：分布式系統(tǒng)中經(jīng)典的八個謬誤
標(biāo)題來源：http://www.dlmjj.cn/article/dhiihhh.html
