In the previous section, we talked about the two lowest concepts of Service Fabric, one is Node Type and Node at the hardware level. The other is Application.
Node Type is a collection of Nodes, which are conceptual abstractions of deploying machines. For Service Fabric, a node can be a physical machine, a virtual machine, or even the most popular container now.
Running on Node Type is Application. It is an abstract understanding at the level of system software. There are multiple Micro Services in an application. Even all the underlying services of Service Fabric, such as FailoverManager Service and Naming Service, are Micro Services.
All distributed features of Service Fabric correspond to Micro Service deployments. We can dynamically adjust how many instances a Micro Service needs to run on how many nodes to distribute load pressure or perform disaster recovery backups. Each instance listens to a different port, and the load balancing layer distributes requests to different instances.
Actual scenario
Stateful Service is one of the Micro Services.
Before we start introducing Stateful Service, let's consider the following common business scenarios.
You're thinking about implementing a shopping cart feature on your website. After logging in, users will place some items in their shopping cart.
The next time the user logs in, the front desk page will call the shopping cart service, and need to re-read the saved shopping cart data from this service and display it.
If so, how would you achieve it?
If the number of users is not particularly large, we will add a shopping cart table to the database and associate it with the user table. The cart table will have a user ID field and record a large amount of user cart data.
Then this will bring some follow-up problems.
If the number of users continues to increase, the performance of the database tables will continue to degrade.
Database table data needs to be backed up regularly in case of data loss
If there is a problem with database performance, the table needs to be debunked or even partitioned
The shopping cart system itself needs to handle any adjustments to the database, and even it may need to be load balanced
The root of this problem is that the system itself is not designed to be scalable in the first place. In addition, databases are a potential bottleneck and threat to performance.
Stateful Service
Let's consider such a completely new architecture.
From the beginning, the shopping cart system has 36 sub-services that handle all requests (36 because the initials of the user ID are 0-9 a-z, a total of 36).
The user's request is processed according to the initial hash of the user ID to a specific sub-service.
The sub-service stores the shopping cart data in-house through a lightweight database and persists it on its own storage device.
Each sub-service also has 3 backups, which are constantly synchronizing the stored data, and these backups are always running on different nodes.
At the same time, only one backup is responsible for processing requests as an activation state, and when there is a problem with activating the backup, the other two backups activate one according to the scheduling algorithm.
The disaster recovery subsystem creates a new backup to ensure that the subservice always has 3 healthy backups.
Stateful Service is one such solution.
Back to the above scenario, the shopping cart system is a stateful service.
The 36 subsystems are the 36 instances of this Stateful Service, which we call Partitions.
The backup under each subsystem is Replica, and there are 3 Replicas in a partition.
The currently active backup is Active Replica, and the two inactive standby backups are Secondary Replica.
Each replica of the same Partiion must run on a different node.
The Stateful Service code uses <T>interfaces such as IReliableCollection, IReliableDictionary< T1, and T2 >to save data and synchronize internally.
In addition, Stateful Service can implement the following features:
All of the above numbers can be reset, and you can have hundreds of partitions in the cart system to load more stress. You can even have 5 or more replicas per partition to ensure more robustness.
External systems don't care how many partitions the Stateful Service has, they are called by partition key. The partition key and the corresponding partition are resolved by the underlying Micro Service of Service Fabric. For example, in your business, you may have a few million users, but only set up 5 partitions. When calling the shopping cart Stateful Service, the external system only needs to inform the user ID (partition key) and the saved data. This request is automatically mapped to one of the five partitions based on the user ID and hash algorithm.
Data operations in Stateful Services support transactions. So you can rollback on failure
I hope the above introduction can help you better understand Stateful Service.
We'll cover code examples for Stateful Service in the following sections. |
Posted on 3/15/2018 10:03:44 AM
|
|
|
|
