Compétences avancées en conception d'architecture de système · Théorie et pratique de la conception d'architecture orientée services

Cliquez pour accéder au répertoire des séries d'articles

1. Concepts associés à la SOA

1.1Définition de la SOA

A partir de la définition des principes de base du logiciel, on peut considérer que SOA est un modèle de composants qui relie différentes unités fonctionnelles d'une application (appelées services) via des interfaces et des contrats bien définis entre ces services. L'interface est définie de manière neutre et doit être indépendante de la plateforme matérielle, du système d'exploitation et du langage de programmation sur lesquels le service est implémenté. Cela permet aux services intégrés dans une variété de systèmes de ce type d'interagir de manière unifiée et commune.

1.2 Processus métier et langage d'exécution des processus métier

Langage de processus métier et d'exécution de processus métier (Business Process Execution Language, BPEL) . Le processus métier fait référence à un processus ou à une série d'actions effectuées pour atteindre un certain objectif commercial. Grâce à BPEL, les utilisateurs peuvent mettre en œuvre une architecture orientée services de haut en bas en composant, orchestrant et coordonnant les services Web. BPEL est actuellement utilisé pour intégrer des services Web existants et organiser les services Web existants en un nouveau service Web en fonction des processus métier requis. Sur cette base, un service est formé qui est identique à un service unique du monde extérieur.

2. Historique du développement de la SOA

(1) Stade embryonnaire : cette utilisation généralisée de XML permet aux organisations de définir les métadonnées des documents, de permettre l'échange électronique de données au sein et entre les entreprises, et de spécifier le format et la structure de l'échange de données entre les services et au sein des services.

(2) Étape de normalisation : Normes et spécifications internationales - Simple Object Access Protocol (SOAP), Web Service Description Language (Web Service Description, UDDI).

(3) Stade mature : 3 spécifications poids lourds - SCA, SDO, WS-Policy. SCA et SDO constituent la base du modèle de programmation SOA, et WS-Policy établit les spécifications pour les interactions sécurisées entre les composants SOA.

3. La différence entre SOA et microservices

(1) Les microservices sont plus sophistiqués que la SOA. Les microservices existent davantage en tant que processus indépendants et n'ont aucune influence les uns sur les autres.

(2) La méthode d'interface fournie par les microservices est plus universelle, comme la méthode HTTP RESTful, qui peut être appelée par différents terminaux quelles que soient les restrictions de langue et de plate-forme.

(3) Les microservices sont plus enclins à une méthode de déploiement distribuée et décentralisée, plus adaptée aux scénarios commerciaux Internet.

Comme suit, un tableau comparatif entre l'architecture SOA et l'architecture de microservices :

3. Architecture de référence SOA

L'architecture de référence d'intégration métier Websphere d'IBM est une architecture d'intégration d'entreprise typique centrée sur les services, qui peut être divisée en six catégories :

(1) Service de logique métier.
(2) Service de contrôle.
(3) Service de connectivité.
(4) Service d'innovation et d'optimisation des entreprises.
(5) Service de développement.
(6) Gestion des services informatiques.

4. Principales spécifications du protocole SOA

Comme suit, basé sur le protocole du service Web :

(1) Protocole UDDI : protocole unifié de description, de découverte et d'intégration. Contient une spécification standard pour la description et la découverte des services, qui permet aux entités commerciales de se découvrir mutuellement ; définit la manière dont elles interagissent sur Internet et partagent des informations dans une architecture d'enregistrement globale.

(2) Web Service Description Language (WSDL) : WSDL est un langage XML utilisé pour décrire les services Web et expliquer comment communiquer avec les services Web. Décrit 3 attributs de base des services Web :

• Ce que fait le service : les opérations (méthodes) fournies par le service.
• Comment accéder au service - le format des données et les protocoles nécessaires pour interagir avec le service.
• Où se trouve le service : une adresse liée au protocole, telle qu'une URL.
  Voici le cadre structurel de base du document :
  

