Azure Service Fabric 多服務容器

Question

我計划構建 n 個 docker 容器，每個容器包含 m 個服務。

1. 這是推薦的嗎？ 根據硬件和 docker 容器結構，容器內的推薦或最大服務數是多少？ （考慮到所選服務具有內聚性，從而完成類似的語義任務）
2. 為什么在特定情況下（例如 1 of n 服務崩潰）中，我找不到任何關於容器行為的故障轉移描述的文檔。 Afaik，如果一項服務崩潰，容器會自動重啟。 有沒有辦法防止這種情況？ 我本來希望容器內的應用程序負責服務重啟。

編輯：

另外兩個注意事項：您提到多個服務在擴展方面不合適，您能解釋一下原因嗎？ （他們沒有計划那些用例嗎？）我之前提到的應用程序 model 怎么樣？ 在此鏈接上進行了描述： Service Fabric support for containers

Service Fabric 提供了一個應用程序 model，其中一個容器代表一個應用程序主機，其中放置了多個服務副本。 Service Fabric 還支持來賓可執行方案，您不使用內置的 Service Fabric 編程模型，而是使用 package 一個現有應用程序，使用任何語言或框架編寫，在容器內。 此場景是容器的常見用例。 您還可以在容器內運行 Service Fabric 服務。 目前對在容器內運行 Service Fabric 服務的支持有限。

創建應用程序時，在服務創建階段選擇容器。 並且可以向現有應用程序添加更多服務（同時再次選擇容器類型）。 應用程序本身是否也被視為容器？ 這不合適嗎？ 但是在我添加的引用中，它只討論了一個來賓可執行文件，而不是很多。 此頁面進一步說明： Package 並使用 Yeoman 將容器部署為 Service Fabric 應用程序

這很令人困惑。 似乎已經考慮了容器內的多服務器場景，而您說這是推薦的。 它處於測試階段嗎？

你能描述一下你去 go 的方式嗎？ 在一個容器中提供一項服務？ 我是否需要先創建一個具有容器服務的應用程序，然后將該應用程序添加到可以添加到集群節點的 docker 基礎映像中？

Answer 1

根據容器的思想——每個容器都應該有一個服務。 將多個服務放入容器中被認為是一種不好的做法。 這將回答您的兩個問題。