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前端，还有一个Worker角色处理后台队列.

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?

我已阅读文档，位于此处服务结构应用程序模型，一遍又一遍，我不知道我的服务适合哪里.

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:

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

放置和缩放在服务中完成.因此，例如，您可以扩展应用程序中的一项服务，然后可以将另一项服务放置在较大的VM上.

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屋！