動態可擴展和自適應架構

Question

我是一名雲計算博士生，我計劃將我的研究項目中使用基於微服務的架構與consul和zeromq結合使用。我有幾個難以理解的問題。有人能幫助我分享他們的經驗。

1. 我們有基於碼頭的微服務，我們有zeromq，我們有領事。你能否提一下我們如何將所有三者結合在一起形成一個動態的適應性環境？

雖然我明白，什麼zeromq，碼頭工人和領事是個別，我仍然無法得到所有他們是如何的清晰畫面功能爲whole.We都具有在它們內部運行的微服務Docker容器主辦。我們在碼頭集裝箱之間使用zeromq傳輸（Pub-sub/pipeline）消息。這些容器可能運行在相同的主機/數據中心或不同的主機/數據中心上。然後我們使用領事進行服務發現。我的理解在這裏正確嗎？

1. 架構如何根據工作負載動態擴展/縮小？

說，我有一種情況，在某個時間我需要更多的工作節點進行特定的計算。誰旋轉了更多數量的工作節點。哪個組件決定/做出這個決定？

是否有調度組件？如果是這樣，有人可以簡單地解釋它是如何發生的或哪個組件執行該功能？

1. 那麼，領事的主要角色是什麼？它僅用於服務發現嗎？它是否也可以用於配置。如果是這樣，它的侷限性是什麼？

我看到即使是zeromq也有服務發現機制，那麼爲什麼我們需要領事？

1. 節點信息的故障如何在架構中傳播？哪個組件負責？這只是領事嗎？還是zeroMq呢？

請指教。

Answer 1

我參與了一個使用基於Docker的微服務和Consul的大型項目。 （我們使用的是不同的排隊服務--RabbitMQ，所以我不能詳細說明這方面的情況，但通常情況下，隊列是隊列。）

Docker，Consul和任何隊列技術都不​​是我我知道提供自動縮放功能。 Docker提供了一種簡單的方法來啓動服務的多個實例，Consul提供服務發現（如您所說）和一個鍵/值持久性存儲。隊列只是在服務實例之間傳遞消息的一種方式。你沒有提到處理自動縮放的問題。

要添加自動縮放功能，您需要查看類似Kubernetes的內容。

你可以看看CloudFoundry或Mesos。但是，這兩者都需要虛擬化層，例如OpenStack或VMWare vSphere。這些產品具有重要價值，但價格和複雜性也很高。

我建議您不要走這條路線，而應該考慮亞馬遜網絡服務。使用AWS，您可以輕鬆運行Docker容器，並根據CPU負載，隊列中的消息，一天中的時間（或一週中的某天）等設置自動調節。我知道使用AWS帶有價格標籤，但是如果設計良好並進行了管理，它會花費你遠遠低於試圖設計，實施和維護自己。您還可以使用最小的（即免費的）機器和/或現場實例來降低成本。

Answer 2

這是一個有趣的問題。您提到的所有組件都是獨立的，並且在微服務架構中具有明確的獨立優勢和角色。不尋常的部分是使用消息而不是HTTP。我認爲這是一個有價值的背景，因爲它可以實現更靈活的計算模式（工作生產者不需要成爲產品消費者，甚至不需要通知）。跳過HTTP的特別之處在於避免了成本（OPEX和服務延遲），複雜性以及負載均衡器的增加的故障模式。

1. 泊塢窗：管理的各個服務和交付包裝到基礎設施 ZeroMQ：管理服務 領事之間的高效對等網絡或撮合通訊：服務發現（例如找出用戶服務是）

2. 自動擴展不由Docker執行。您可以使用您自己的微服務來檢查負載指標（例如負載平均值，物理/交換內存使用情況等），並調整副本並更新Consul。

   或者，您可以依靠@drhender：Kubernetes，Mesosphere DCOS或AWS Autoscaling Groups詳述的自動調節解​​決方案。但請注意，使用AWS Autoscaling組會顯着限制解決方案的可移植性。

   無論您選擇哪種自動縮放機制，都要確保您的ZeroMQ消息模式支持添加或刪除服務。 ZeroMQ Guide對此主題有很好的建議。

3. 領事可以提供服務發現和服務配置需求。如果您正在存儲敏感數據（如PHI或PII），請記住存儲安全問題。這些更好地存儲與靜態保護，如保險櫃供應。

   The Consul agent collects telemetry您可以監視問題。還有一個相當簡單的Consul KV benchmarking suite，您可以使用它來測試配置存儲。

   ZeroMQ並非專爲服務發現而設計的。您可以選擇一種集中代理的架構，這種架構可以使單獨的服務發現變得不必要，但這具有不同的可伸縮性和容錯性。假設您在綁定SUB套接字時使用多部分消息和主題訂閱，它具有每個消息的有效載荷開銷。有很多方法可以單獨使用ZeroMQ進行服務發現，但在考慮容忍性和共識性時尤其如此，這一點並不重要。

4. 節點故障是一個有趣的挑戰。領事可以通過健康檢查知道，但ZeroMQ根據消息傳遞模式創造了一些挑戰。例如，如果發送請求並且響應者在傳送後死亡，則使用REQ-REP對，根據我的經驗，REQ套接字將永遠阻塞。有超時解決方法。

   我會依賴Consul爲此做好準備，在發生故障時準備中斷或重新生成REQ套接字。幾乎完全通過使用分步事件驅動體系結構（SEDA）完全避免RPC風格的交互，其中輸入的生產者不是輸出的消費者。在失敗時，您總是會面臨丟失排隊輸入或輸出的挑戰，因此如果失去工作是致命的，您需要系統級別的監控和重試機制。

ContainerBuddy允許您將任何可啓動的應用程序放入Docker容器中，並將其註冊到Consul。它可以爲你簡化事情。