Service Fabric is a collection of services grouped into different subsystems. These subsystems have specific responsibilities. The following diagram illustrates the major subsystems which form the Service Fabric architecture:
Subsystems of Service Fabric
The first layer from the bottom, the Transport Subsystem is responsible for providing secure communication channels between nodes in a Service Fabric cluster. The Federation Subsystem above it helps logically group physical or virtual nodes into a cluster so that it can be managed as a unit. This helps Service Fabric with tasks such as failure detection, leader election, and routing. Reliability of the workload hosted on Service Fabric is managed by the Reliability Subsystem. It owns the responsibility of replication, resource management, and failover. The Hosting & Activation Subsystem manages the lifecycle of the workload on every node and the Management Subsystem is responsible for managing the lifecycle of applications. The Testability Subsystem helps developers test their workload before and after deployment. Service location of services hosted on Service Fabric is managed by Communication Subsystem. The top three boxes capture the application programming models and the application model available for the developers to consume. More about application models is discussed in later parts of this book.
The Transport Subsystem provides a communication channel for intra and inter cluster communication. The channels used for communication are secured by X509 certificate or Windows security. The subsystem supports both one-way and request-response communication patterns. These channels are in turn used by the Federation Subsystem for broadcast and multicast messaging. This subsystem is internal to Service Fabric and cannot be directly used by the developers for application programming.
Federation Subsystem is responsible for logically grouping virtual or physical machines together to form a Service Fabric cluster. This subsystem uses the communication infrastructure provided by the Transport Subsystem to achieve this grouping. Grouping of nodes helps Service Fabric better manage the resources. The key responsibilities of this subsystem includes failure detection, leader election, and routing. The subsystem forms a ring topology over the nodes allocated for the cluster. A token-leasing mechanism along with a heartbeat check is implemented within the system to detect failures, perform leader election, and to achieve consistent routing.
Reliability of the service hosted on the platform is ensured by the Reliability Subsystem. It achieves these tasks by managing failover, replicating, and balancing resources across nodes in a cluster.
The replicator logic within this subsystem is responsible for replicating the state across multiple instances of a service. Maintaining consistency between the primary and the secondary replicas in a service deployment is its main task. It interacts with the failover unit and the reconfiguration agent to understand what needs to be replicated.
Any changes in the number of nodes in the cluster trigger the failover manager service. This in turn triggers automatic redistribution of services across the active nodes.
The resource manager plays the part of placing service replicas across different failure domains. It is also responsible for balancing the resources across the available nodes in the cluster while optimizing the load distribution and resource consumption.
The application lifecycle management of workloads deployed on a Service Fabric cluster is owned by the Management Subsystem. Application developers can access the Management Subsystem functionalities through administrative APIs or PowerShell cmdlets to provision, deploy, upgrade, or de-provision applications. All these operations can be performed without any downtime. The Management Subsystem has three key components – cluster manager, health manager, and image store.
The cluster manager interacts with the failover manager and the resource manager in the Reliability Subsystem for deploying the applications of available nodes considering the placement constraints. It is responsible for the lifecycle of the application, starting from provisioning to de-provisioning. It also integrates with the health manager to perform health checks during service upgrades.
Health manager, as the name suggests, is responsible for monitoring the health of applications, services, nodes, partitions, and replicas. It is also responsible for aggregating the health status and storing it in a centralized health store. APIs are exposed out of this system to query health events to perform corrective actions. The APIs can either return raw events or aggregated health data for a specific cluster resource.
The image store is responsible for persisting and distributing application binaries deployed on a Service Fabric cluster.
The Hosting Subsystem takes care of managing application deployments within the scope of a node. The cluster manager signals the Hosting Subsystem, informing it about the application deployments to be managed on a particular node. The Hosting Subsystem then manages the lifecycle of the application on that node. It interacts with the Reliability Subsystem and Management Subsystem to ensure the health of each deployment.
The communication subsystem provides features for service discovery and intra-cluster messaging features using a naming service. The naming service is used to locate a service within a cluster. It also lets users securely communicate with any node on a cluster, retrieve service metadata, and manage service properties. The naming service also exposes APIs, which enables users to resolve network location or each service despite of them being dynamically placed.
The Testability Subsystem provides a list of tools for developers, deployment engineers, and testers to introduce controlled faults and run test scenarios to validate state transitions and behaviors of services deployed on Service Fabric. The fault analysis service is automatically started when a cluster is provisioned. When a fault action or test scenario is initiated, a command is sent to the fault analysis service to run the fault action or test scenario.
