Azure Service Fabric中的應用程序設計

Question

我需要幫助如何考慮設計我們的應用程序以適應新的Azure Service Fabric模板。

今天，我們有一個基於Azure雲服務的應用程序。 該應用程序是圍繞DDD構建的，我們為應用程序的不同子系統部分提供了單獨的有界上下文。 今天有界上下文托管在一個工作者角色中，該角色使用單個WebAPI公開這些子系統。

此外，我們有一個托管Web前端的Web角色和一個處理后台隊列的Worker角色。

我們努力轉向微服務架構。 我打算做的第一件事就是將所有有界上下文提取到自己的API主機中。 這將導致5-10個新的WebAPI服務支持我們的子系統。

我的問題是，所有這些子系統/有界上下文/ API主機是否應該是他們自己的Service Fabric應用程序或單個Service Fabric應用程序中的服務？

我已經閱讀了文檔，在這里找到Service Fabric Application Model ，一遍又一遍，我無法弄清楚我的服務適合的位置。

我們希望系統支持不同版本的服務，並且服務也應該可以擴展到不同的服務。 甚至可能需要讓一個微服務以更大的VM大小運行，然后其余的。

請有人指導我，以滿足我的需求。

Answer 1

一般來說，我認為你有正確的想法，每個有限的上下文都是（微）服務。 Service Fabric為您提供了兩個組織級別的應用程序和服務，其中應用程序是服務的邏輯分組。 這對你意味着什么：

從邏輯上講，將應用程序視為一組有凝聚力的功能。 共同形成該一組有凝聚力的功能的服務應該被分組為應用程序。 對於每項服務，您可以問自己：“沒有這些其他服務，自行部署此服務是否有意義？” 如果答案是否定的，那么它們應該歸入同一個應用程序中。

從發展的角度來看，Visual Studio工具在一個應用程序中更多地面向多個服務，但您也可以在一個解決方案中使用多個應用程序。

從操作上講，應用程序代表進程邊界，升級組和版本控制組：

• 您創建的每個應用程序實例都會獲得自己的進程（如果您在應用程序中有多種服務類型，則會獲得一組進程）。 服務類型的服務實例共享主機進程。 不同服務類型的服務實例每種類型都有自己的進程。
• 該應用程序是頂級升級單元，也就是說，您執行的每個升級都是應用程序升級。 您可以升級應用程序中的各個服務（您不必總是升級應用程序中的每個服務），但每次升級時，應用程序版本都會更改。
• 您可以在群集中創建同一應用程序類型的不同版本的並行實例。 您無法在應用程序實例中創建同一服務類型的不同版本的並行實例。

在服務中完成安置和擴展。 例如，您可以在應用程序中擴展一個服務，並且可以在更大的VM上放置另一個服務。