Service Fabric (continued)   

Part 2 compared Paxos and Raft. Part 3 discussed SF-Ring.

This article continues the discussion on Service Fabric with a focus on its architecture. ServiceFabric is built with layered subsystems which enables us to write applications that are highly available, scalable, manageable and testable.

The major subsystems in a ServiceFabric include the following:

-          the transportation subsystem that secures point to point communication as the base layer

-          the federation subsystem that federates a set of nodes to form a consistent scalable fabric

-          the communication system that does service discovery

-          the reliability system that offers reliability, availability, replication, and service orchestration.

-          The hosting and activation subsystem that offers application lifecycle

-          The management subsystem that performs deployment, upgrade and monitoring

-          The testability subsystem that performs fault injection, test in production

-          The application model that is declarative application description

-          The native and managed APIs that support reliable, scalable applications

Service Fabric provides the ability to resolve service locations through its communication subsystem. The application programming models exposed to the developers are layered on top of these subsystems along with the application model to enable tooling.

 

The transport subsystem implements a point-to-point datagram communication channel which is used for communication within service fabric clusters and communication between the service fabric cluster and clients. It enables broadcast and multicast in the Federation layer and provides encrypted communication. It is not exposed to users.

 

The federation subsystem stitches the various nodes into a single unified cluster. It provides the distributed systems primitives needed by the other subsystems - failure detection, leader election, and consistent routing. It is built on top of distributed hash tables with a 128-bit token space which is a ring topology over the nodes.

The reliability subsystem consists of a Replicator, Failover Manager, and Resource Balancer.  The Replicator ensures that state changes in the primary service replica are replicated and in sync. The Failover Manager ensures that the load is automatically redistributed across the nodes on additions and removals.  The Resource Manager places service replicas across failure domains in the cluster and ensures that all failover units are operational.

The Management subsystem consists of a cluster manager, Health manager, and the Image store. The Cluster manager places the applications on the nodes based on service placement constraints. The Health manager enables health monitoring of applications, services and cluster entities. The Image store service provides storage and distribution of the application binaries.

The Hosting subsystem services manages the lifecycle of an application on a node that the hosting subsystem provides.

The communication subsystem provides reliable messaging within the cluster and service discovery through the Naming service.

The Testability subsystem  is a suite of tools specifically designed for testing services built on Service Fabric.