简体   繁体   中英

What is the difference between Service Fabric Applications and Services

What is the reasoning behind Applications concept in Service Fabric? What is the recommended relation between Applications and Services? In which scenarios do Applications prove useful?

Here is a nice summary how logical services differ from physical services: https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/logical-versus-physical-architecture

Now, in relation to Service Fabric, Service Fabric applications represent logical services while Service Fabric services represent physical services. To simplify it, a Service Fabric application is a deployment unit, so you would put there multiple services that rely on the same persistent storage or have other inter-dependencies so that you really need to deploy them together. If you have totally independent services, you would put them into different Service Fabric applications.

An application is a required top level container for services. You deploy applications, not services. So you cannot really speak about differences between the two since you cannot have services without an application.

From https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-application-model :

An application is a collection of constituent services that perform a certain function or functions. A service performs a complete and standalone function (it can start and run independently of other services) and is composed of code, configuration, and data. For each service, code consists of the executable binaries, configuration consists of service settings that can be loaded at run time, and data consists of arbitrary static data to be consumed by the service. Each component in this hierarchical application model can be versioned and upgraded independently.

Take a look at the link provided and you will see the hierarchical relationship.

An application is a collection of constituent services that perform a certain function or functions. A service performs a complete and standalone function and can start and run independently of other services. A service is composed of code, configuration, and data. For each service, code consists of the executable binaries, configuration consists of service settings that can be loaded at run time, and data consists of arbitrary static data to be consumed by the service. Each component in this hierarchical application model can be versioned and upgraded independently.

It is described here in detail

How I currently see it, applications are a nice concept to group multiple services together and manage them as single unit. In context of service fabric, this is useful if you have multiple nano-services which do not warrant them being completely standalone; instead you can package them together into microservices (SF application).

Disclaimers: - nano-service would be a REALLY small piece of code running as a stateless SF service for example (eg read from queue, couple of lines of code to process, write to another queue). - in case of "normal" microservices, one could consider packaging them as 1 SF application = 1 SF service

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM