L’architecture de service est une approche de conception logicielle qui résout un problème avec une série de services autonomes.
Analogie
Une analogie raisonnable pour l’architecture de service est une organisation telle qu’une banque. La banque divise le travail en une variété de services tels que le service client, les services informatiques et les services de gestion des ressources humaines. Chaque service est indépendant et peut être déployé dans différents bureaux. Les clients de chaque service se voient proposer un contrat qui précise ce que l’on peut attendre du service. Par exemple, la gestion des ressources humaines peut aider une équipe à recruter du nouveau personnel avec un formulaire que l’équipe remplit pour lancer le processus. La structure de service de l’entreprise décompose le problème complexe de l’exploitation d’une banque en petits blocs de fonctionnalités de gestion.
Services
Les services sont des unités de logiciel qui exécuter une fonction. Ils sont utilisés pour décomposer des problèmes complexes en une série de problèmes plus simples. Les services sont également conçus pour être déployables séparément. Il s’agit d’un avantage majeur car il vous permet de créer des systèmes hautement évolutifs et résilients.
Résilience
La résilience est un terme désignant un logiciel fiable dans des conditions du monde réel qui comprend diverses contraintes et les échecs. L’architecture de service est une technique utile pour créer des systèmes qui continuent de fonctionner en cas de défaillance. Pour ce faire, les services sont conçus de manière à être autonomes de manière à ne pas dépendre les uns des autres. Les services peuvent ensuite être déployés sur l’infrastructure cloud et mis à l’échelle selon les besoins. Lorsqu’une instance tombe en panne, les services sont suffisamment intelligents pour le détecter et automatiquement trouver une instance qui fonctionne.
Services vs composants
Les services et les composants sont deux manières différentes de diviser le travail en blocs gérables et réutilisables. La différence est que les services peuvent être déployés seuls. Les composants sont déployés avec autre chose et ne sont donc pas autonomes. Les services peuvent être construits à partir de composants. De même, les composants peuvent utiliser des services.
Architecture orientée services (SOA)
L’architecture orientée services était un terme précoce pour l’architecture de services qui a été adoptée et commercialisée par de nombreux grands fournisseurs informatiques qui l’ont utilisé pour vendre des plates-formes SOA et des intergiciels. Il s’agissait d’une grande mode de la technologie de l’information vers 2005 qui a vu de nombreuses implémentations descendantes qui impliquaient l’achat d’un ensemble de logiciels, puis la refonte des systèmes existants pour les intégrer dans un paradigme SOA. Une grande partie de cette activité a complètement manqué le point de la SOA et les échecs de projet étaient courants. La confusion a plu alors que les experts de l’informatique encourageaient ou critiquaient la SOA, souvent en rendant les choses aussi complexes que possible.
Microservices
Toutes les grandes idées et les absurdités qui a entouré SOA au sommet de sa popularité n’a pas empêché les architectes qualifiés d’utiliser ses idées de base de manière efficace et légère, ce qui a produit des systèmes et des applications fiables, évolutifs, gérables et rentables. Cela a évolué vers une nouvelle culture de conception de logiciels connue sous le nom de microservices, organisée autour d’un ensemble de principes de conception de services.
Exemple
Une entreprise de télécommunications conçoit un système de facturation comme une série de services déployables séparément. Chaque service est considéré comme un produit distinct qui peut être développé, maintenu et géré par différentes personnes. Les services sont déployés dans le cloud et faiblement couplés. Lorsqu’une instance de service échoue, les autres services basculent automatiquement vers une instance qui fonctionne toujours. Bien que le problème de la facturation des télécommunications soit extrêmement complexe, aucun service unique dans l’architecture n’est complexe de sorte que chacun est relativement bon marché à développer et à gérer. Les services sont essentiellement auto-organisés. Chacun publie une API pour les autres services. Chacun sait ce dont il a besoin des autres services et est suffisamment intelligent pour contourner les instances défaillantes afin de trouver les services qui répondent. En d’autres termes, l’architecture n’a pas de contrôleur central ni d’intergiciel.
Présentation: architecture de service | ||
Type | ||
Définition | Une approche de conception logicielle qui résout un problème avec une série de services autonomes. | |
Concepts associés |