Join Chander Dhall for an in-depth discussion in this video Architecture, part of Microservices and Azure Service Fabric Basics for Developers.
- [Instructor] So let's look into the architecture of Azure Service Fabric. In this diagram you can see we have Azure, our private cloud or any other clouds that we want to interface with. And then we have Service Fabric right underneath our microservices layer. So imagine you have an application that has hundreds and thousands of services and it needs high availability, hyper scale, data partitioning, automatic rollback, and a lot of other features that Service Fabric brings to the table.
So this is really the cushion that gives you all those features including your life cycle management, health monitoring, automatic fail over, self-healing, resource balancing, and a lot of other things that we're going to talk about. So at the higher level, this is the architecture that Service Fabric follows. So in order to build reliable, scalable applications using Azure Service Fabric, we need the application model and the APIs that are really sitting on top of a system that has a lot of subsystems.
In this case, we have the management subsystem and then we have the communication subsystem, the federation system, transport system, and a lot of others. So let's talk about these subsystems one at a time. Transport subsystem. This provides secure communication between nodes. The federation subsystem is responsible for detecting failures, performing leader election, and providing consistent routing. The next one is the reliability subsystem.
As the name suggests, it's responsible for application resource management and fail over. Then we have the management subsystem which is responsible for managing the life cycle of applications and services. And then of course, the testability subsystem. This is where the developers get to test their services by simulating false. This is more like an essential step before and after deploying applications and services to production environments.
And then you also have the hosting and activation system which is really your application life cycle system. And the communication system, that really starts communications between nodes inside a cluster. On top of all this is the application model and the native and management APIs that you need as developers to talk to this subsystem. So transport system, transport system is used for two kinds of communications. One is within Service Fabric clusters and the second one is between Service Fabric clusters and clients.
The transport subsystem supports two kinds of communication patterns, one way and request reply. These communication patterns provide the basis for implementing broadcast and multicast in the federation layer. In a distributed system, secure communication between nodes in a cluster is very important. The transport subsystem uses X.509 certificates or Windows Security to secure communication.
Just to make it clear, this is something that is used by Service Fabric internally and is not accessible to us. The federation subsystem unifies nodes into a manageable cluster. It takes care of detecting failure, electing the leader in case of failure of the primary node and consistent routing. Behind the scenes, the federation subsystem creates distributed hash tables. These are created in a 128-bit token space.
These nodes are allocated a subset of the token space and created as part of a ring topology. It guarantees that at any given point of time, only a single owner of the token exists. This is how it elects the leader and guarantees consistent routing. It detects failure using standard techniques like heart beating and arbitration. Reliability subsystem. As the name suggests, the reliability subsystem is responsible for making sure that our system is highly available.
It uses a replicator, fail over manager, and resource balancer. The replicator replicates the state changes from primary to secondary replicas, maintains consistency between them and manages the quorum among the replicas. Service Fabric provides us with fabric replicator which is exposed by an API that we can use to make the service date highly available and reliable. The fail over manager manages automatic distribution of the load in case of a failure.
It is tasked with reconfiguring the service replicas for high availability. The resource manager ensures that all fail over units are operational and helps achieve optimal uniform load distribution. Management subsystem. This is responsible for providing end-to-end service and application life cycle management. The cluster manager is fully responsible for the complete life cycle of the application. This entails working with a health manager to ensure availability of the system.
The health manager is responsible for monitoring the health of the entire system. This includes applications, services, and cluster entities such as nodes, service partitions, and replicas. All the health information is reported by cluster entities. This information is later aggregated into a centralized health store. This exposes health query APIs that enables us to gather raw health data.
And then we have the image store inside the management subsystem. This is a store where we upload our application package or binaries. Even though the image store is a distributed store, if you run your entire application on one local machine, it's simply not distributed. You will see that it's nothing but a direct link to your file system. This is important to understand. There is no point creating a distributed version of an image store on the same disk.
That's because even though you might have multiple nodes logically, physically it's still the same disk and failure of that one disk will mean the failure of all the replicas. We also have PowerShell commandlets and administrative APIs that enable us to provision, deploy, patch, upgrade, and deprovision applications without loss of any availability inside the management subsystem. Hosting subsystem.
This subsystem runs on every single node. Cluster manager lets the hosting subsystem know the list of services it needs to provide to manage a particular node. These services are integral components of the application life cycle for that particular node. Hosting subsystem also interacts with the reliability subsystem and the health manager to ensure the health of the node. Communication subsystem. This subsystem helps clients communicate with any node in the cluster.
It also helps to resolve a service name and retrieve the associated service metadata in case of the resizing of the cluster. Developers can resolve the actual network location using a simple naming client API. This enables them to be able to manage service names and properties associated with them. Testability subsystem. This subsystem provides a suite of tools specifically designed for testing services built on Service Fabric.
It lets developers introduce false to simulate a real production environment. It allows them to run test scenarios. It also allows them to validate the numerous dates and transitions that a service will experience throughout its lifetime. The best part is being able to automate longer tests with introduction of failure and testing for availability during such a scenario. This subsystem is used before and after deployment to minimize failure and ensure the overall health of the application.
- Reviewing microservices vs. monolithic architecture
- Reviewing microservices and Azure Service Fabric basics
- Programming model architecture
- Creating a stateless service and a stateful service
- Creating a cluster in Azure
- Adding security to a cluster
- Finalizing cluster creation
- Deploying to an Azure cluster
- Debugging an application remotely