我需要帮助如何考虑设计我们的应用程序以适应新的 Azure Service Fabric 模板。
今天,我们有一个基于 Azure 云服务构建的应用程序。该应用程序是围绕 DDD 构建的,我们为应用程序的不同子系统部分提供了单独的有界上下文。目前,有界上下文托管在一个辅助角色中,该角色使用单个 WebAPI 公开这些子系统。
此外,我们还有一个托管 Web 前端的 Web 角色和一个处理后台队列的工作角色。
我们努力转向微服务架构。我计划做的第一件事是将所有有界上下文提取到它们自己的 API 主机中。这将导致 5-10 个新的 WebAPI 服务支持我们的子系统。
对于我的问题,所有这些子系统/有界上下文/API 主机应该是它们自己的 Service Fabric 应用程序还是单个 Service Fabric 应用程序中的服务?
我已阅读文档,可在此处找到 Service Fabric Application Model ,一遍又一遍,我无法弄清楚我的服务适合哪里。
我们希望系统支持不同版本的服务,并且服务也应该能够进行不同的扩展。甚至可能需要让一个微服务在比其他微服务更大的虚拟机中运行。
请有人指导我适合我的需求。
最佳答案
我认为您的想法是正确的,一般来说,每个有界上下文都是一个(微)服务。 Service Fabric 为您提供了应用程序和服务的两个组织级别,其中应用程序是服务的逻辑分组。这对您意味着什么:
从逻辑上讲,将应用程序视为一组有凝聚力的功能。共同形成该内聚功能集的服务应分组为应用程序。对于每项服务,您可以问自己:“在没有这些其他服务的情况下单独部署此服务是否有意义?”如果答案是否定的,那么它们可能应该被分组在同一个应用程序中。
从开发角度来说,Visual Studio 工具更适合一个应用程序中的多个服务,但您也可以在一个解决方案中拥有多个应用程序。
从操作上来说,应用程序代表进程边界、升级组和版本控制组:
- 您创建的应用程序的每个实例都有自己的进程(如果应用程序中有多种服务类型,则为一组进程)。服务类型的服务实例共享主机进程。不同服务类型的服务实例每种类型都有自己的进程。
- 应用程序是最顶层的升级单元,即你所做的每一次升级都是一次应用程序的升级。您可以升级应用程序中的各个服务(您不必总是升级应用程序中的每项服务),但每次升级时,应用程序版本都会发生变化。
- 您可以在集群中创建同一应用程序类型的不同版本的并行实例。您无法在应用程序实例中同时创建同一服务类型的不同版本的实例。
放置和缩放是在服务中完成的。例如,您可以扩展应用程序中的一项服务,并且可以将另一项服务放置在更大的虚拟机上。
关于azure - Azure Service Fabric 中的应用程序设计,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37567644/