Dans la section précédente, nous avons parlé des deux concepts les plus bas du Service Fabric, l’un étant le Type de Node et le Node au niveau matériel. L’autre est l’application.
Le type de nœud est un ensemble de nœuds, qui sont des abstractions conceptuelles des machines en déploiement. Pour Service Fabric, un nœud peut être une machine physique, une machine virtuelle, ou même le conteneur le plus populaire aujourd’hui.
Sur le type de nœud s’exécute Application. C’est une compréhension abstraite au niveau du logiciel système. Il existe plusieurs microservices dans une application. Même tous les services sous-jacents de Service Fabric, tels que FailoverManager Service et Naming Service, sont des microservices.
Toutes les fonctionnalités distribuées de Service Fabric correspondent aux déploiements de microservices. Nous pouvons ajuster dynamiquement le nombre d’instances qu’un Micro Service doit exécuter sur le nombre de nœuds pour répartir la pression de charge ou effectuer des sauvegardes de récupération après sinistre. Chaque instance écoute un port différent, et la couche d’équilibrage de charge distribue les requêtes à différentes instances.
Scénario réel
Le service d’état est l’un des microservices.
Avant de commencer à introduire le Service Étatif, considérons les scénarios commerciaux courants suivants.
Vous envisagez d’implanter une fonctionnalité de panier d’achat sur votre site web. Après la connexion, les utilisateurs déposent certains articles dans leur panier d’achat.
La prochaine fois que l’utilisateur se connecte, la page d’accueil appellera le service de panier et devra relire les données sauvegardées de ce service et les afficher.
Si oui, comment y parviendriez-vous ?
Si le nombre d’utilisateurs n’est pas particulièrement élevé, nous ajouterons une table panier à la base de données et l’associerons à la table utilisateur. La table du chariot comportera un champ d’identification utilisateur et enregistrera une grande quantité de données de chariot utilisateur.
Cela apportera alors quelques problèmes de suivi.
Si le nombre d’utilisateurs continue d’augmenter, les performances des tables de la base de données continueront de se dégrader.
Les données des tables de base de données doivent être sauvegardées régulièrement en cas de perte de données
S’il y a un problème de performance de la base de données, la table doit être démystifiée, voire partitionnée
Le système de panier d’achat lui-même doit gérer tous les ajustements de la base de données, et même il peut devoir être équilibré en charge
La racine de ce problème est que le système lui-même n’est pas conçu pour être évolutif dès le départ. De plus, les bases de données constituent un goulot d’étranglement potentiel et une menace pour la performance.
Service d’État
Considérons une architecture complètement nouvelle.
Dès le départ, le système de panier d’achatage compte 36 sous-services qui gèrent toutes les requêtes (36 car les initiales de l’identifiant utilisateur sont de 0 à 9 a-z, soit un total de 36).
La requête de l’utilisateur est traitée selon le hachage initial de l’identifiant utilisateur pour un sous-service spécifique.
Le sous-service stocke les données du panier d’achat en interne via une base de données légère et les conserve sur son propre dispositif de stockage.
Chaque sous-service dispose également de 3 sauvegardes, qui synchronisent constamment les données stockées, et ces sauvegardes s’exécutent toujours sur différents nœuds.
En même temps, une seule sauvegarde est responsable du traitement des requêtes en tant qu’état d’activation, et lorsqu’il y a un problème pour activer la sauvegarde, les deux autres sauvegardes en activent une selon l’algorithme de planification.
Le sous-système de reprise après sinistre crée une nouvelle sauvegarde pour garantir que le sous-service dispose toujours de 3 sauvegardes en bon état.
Le service étatique est une de ces solutions.
Pour revenir au scénario ci-dessus, le système de panier d’achat est un service avec état.
Les 36 sous-systèmes sont les 36 instances de ce Service Étatif, que nous appelons Partitions.
La sauvegarde sous chaque sous-système est Replica, et il y a 3 Replicas dans une partition.
La sauvegarde actuellement active est Active Replica, et les deux sauvegardes de veille inactives sont Secondary Replica.
Chaque réplique de la même Partion doit s’exécuter sur un nœud différent.
Le code Stateful Service utilise <T>des interfaces telles que IReliableCollection, IReliableDictionary< T1 et T2 >pour sauvegarder les données et les synchroniser en interne.
De plus, le service avec états peut implémenter les fonctionnalités suivantes :
Tous les chiffres ci-dessus peuvent être réinitialisés, et vous pouvez avoir des centaines de partitions dans le système de chariots pour charger plus de stress. Vous pouvez même avoir 5 répliques ou plus par partition pour garantir une plus grande robustesse.
Les systèmes externes ne se soucient pas du nombre de partitions du service à état, ils sont appelés par clé de partition. La clé de partition et la partition correspondante sont résolues par le Micro Service sous-jacent du Service Fabric. Par exemple, dans votre entreprise, vous pouvez avoir quelques millions d’utilisateurs, mais ne configurer que 5 partitions. Lors de l’appel du service étatif du panier d’achat, le système externe n’a qu’à informer l’identifiant utilisateur (clé de partition) et les données enregistrées. Cette requête est automatiquement mappée à l’une des cinq partitions en fonction de l’identifiant utilisateur et de l’algorithme de hachage.
Les opérations de données dans les services étatiques prennent en charge les transactions. Ainsi, vous pouvez revenir en arrière en cas d’échec
J’espère que l’introduction ci-dessus pourra vous aider à mieux comprendre le service étatique.
Nous aborderons des exemples de code pour le service avec états dans les sections suivantes. |
Publié sur 15/03/2018 10:03:44
|
|
|
|
