Azure Service Fabric 中的应用程序设计 [英] Design of Application in Azure Service Fabric

问题描述

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

I need help how to think about designing our application to fit into the new Azure Service Fabric template.

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

Today we have an application built on Azure Cloud Services. The application is built around DDD and we have separate bounded contexts for different subsystem parts of the application. The bounded contexts are today hosted in one worker role that exposes these subsystems using a single WebAPI.

此外，我们有一个 Web 角色托管 Web 前端和一个工作角色处理后台队列.

Additionally we have one Web Role hosting the web frontend and one Worker Role processing a background queue.

我们努力转向微服务架构.我计划做的第一件事是将所有有界上下文提取到它们自己的 API 主机中.这将产生 5-10 个支持我们子系统的新 WebAPI 服务.

We strive to move to a micro services architecture. The first thing I planned to do was to extract all bounded context into their own API-hosts. This will result in 5-10 new WebAPI services supporting our subsystems.

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

To my question, should all of these subsystem/bounded context/API-hosts be their own Service Fabric Application or a service within a single Service Fabric Application?

我已阅读文档，可在此处找到 Service Fabric 应用程序模型，一遍又一遍，我无法弄清楚我的服务适合哪里.

I've read the documentation, found here Service Fabric Application Model, over and over and I can't figure out where my services fits in.

我们希望系统支持不同版本的服务，并且这些服务也应该可以进行不同的扩展.甚至可能需要让一个微服务在比其他微服务更大的 VM 中运行.

We want the system to support different versions of the services, and the services should also be possible to scale different from another. There might even be a requirement to have one micro service to run in a larger VM size then the rest.

请有人指导我适合我的需求.

Please can someone guide me in which suits my needs.

推荐答案

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

I think you have the right idea, in general terms, that each bounded context is a (micro) service. Service Fabric gives you two levels of organization with applications and services, where an application is a logical grouping of services. Here's what that means for you:

从逻辑上讲，将应用程序视为一组内聚的功能.共同形成一组内聚功能的服务应该被分组为一个应用程序.对于每项服务，您可以问自己:在没有这些其他服务的情况下单独部署该服务是否有意义?"如果答案是否定的，那么它们可能应该被归入同一个应用程序中.

Logically speaking, think of an application as a cohesive set of functionality. The services that collectively form that cohesive set of functionality should be grouped as an application. You can ask yourself, for each service: "does it make sense to deploy this service by itself without these other services?" If the answer is no, then they should probably be grouped in the same application.

从开发角度来看，Visual Studio 工具更适合在一个应用程序中提供多个服务，但您也可以在一个解决方案中拥有多个应用程序.

Developmentally speaking, the Visual Studio tooling is geared a bit more toward multiple services in one application, but you can have multiple applications in one solution too.

从操作上来说，一个应用代表一个进程边界、升级组和版本控制组:

Operationally speaking, an application represents a process boundary, upgrade group, and versioning group:

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

放置和缩放在服务中完成.因此，例如，您可以在应用程序中扩展一项服务，也可以将另一项服务放置在更大的虚拟机上.

Placement and scale is done at the service. So for example, you can scale one service in an application, and you can place another service on a larger VM.

这篇关于Azure Service Fabric 中的应用程序设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！