微服務和雲資源限制

Question

我在使用Spring Cloud/Spring Cloud Netflix從單一的單一web服務到微服務集合的大遷移開始。通過我對微服務的研究，我明白服務之間的界限應該反映他們之間的關注點分離。影響分離的另一個因素是需要哪些服務單獨擴展。

作爲具體的例子，這取決於粒度的需要的水平時，一個微服務環境最終可能是這樣的：

• （含有註冊，登錄，配置文件等）
• 存儲（含帳戶產品，付款，報告，存貨等）
• 聊天/社會（含聊天室，用戶狀態等）
• ...

或者它可以通過自己的微服務括號來表示每個關注的領域的結尾，例如：

• 賬戶
• 註冊
• 登錄
• ...

我相信微服務社區對於第二種方法有偏好，我傾向於同意。但是，我遇到的問題是託管和資源限制之一。

在遷移中，我想簡化資源的供應和安裝更新的服務。由於我們使用AWS堆棧，Elastic Beanstalk似乎是最佳選擇。雖然研究Elastic Beanstalk雖然我很沮喪，發現每個帳戶有25個應用程序的限制。不僅如此，EC2每個賬戶每個地區限制20個實例。看起來微服務架構很快就會達到這個限制，尤其是當您爲每個服務添加多個環境（分段和生產）時，更不用說網站和內部工具了。

隨着我在網絡上看到有關微服務的所有令人驚歎的內容，我感到很驚訝，並且對於缺少關於超出其開發範圍的實際託管微服務的信息感到有點失望。我錯過了什麼嗎？有關於在AWS上部署多個微服務的任何信息嗎？

我的理解是，Netflix使用AWS進行自己的微服務託管，除了要求亞馬遜的額外資源並向其投資外，還有其他解決方案嗎？他們的Asgard工具可以幫助解決這個問題（可能通過處理服務之間的實例共享）還是會導致相同的結果？

Answer 1

正如上面的評論中提到的，如果您有合法的使用案例，AWS會提高您的限制 - 爲什麼他們不？他們正在出售你的服務。

但既然你問了比增加這些限制其他的建議，因爲你是在設計解決方案的早期階段，你應該考慮在泊塢窗或類似服務的另一個容器/容器基礎的微服務架構的一部分（我自己喜歡的是AWS的容器服務）。根據您的解決方案的性質，即使在20個EC2實例（每個區域）的限制範圍內，如果您有足夠大的實例運行，您可以安裝數十個（甚至數百個輕量級）碼頭映像，並在每個分配的20個實例上運行 - 因此可能會在這20個EC2實例上運行數千個被關閉的微服務。

對於您可能擁有的許多微服務中的每一種，使用整個EC2映像可能最終會比需要昂貴得多。

您還應該考慮在您的微服務體系結構的至少部分中使用AWS Lamba - 它也是由AWS提供的「超微服務」工具。