(3) Protocole SOAP : SOAP est un protocole simple d'échange d'informations dans un environnement décentralisé ou distribué. Il s'agit d'un protocole basé sur XML.
(4) Spécification REST : afin de permettre à différents logiciels ou applications de se transférer des informations dans n'importe quel environnement réseau. Les microservices sont exposés aux appelants sous la forme d'API REST. RESTful est la forme de REST. Il s'agit d'un terme général désignant un type de conception architecturale ou d'application qui suit les idées de conception REST tout en satisfaisant les contraintes de conception. Ce type peut être appelé RESTful, qui peut être compris comme un transfert d'état expressif de ressources :

• Ressources : Toutes les transactions exposées aux clients sur Internet peuvent être considérées comme une ressource.
• Représentation : La représentation est utilisée en REST pour décrire l'état des ressources à un moment donné dans le Web.
• Transfert d'état : divisé en deux types,
  état de l'application - un instantané des informations relatives à la session de demande de l'utilisateur au cours d'une certaine période de temps, enregistré sur le client.
  L'état de la ressource - enregistré sur le serveur, est un instantané de la représentation de la demande de ressource à un moment donné.
• Hyperliens : établissez des connexions vers d’autres ressources en intégrant des liens dans vos pages.

5. Exigences des normes de conception SOA

(1) Normalisation des documents .
Les services SOA disposent de documents XML auto-descriptifs indépendants de la plate-forme. Le langage de description des services Web est un langage standard pour décrire les services.

(2) Normes de protocole de communication .
Les services SOA communiquent à l'aide de messages, généralement définis à l'aide d'un schéma XML (également appelé définition de schéma XML, XSD).
(3) Enregistrement et intégration unifiés des applications .
Au sein d'une entreprise, les services SOA sont maintenus via un registre qui joue le rôle de Director Listing. L'application recherche et appelle un service dans le Registre. La description, la définition et l'intégration unifiées sont les normes pour l'enregistrement des services.
(4) Qualité de service (Qos) . comprennent principalement :

• Fiabilité : caractéristiques de transmission lors de la transmission de documents entre consommateurs de services et fournisseurs de services (et transmettre une seule fois, transmettre au plus une fois, filtrage des messages répétés, livraison garantie des messages)
• Sécurité : les spécifications de sécurité du service Web sont utilisées pour assurer la sécurité des messages.
• Politiques : les fournisseurs de services exigent parfois que les consommateurs de services communiquent avec une certaine politique. Par exemple, un fournisseur de services peut exiger que les consommateurs fournissent un jeton de sécurité Kerberos pour obtenir un certain service.
• Contrôle : Dans SOA, les processus sont créés à l'aide d'un ensemble discret de services. BPEL4WS ou WSBPEL (Web Service Business Process Execution Language) est le langage utilisé pour contrôler ces services.
• Gestion : il doit exister un système de gestion unifié pour tous les services exécutés dans plusieurs environnements afin que les administrateurs système puissent les gérer efficacement. Tout service implémenté sur la base de WSDM peut être géré par une solution de gestion compatible avec WSDM.

6. Le rôle et les principes de conception de la SOA

(1) La fonction principale de la SOA : briser les îlots d'informations et convertir les applications et les ressources en services. Et transformez ces services en services standards pour former un partage de ressources.
(2) Les principes de conception de la SOA comprennent principalement :

• Apatride .
  Eviter que le demandeur du service ne soit dépendant de l'état du prestataire.
• Instance unique .
  Utilisez une méthode de mise en œuvre hautement cohérente pour éviter la redondance fonctionnelle.
• Interface bien définie .
  L'interface d'un service est définie par WSDL, qui permet d'indiquer la frontière entre l'interface publique du service et son implémentation privée interne.
• Autonome et modulaire .
  Les services encapsulent les activités et les composants stables et récurrents dans l'entreprise. Les entités fonctionnelles qui mettent en œuvre les services sont totalement indépendantes et peuvent être déployées, versionnées, autogérées et restaurées de manière indépendante.
