浅谈蓝色服务织物的应用设计

Question

我需要帮助，如何考虑如何设计我们的应用程序，以适应新的Azure服务织物模板。

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

此外，我们有一个承载Web前端的web角色和一个处理后台队列的工作人员角色。

我们努力转向微服务体系结构。我计划做的第一件事是将所有有限制的上下文提取到他们自己的API主机中。这将导致5-10个新的WebAPI服务支持我们的子系统。

对于我的问题，所有这些子系统/有限制的上下文/API-主机应该是它们自己的Service应用程序还是单个service应用程序中的一个服务？

我一遍又一遍地阅读了在这里找到的文档，Service Fabric Application Model，我不知道我的服务在哪里合适。

我们希望系统能够支持不同版本的服务，服务也应该可以扩展到不同的版本。甚至可能需要在更大的VM大小中运行一个微服务，而不是其他的。

请有人指导我，使之适合我的需要。

Answer 1

总的来说，我认为您有一个正确的想法，即每个有界上下文都是一个(微观)服务。services为您提供了两个层次的应用程序和服务组织，其中应用程序是服务的逻辑分组。这对你来说意味着什么：

从逻辑上讲，将应用程序看作是一组具有凝聚力的功能。应该将集体形成该功能集的服务分组为应用程序。对于每个服务，您可以问自己：“在没有其他服务的情况下单独部署该服务有意义吗？”如果答案是否定的，那么它们可能应该分组在同一个应用程序中。

在开发方面，Visual工具更适合于一个应用程序中的多个服务，但您也可以在一个解决方案中使用多个应用程序。

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

• 您创建的应用程序的每个实例都得到自己的进程(如果应用程序中有多个服务类型，则获取一组进程)。服务类型的服务实例共享主机进程。不同服务类型的服务实例每种类型都有自己的流程。
• 应用程序是顶级的升级单元，也就是说，您所做的每一次升级都是一个应用程序升级。您可以在应用程序中升级单个服务(不必总是升级应用程序中的每个服务)，但是每次升级时，应用程序版本都会发生变化。
• 您可以在集群中创建同一应用程序类型的不同版本的并行实例。不能在应用程序实例中创建同一服务类型的不同版本的并行实例。

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