azure - Azure Service Fabric中的应用程序设计

我需要帮助如何考虑设计我们的应用程序以适应新的Azure Service Fabric模板。

今天我们有一个基于Azure云服务的应用程序。该应用程序是围绕DDD构建的，我们为应用程序的不同子系统部分提供了单独的有界上下文。今天有界上下文托管在一个工作者角色中，该角色使用单个WebAPI公开这些子系统。

此外，我们有一个托管Web前端的Web角色和一个处理后台队列的Worker角色。

我们努力转向微服务架构。我打算做的第一件事就是将所有有界上下文提取到自己的API主机中。这将导致5-10个新的WebAPI服务支持我们的子系统。

我的问题是，所有这些子系统/有界上下文/ API主机都应该是他们自己的Service Fabric应用程序还是单个Service Fabric应用程序中的服务？

我已经一遍又一遍地阅读了Service Fabric Application Model这里找到的文档，我无法弄清楚我的服务适合的位置。

我们希望系统支持不同版本的服务，并且服务也应该可以扩展到不同的服务。甚至可能需要让一个微服务以比其余的更大的VM大小运行。

请有人指导我，以满足我的需要。

一般来说，我认为你有正确的想法，每个有限的上下文都是（微）服务。 Service Fabric为您提供了两个组织级别的应用程序和服务，其中应用程序是服务的逻辑分组。这对你意味着什么：

从逻辑上讲，将应用程序视为一组具有凝聚力的功能。共同形成该一组有凝聚力的功能的服务应该被分组为应用程序。对于每项服务，您可以问自己：＆＃34;在没有这些其他服务的情况下自行部署此服务是否有意义？＆＃34;如果答案是否定的，那么它们可能应该归入同一个应用程序中。

从发展的角度来看，Visual Studio工具在一个应用程序中更多地面向多个服务，但您也可以在一个解决方案中使用多个应用程序。

从操作上讲，应用程序代表进程边界，升级组和版本控制组：

您创建的每个应用程序实例都会获得自己的进程（如果您在应用程序中有多种服务类型，则会获得一组进程）。服务类型的服务实例共享主机进程。不同服务类型的服务实例每种类型都有自己的进程。
应用程序是顶级升级单元，也就是说，您执行的每个升级都是应用程序升级。您可以升级应用程序中的各个服务（您不必总是升级应用程序中的每个服务），但每次升级时，应用程序版本都会更改。
您可以在群集中创建同一应用程序类型的不同版本的并行实例。您无法在应用程序实例中创建同一服务类型的不同版本的并行实例。

在服务中完成放置和缩放。例如，您可以在应用程序中扩展一个服务，并且可以在更大的VM上放置另一个服务。