• Gros grain .
  Le nombre de services ne doit pas être trop important et reposer sur l'interaction des messages plutôt que sur l'appel de procédure à distance (RPC). Habituellement, le volume des messages est important, mais la fréquence d'interaction entre les services est faible.
• Couplage lâche entre les services .
  Ce que voient les utilisateurs du service, c'est l'interface du service. Son emplacement, sa technologie de mise en œuvre et son état actuel ne sont pas visibles pour les utilisateurs. Les données privées du service ne sont pas visibles pour les utilisateurs du service.
• Interopérabilité, compatibilité et déclarations de politique .
  Afin de garantir que la spécification du service est complète et claire, des politiques sont utilisées pour définir une sémantique d'interopérabilité configurable afin de décrire les attentes de services spécifiques et de contrôler leur comportement. Tirez parti des déclarations de politique pour garantir l’exhaustivité et la clarté des attentes en matière de service et de la compatibilité sémantique.

7. Modèles de conception SOA

7.1 Mode registre de services

Le registre de services prend en charge le développement, la publication et la gestion des contrats de service, des politiques et des métadonnées qui pilotent la gouvernance SOA.
(1) Enregistrement des services : Les développeurs d'applications, également appelés fournisseurs de services, publient leurs fonctions dans le registre.
(2) Emplacement du service : Autrement dit, les développeurs d'applications de service les aident à interroger les services d'enregistrement et à trouver des services qui répondent à leurs propres besoins.
(3) Liaison de service : Le consommateur du service utilise le contrat de service récupéré pour développer du code. Le code développé est lié au service enregistré, appelle le service enregistré et interagit avec lui.

7.2 Modèle de bus de services d'entreprise (EBS)

Le modèle de bus de services d'entreprise fournit une architecture sous-jacente logicielle standard. Divers composants de programme peuvent être « insérés » dans la plate-forme en tant qu'unités de service et peuvent interagir les uns avec les autres dans une méthode de communication de message standard . Ses fonctions principales sont les suivantes :

(1) Services de routage et d'adressage des messages qui assurent la transparence de la localisation. Les composants du programme n'ont pas besoin de prêter attention au routage et à l'adressage des uns et des autres.
(2) Fournir des fonctions de gestion pour l'enregistrement et la dénomination des services.
(3) Prise en charge de plusieurs spécifications de messagerie (telles que demande/réponse, publication et abonnement).
(4) Prend en charge une variété de protocoles de transmission largement utilisés.
(5) Prend en charge plusieurs formats de données et leur conversion mutuelle.
(6) Fournir des fonctions de journalisation et de surveillance.

Comme indiqué ci-dessous, schéma EBS :

7.3 Modèle de microservice

Architecture des microservices La division d' une grande application ou d'un service en plusieurs microservices vous permet de faire évoluer des composants individuels plutôt que l'ensemble de la pile d'applications pour respecter les accords de niveau de service. L'architecture des microservices divise les services autour de domaines d'activité. Chaque service peut être développé, géré et itéré indépendamment. Ils communiquent entre eux à l'aide d'une interface unifiée, réalisant les fonctions de déploiement, de gestion et de service dans des composants dispersés, facilitant ainsi la livraison du produit. Il devient plus simple de divisez efficacement les applications et réalisez un développement et un déploiement agiles. Les caractéristiques du modèle de microservice sont les suivantes :
(1) Découplage d'applications complexes : L'architecture de microservice décompose une application à module unique en plusieurs microservices tout en gardant la fonctionnalité globale inchangée.
(2) Indépendant : les microservices sont développés, testés et déployés indépendamment dans le cycle de vie du logiciel système.
(3) Sélection technologique flexible : La sélection technologique des applications système sous l'architecture des microservices est décentralisée. Chaque équipe de développement peut choisir l'architecture système et la technologie appropriées en fonction des besoins commerciaux de sa propre application.
(4) Tolérance aux pannes : chaque microservice est indépendant les uns des autres, les pannes seront isolées dans un seul service et les autres microservices du système peuvent atteindre la tolérance aux pannes de la couche application grâce à des mécanismes tels que les nouvelles tentatives et la dégradation en douceur, améliorant ainsi la tolérance aux pannes de applications système.
(5) Couplage lâche et expansion facile : chaque service de l'architecture de microservice est faiblement couplé et peut être étendu indépendamment en fonction des besoins réels, reflétant la flexibilité de l'architecture de microservice. Le diagramme schématique de l'architecture d'application monolithique et de l'architecture de microservices est le suivant :

7.4 Solution de modèle d'architecture de microservices

La solution de modèle d'architecture de microservice comprend principalement :
(1) Microservice d'agrégateur : l'agrégateur agit comme un commandant de processus et appelle plusieurs microservices pour implémenter les fonctions requises par les applications système.
(2) Microservices chaînés : une fois que le client ou le serveur a reçu une requête, des appels récursifs imbriqués entre plusieurs services se produiront et une réponse traitée sera renvoyée.
(3) Microservices de partage de données : Ce modèle convient à la phase de transition de l'architecture monolithique à l'architecture de microservices. Des relations de couplage fortes sont autorisées entre les services, telles que plusieurs microservices partageant le cache et le stockage de base de données.
(4) Microservices de messagerie asynchrone : pour certaines logiques métier qui n'ont pas besoin de s'exécuter de manière synchrone, les files d'attente de messages peuvent être utilisées à la place de REST pour implémenter des requêtes et des réponses afin d'accélérer la vitesse de réponse des appels de service.

Comme suit, architecture monolithique et architecture de microservices :

7.5 Problèmes et défis rencontrés par l'architecture des microservices

(1) La découverte de services et le suivi de la chaîne d’appels de service deviennent difficiles.
(2) Il est difficile d’obtenir une forte cohérence dans les bases de données traditionnelles et recherche plutôt une cohérence éventuelle.

8. Problèmes auxquels il convient de prêter attention lors de la création d'une architecture SOA

(1) Les exigences d'intégration dans l'architecture système d'origine comprennent : les exigences d'intégration des applications, les exigences d'intégration de l'interface utilisateur du terminal, les exigences d'intégration des processus et les exigences d'intégration des informations système existantes.

(2) Le contrôle de la granularité du service et la conception des services sans état s'expriment comme suit :

• Contrôle de la granularité des services : il est recommandé d'utiliser des interfaces à granularité grossière pour les services qui seront exposés en dehors de l'ensemble du système, tandis que les interfaces de services à granularité relativement fine sont généralement utilisées dans l'architecture du système d'entreprise.
• Conception de services sans état : Les services spécifiques dans l'architecture du système SOA doivent être des requêtes indépendantes et autonomes. Lors de la mise en œuvre de ces services, l'état de la requête précédente n'est pas requis, ce qui signifie que les services ne doivent pas dépendre du contexte d'autres services. Et l'état, c'est-à-dire que les services dans l'architecture SOA doivent être des services sans état.

9. Processus de mise en œuvre de la SOA

(1) Sélectionnez les solutions SOA principalement sous les trois aspects suivants :

• Essayez de choisir un plan qui permet une planification globale.
• Lors du choix, tenez pleinement compte des besoins de l’entreprise elle-même.
• Effectuer des inspections sur les aspects techniques tels que la plate-forme et la mise en œuvre.

(2) L'analyse des processus métiers se concentre principalement sur :

• Établir un modèle de service :
  méthode de décomposition descendante, méthode d'analyse des objectifs commerciaux, méthode d'analyse ascendante.
• Établir des processus métier :
  établir des objets métier (objets métier tels que des entités, des processus, des événements, etc.), établir des interfaces de service et établir des processus de service.

Cliquez pour accéder au répertoire des séries d'articles