分散式系統設計:服務(多節點)模式

前面我們描述了在同一機器上調度的容器集合的單點模式。這些容器緊密耦合，以共生系統的形式存在。它們依賴於本地共享資源，如磁碟，網路介面或進程間通信。這種容器集合是重要的模式，也是大型系統的基石。可靠性，可擴展性和解耦決定了現實世界的系統是由許多不同的這樣的組件構成的，它們分布在多台機器上。與單節點模式相比，多節點分散式模式更加鬆散耦合。雖然模式規定了組件之間的通信模式，但這種通信是基於網路調用。此外，許多調用是並行發出的，並且系統是通過鬆散同步而不是緊縮的約束協調。

微服務介紹

最近，術語微服務已成為描述多節點分散式軟體體系結構的流行詞。微服務描述了一個系統，它由運行在不同進程中的許多不同的組件構成，並通過定義的API進行通信。微服務與單體系統形成對比，單體系統傾向於將服務的所有功能集中在一個緊密協調的應用程序中。圖1和2顯示了這兩種不同的架構。

微服務有許多好處，其中主要集中在可靠性和敏捷性方面。微服務將應用程序分解為小塊，每個小塊都專註於提供單一服務。這種縮小的範圍使得每個服務都可以由一個「雙比薩」團隊來構建和維護。減少團隊規模還可以減少與保持團隊聚焦和向一個方向推動相關的開銷。

此外，在不同的微服務之間引入正式的API將團隊彼此分離，並提供不同服務之間的可靠協議。這個正式的協議減少了團隊間緊密同步的需求，因為提供API的團隊了解它需要保持穩定的界限，而使用API的團隊可以依賴穩定的服務而不必擔心其細節。這種解耦使團隊可以獨立管理他們的代碼和發布時間表，從而提高每個團隊迭代和改進代碼的能力。

最後，微服務的解耦可以實現更好的擴展。由於每個組件都已分解為自己的服務，因此可以獨立進行擴展。大型應用程序中的每項服務都以相同的速度增長，或者具有相同的縮放方式，這種情況很少發生。有些系統是無狀態的，可以簡單地進行水平縮放，而其他系統則保持狀態並需要分片或其他縮放方法。通過分離每個服務，每個服務可以使用該方法進行最適合的縮放。當所有的服務都是單一「巨石」的一部分時，這是不可能的。

但是，當然微系統設計的方法也存在不足之處。最主要的兩個缺點是，由於系統變得更加鬆散耦合，發生故障時調試系統顯得更加困難。你不能再將單個應用程序載入到調試器中，並確定出錯的原因。任何錯誤都是經常在不同機器上運行的大量系統的衍生品。在調試器中復現這種環境非常具有挑戰性。作為推論，基於微服務的系統也很難設計和架構。基於微服務的系統使用多種服務之間的通信方法;不同的模式（例如同步，非同步，消息傳遞等）;以及服務之間多種不同的協調和控制模式。

這些挑戰是分散式模式的推動力。 如果一個微服務架構由眾所周知的模式組成，那麼設計起來就比較容易，因為許多設計實踐都是由模式指定的。 此外，模式使得系統更易於調試，因為它們使開發人員能夠將經驗教訓應用於使用相同模式的多個不同系統。

考慮到這一點，本節將介紹一些用於構建分散式系統的多節點模式。 這些模式不是相互排斥的。 任何真實世界的系統都將通過這些模式的集合來構建，以生成單個更高級別的應用程序。