Application model

A Service Fabric application is made up of one or more Microservices. Each Microservice consists of the executable binaries or code of the Microservice, the configuration or setting that is used by the Microservice at runtime and static data used by the Microservice. All the individual components of the Microservices can be versioned and upgraded independently:

Applications and Microservices in Service Fabric are denoted by their type names. An application type can have a number of service types. You can create instances of application types (for example, by using the PowerShell command New-ServiceFabricApplication) and also service type (for example by using PowerShell command New-ServiceFabricService) which can have different settings and configurations, but the same core functionality.

The application types and service types are described through the application manifests (ApplicationManifest.xml) and service manifests (ServiceManifest.xml) respectively, which are XML files. These manifests serve as the templates against which applications can be instantiated from the cluster's image store.

Once you have installed the Service Fabric SDK, you can find the schema definition for the ServiceManifest.xml and ApplicationManifest.xml files saved in your developer machine at: C:\Program Files\Microsoft SDKs\Service Fabric\schemas\ServiceFabricServiceModel.xsd.

A Service Fabric node can host multiple application instances, some of which might belong to the same application; however, the code for different application instances will run as separate processes. Each application instance can be upgraded and managed independently. The following diagram shows how application types are composed of service types, which in turn are composed of code, configuration, and packages. Each of the service types would include some or all of the code, configuration and data packages:

A stateful Microservice can split its state and save its state across several partitions. A partitioned service can be deployed across nodes in a cluster. A partition is made highly available through replication. A partition has a primary replica and may have multiple secondary replicas. The state data of a stateful Microservice is synchronized automatically across replicas. Whenever a primary replica goes down, a secondary replica is promoted to primary to ensure availability. Later, the number of secondary replicas is brought back up to ensure there is enough redundancy available. There can be one or more instances of a service type active in the cluster.

The following diagram represents the relationship between applications and service instances, partitions, and replicas: