使用微服務前必須要了解的“分散式系統的謬誤”

　　分散式系統的謬誤（Fallacies of distributed systems）是由L Peter Deutsch和Sun公司的其他人一起提出的一系列論斷，這些論斷描述了剛接觸分散式應用程式的程式設計師總是會做出的錯誤假設。

　　微服務的大規模採用迫使更多的工程師理解這一架構決定對他們系統設計的影響。在討論基於微服務的分散式系統設計時，經常能看到這8個被忽略的謬誤：

　　1、網路是可靠的；

　　2、網路延遲是0；

　　3、頻寬是無限的；

　　4、網路是安全的；

　　5、網路拓撲是不變的；

　　6、總是有一個管理員；

　　7、網路傳輸成本是0；

　　8、網路是同質化的。

　　8個分散式系統的謬誤

　　1、網路是可靠的

　　在軟體應用程式開發時很少對網路錯誤進行處理。在網路中斷期間，此類應用程式可能會暫停或無限地等待應答包，永久地消耗記憶體或其他資源。當故障網路可用時，這些應用程式也可能無法重試任何停止的操作或需要(手動)重新啟動。

　　為了建立一個可靠的系統，你必須理解並接受這樣一個事實：任何特定的通訊都有可能失敗；因此，我們需要為系統提供一種方法來處理這種潛在的通訊錯誤。所以最終，這歸結為重新傳送，它可以以多種形式出現。

　　其中一種模式是儲存並轉發模式。我們將資料儲存在本地或其他地方，而不是直接將資料傳送到下游伺服器。這樣還可以在發生災難性的情況下進行資料恢復，而簡單的重試迴圈將缺乏此類保證。

　　有許多技術符合這個的模式，如Kafka、RabbitMQ、ActiveMQ等訊息中介軟體都可以解決此問題。

　　謬誤1：網路是可靠的

　　2、網路延遲是0

　　忽視網路延遲以及它可能導致的資料包丟失，導致應用程式層和傳輸層開發人員允許無限制的流量，大大增加了丟失的資料包並浪費頻寬。

　　我們應該將延遲視為完成任何請求的嚴格必須開銷。訊息可以很大，也可以很小，延遲是不變的。與頻寬不同，延遲通常與光速和通訊距離(或路徑)有關。所以兩個系統之間的距離在這裡起著重要的作用。

　　延遲無處不在。它發生在所有的通訊中。

　　理想情況下，這種開銷應該儘可能小。延遲與從汽車上卸下雜貨非常相似。你從廚房到汽車所花費的時間就是延遲。你是想在一次往返中拿走儘可能多的東西，還是想單獨帶著這些東西，往返幾百次才能把車卸完?

　　謬誤2：網路延遲是0

　　3、頻寬是無限的

　　假設你可以無限制地增加通道上的資料大小，這可能是個很大的錯誤。這個問題只有規模達到一定程度，且通訊通道達到了上限才會出現。

　　現在你可能會想，上面剛剛說的在每次往返中儘可能多地攜帶資料，以減少延遲的影響。這是事實，但它也有侷限性。這在很大程度上取決於你的系統設計和各自的優先順序，但意識到如何權衡兩者是至關重要的。

　　謬誤3：頻寬是無限的

　　4、網路是安全的

　　假設你可以信任你所在的網路或你正在為其構建系統的人，這可能是一個嚴重的錯誤。

　　如今，隨著眾包漏洞賞金計劃的出現以及每天新聞中的重大漏洞，這一點變得更加明顯。

　　在設計系統時採取安全第一的立場將會在未來獲得好處。甚至花時間評估當前系統的安全漏洞也是一個很好的開始，這將很快產生一個簡短的改進清單。

　　謬誤4：網路是安全的

　　5、網路拓撲是不變的

　　網路結構並不總是一樣的。網路拓撲的變化會對頻寬和延遲問題產生影響。例如，如果基礎設施的關鍵部分出現故障，流量能否繼續流向適當的目的地？我們會有單點失敗的故障嗎？

　　隨著Docker和Kubernetes的出現，改變網路拓撲結構的便利性，幾乎讓我們認為這是理所應當的，這種想法是危險的。

　　像Zookeeper和Consul這樣的工具確實有助於解決服務發現方面的問題，並允許應用程式對佈局和組成系統發生變化時做出反應。

　　構建能夠對這些拓撲變化做出反應的系統可能很棘手，但最終會產生更具彈性的系統。

　　謬誤5：網路拓撲是不變的

　　6、總是有一個管理員

　　這個謬誤本質上說是你不能控制一切。

　　隨著系統的發展，它們將依賴於你無法控制的其他系統。花點時間想想所有的依賴關係；你擁有從程式碼到執行它們的伺服器的一切。

　　有一種清晰的方式來管理你的系統及其各自的配置是非常重要的。隨著具有各種配置的系統數量的增加，管理和跟蹤變得越來越困難。基礎設施即程式碼(IaC)可以幫助對系統中的這些配置變化進行編碼。

　　當問題出現時，有一個診斷問題的好方法，監控和可觀察性將是可以節省時間的關鍵工具。

　　另外，適當的解耦還可以幫助確保整體系統的彈性和正常執行時間。

　　謬誤6：總是有一個管理員

　　7、網路傳輸成本是0

　　我們經常認為用於在系統之間傳送資料的資源是一種簡單的業務成本。當資料很小的時候，這些開銷和成本是可以忽略不計。

　　儘管如此，隨著系統的增長，與 gRPC 或 MessagePack 等傳輸最佳化格式相比，最佳化 JSON 等訊息格式的成本可能有點重（雙關語意）。

　　儘管如此，隨著系統的增長，與gRPC或MessagePack等傳輸最佳化格式相比，最佳化JSON這類有點重的訊息格式的成本是值得的。

　　瞭解這些成本是必要的；但是，它也有它的權衡。在短期內，過早最佳化可能會帶來更多的麻煩。

　　謬誤7：網路傳輸成本是0

　　8、網路是同質化的

　　我們肯定曾經寫過不少轉換程式，將一種格式的資料轉換成另一種格式。

　　我們喜歡一切都乾淨整潔，但現實世界遠非如此。互操作是必不可少的。

　　這種靈活性確保我們的系統在 "新的熱門框架 "出現時，或者當你需要在原本未考慮過的環境中執行你的新系統時，能夠繼續發揮作用。

　　知道所有的系統都不一樣，並且不將您的解決方案耦合到特定方面技術，可以節省您的時間和麻煩。

　　謬誤8：網路是同質化的

　　結語

　　在我們廣泛的應用微服務架構時，我們要意識到微服務架構本質上是一種分散式系統的架構。

　　作為分散式系統架構，我們就要面臨很多分散式系統面臨的挑戰。瞭解“分散式系統的謬誤”可以很好的規避我們在使用微服務架構所必要考慮的問題，而不是當這些問題不存在！