En bref sur les types d'architectures logicielles et celle que nous avons choisie pour le fournisseur IaaS

Il existe de nombreux types d'architectures logicielles avec leurs avantages et leurs inconvénients. Ensuite, nous parlerons des fonctionnalités des plus populaires et parlerons de notre transition vers les microservices.


/ libreshot / PD

Types d'architectures logicielles

Architecture en couches

Il s'agit de l'une des architectures les plus courantes. Sur sa base, de nombreux grands frameworks sont construits - Java EE, Drupal, Express. L'exemple le plus célèbre de cette architecture est peut-être le modèle de réseau OSI .

Le système est divisé en niveaux, dont chacun interagit avec seulement deux voisins. Par conséquent, les requêtes vers la base de données, qui se trouve généralement à la toute fin de la chaîne d'interaction, passent séquentiellement à travers chaque «couche».

L'architecture n'implique aucun nombre obligatoire de niveaux - il peut y en avoir trois, quatre, cinq ou plus. Le plus souvent, des systèmes à trois niveaux sont utilisés: avec un niveau de présentation (client), un niveau logique et un niveau de données.


D'innombrables livres et articles ont été écrits sur l'architecture à plusieurs niveaux. Et il y avait des opinions différentes sur ses avantages et ses inconvénients.

Avantages:

Chaque niveau de cette architecture exécute un ensemble strictement limité de fonctions (qui ne sont pas répétées d'une couche à l'autre) et ne sait pas comment les autres niveaux sont organisés. Par conséquent, le «contenu» des niveaux peut être modifié sans risque de conflits globaux entre les couches.

En général, les applications à plusieurs niveaux sont si répandues que des générateurs de modèles spéciaux sont créés pour leur développement. Par exemple, LASG pour Visual Studio propose plusieurs méthodes de génération de code qui automatisent les tâches de routine et aident à créer des niveaux d'application.

Inconvénients:

En programmation, on dit que tout problème peut être résolu en ajoutant un autre niveau d'abstraction. Cependant, cette approche peut finalement conduire à une mauvaise organisation du code et dérouter les développeurs.

Un autre problème vient de cela - la faible vitesse. De nombreuses informations commencent à passer inutilement d'une couche à l'autre, sans utiliser de logique métier. Ce problème est parfois appelé un anti-modèle de gouffre, un modèle de conception lorsque le nombre d'opérations inutiles commence à prévaloir sur les opérations utiles.

Trouver des bogues sur des systèmes à plusieurs niveaux peut également être difficile . Avant d'entrer dans la base de données, les informations passent par tous les niveaux (car la base de données est le composant final). Si, pour une raison quelconque, ces informations sont endommagées (ou perdues en cours de route), pour trouver une erreur, vous devez analyser chaque niveau séparément.

Bon ajustement:

• Pour créer de nouvelles applications qui doivent être déployées rapidement. Il s'agit d'une sorte de "modèle à usage général".
  
  

  Lorsque nous avons commencé à travailler sur les systèmes internes de notre fournisseur d'infrastructure virtuelle dans 1cloud , nous avons utilisé ce type particulier d'architecture. Au départ, nous n'avions pas pour tâche de créer un service IaaS capable de traiter le trafic de dizaines ou de centaines de milliers d'utilisateurs. Nous avons décidé de lancer rapidement le produit sur le marché et de commencer à développer une base de clients et à résoudre les problèmes de mise à l'échelle au fur et à mesure qu'ils deviennent disponibles (et maintenant nous transférons tous les systèmes vers une architecture de microservice, qui sera discutée plus tard).

  
  Parmi les développeurs, il y a une opinion qu'il n'est pas nécessaire dès les premiers jours du projet de le préparer à des charges colossales (écrire un logiciel à l'épreuve du temps). Les exigences réelles pour l'application ou le service peuvent différer des attentes et les objectifs commerciaux peuvent changer . Par conséquent, un code écrit dans un avenir lointain risque de devenir une dette technique.
• Selon O'Reilly, l'architecture en couches est un choix naturel pour de nombreuses applications d'entreprise. Comme les entreprises (surtout les grandes) partagent souvent des compétences: il y a une équipe responsable du front-end, il y a des gens qui sont responsables du back-end, etc. Cela implique la division naturelle des applications en niveaux: certains développeurs travaillent sur le client, d'autres sur la logique.
  
  Une relation similaire entre la structure de l'organisation et les approches de développement d'applications est également dictée par la loi de Conway , formulée en 1967. Il se lit comme suit: «Lors du développement d'un système, les organisations sont obligées d'adhérer à un schéma qui répète la structure des communications au sein de l'entreprise.

Architecture orientée événement

Dans ce cas, le développeur prescrit le comportement (réactions) du programme lorsque des événements se produisent. Un événement dans le système est considéré comme un changement significatif de son état.

Vous pouvez faire une analogie avec l'achat d'une voiture en cabine. Lorsqu'une voiture trouve un nouveau propriétaire, son état passe de «à vendre» à «vendu». Cet événement lance le processus de préparation à la pré-vente - installation d'équipements supplémentaires, vérification de l'état technique, lavage, etc.

Un système piloté par événements contient généralement deux composants: les sources d'événements (agents) et leurs consommateurs (récepteurs). Il existe également généralement deux types d'événements: un événement initiateur et un événement auquel les consommateurs répondent.

Un exemple de la mise en œuvre d'une telle architecture est la bibliothèque Java Swing. Si la classe a besoin d'une alerte sur un événement, le développeur implémente le soi-disant écouteur - ActionListener (il "attrape" l'événement correspondant) et l'ajoute à l'objet que cet événement peut générer.

Le code d'implémentation suivant pour ce mécanisme est fourni sur le Wiki:

public class FooPanel extends JPanel implements ActionListener { public FooPanel() { super(); JButton btn = new JButton("Click Me!"); btn.addActionListener(this); this.add(btn); } @Override public void actionPerformed(ActionEvent ae) { System.out.println("Button has been clicked!"); } } 

Avantages de l'architecture:

Étant donné que les applications se composent d'un grand nombre de modules asynchrones (qui n'ont pas d'informations sur la mise en œuvre de l'autre), elles sont faciles à mettre à l'échelle. Ces systèmes sont assemblés comme un constructeur - vous n'avez pas besoin d'enregistrer les dépendances, implémentez simplement un nouveau module. De plus, le modèle asynchrone permet des performances élevées des applications.

Inconvénients:

La nature asynchrone de ces applications complique le débogage. Un événement peut déclencher plusieurs chaînes d'actions à la fois. S'il existe de nombreuses chaînes de ce type, il peut être difficile de comprendre la cause exacte de l'échec. Pour résoudre le problème, nous devons trouver les conditions difficiles de la gestion des erreurs. À partir de là, le problème de la journalisation suit - les journaux sont difficiles à structurer.

Convient pour:

• Création de systèmes asynchrones. Cela est évident car l'architecture elle-même se compose d'un grand nombre de modules asynchrones.
• Peut être utilisé pour créer une interface utilisateur. Une page Web agit comme un conteneur dans lequel chacun de ses composants est isolé et répond à certaines actions de l'utilisateur.
• Organiser la messagerie entre différents systèmes d'information.

Architecture micro-noyau

Ce type d'architecture se compose de deux composants: le cœur du système et les plugins. Les plugins sont responsables de la logique métier, et le noyau gère leur chargement et déchargement.


À titre d'exemple d'architecture micro-noyau, le livre O'Reilly fournit un IDE Eclipse. Il s'agit d'un simple éditeur qui ouvre des fichiers, leur permet d'être modifiés et exécute des processus d'arrière-plan. Mais avec l'ajout de plugins (par exemple, le compilateur Java), ses fonctionnalités s'étendent.

L'architecture du micro-noyau utilisait à une époque le système d'exploitation Symbian pour les appareils mobiles (le développement a été arrêté en 2012). Dans son micro-noyau se trouvait un planificateur de tâches, des systèmes de gestion de la mémoire et des pilotes, et le système de fichiers et les composants responsables des communications téléphoniques faisaient office de plug-ins.

Avantages de l'architecture:

Il est facile de porter une application d'un environnement à un autre, car seul le micro-noyau doit être modifié. La séparation des politiques de haut niveau et des mécanismes de bas niveau simplifie la prise en charge du système et garantit son extensibilité.

Inconvénients:

Les performances des applications sont réduites si vous branchez trop de modules. Cependant, il peut être problématique de trouver un équilibre entre le nombre de plugins et le nombre de tâches du micronoyau (généralement il ne contient que du code fréquemment utilisé).

Il est également difficile de déterminer à l'avance (avant le développement de l'application) le degré optimal de fragmentation du code du micronoyau. Et changer l'approche plus tard est presque impossible.

Bon pour:

• Créez des applications extensibles utilisées par un grand nombre de personnes. Par exemple, l'iPhone OS a des racines de «micro-noyau» - ses développeurs se sont inspirés de Mach (c'est l'un des tout premiers exemples de micro-noyau).
• Création d'applications avec une séparation claire des méthodes de base et des règles de haut niveau.
• Développement de systèmes avec un ensemble de règles en évolution dynamique qui doivent être mises à jour fréquemment.

Microservices

Similaire à l'architecture événementielle et au micro-noyau. Mais ils sont utilisés lorsque les tâches d'application individuelles peuvent être facilement divisées en petites fonctions - des services indépendants . Ces services peuvent être écrits dans différents langages de programmation car ils communiquent entre eux à l'aide de l'API REST (par exemple, à l'aide de JSON ou Thrift ).

Dans quelles proportions le code est divisé, le développeur décide, mais Sam Newman, l'auteur du livre « Création de microservices» , vous recommande d'allouer autant de lignes de code au microservice que l'équipe peut reproduire en deux semaines. Selon lui, cela permettra d'éviter des "ballonnements" excessifs de l'architecture.

Le plus souvent, les microservices sont lancés dans des soi-disant conteneurs. Ces conteneurs sont accessibles sur le réseau à d'autres microservices et applications, et le système d'orchestration les gère tous: Kubernetes, Docker Swarm, par exemple.

Avantages:

L'architecture de microservice simplifie la mise à l'échelle des applications. Pour implémenter une nouvelle fonctionnalité, il suffit d'écrire un nouveau service. Si la fonction n'est plus nécessaire, le microservice peut être désactivé. Chaque microservice est un projet distinct, il est donc facile de répartir le travail sur eux entre les équipes de développement.

En savoir plus sur les mécanismes de mise à l'échelle des systèmes de microservices dans le livre de Martin L. Abbott, The Art of Scalability.

Inconvénients:

Il est difficile de trouver des erreurs. Contrairement aux systèmes monolithiques (lorsque toutes les fonctions sont dans le même noyau), il peut être difficile de déterminer pourquoi la demande a "chuté". Pour plus de détails, vous devez vous rendre dans les journaux du processus «coupable» (s'il y en a plusieurs, le problème est aggravé).

Cela crée une surcharge supplémentaire pour la transmission de messages entre microservices. Selon nos estimations, la croissance des coûts de réseau peut atteindre 25%.

Un autre inconvénient est la nécessité de s'accommoder du concept de cohérence éventuelle ( cohérence à long terme ). Les microservices ont leurs propres entrepôts de données, auxquels d'autres microservices accèdent. Les informations sur les modifications de ces données ne sont pas distribuées instantanément via le système. Par conséquent, des situations surviennent lorsque certains microservices (quoique pour une période de temps extrêmement courte) contiennent des données obsolètes.

Où utiliser:

• Dans les grands projets avec une charge élevée. Par exemple, les microservices sont utilisés par les plateformes de streaming. Les systèmes de diffusion de contenu et autres services de support peuvent être mis à l'échelle indépendamment les uns des autres, en s'adaptant aux changements de charge.
• Dans les systèmes qui utilisent des ressources "mixtes". Si une partie de l'application a besoin de plus de temps processeur, et la seconde - de la mémoire, alors il est logique de les diviser en microservices. Ensuite, ils peuvent être hébergés sur différentes machines - avec un processeur puissant ou une grande quantité de mémoire, respectivement.
• Quand la sécurité est nécessaire . Étant donné que les microservices sont isolés et communiquent par API, il peut être garanti que seules les informations dont un service particulier a besoin seront transmises. Ceci est important lorsque vous travaillez avec des mots de passe ou des données de carte de paiement.

Pourquoi passons-nous aux microservices dans 1cloud

Comme nous l'avons déjà dit, la base des services que nous proposons ( cloud privé , serveurs virtuels , stockage en nuage d'objets , etc.) est basée sur une architecture à plusieurs niveaux. Elle s'est montrée du bon côté, mais maintenant sa capacité à évoluer a commencé à s'épuiser.

Nous devenons de plus en plus de partenaires qui fournissent leurs solutions basées sur notre plateforme de franchise. Il existe des sites et des services distants qui deviennent difficiles à gérer à partir d'un seul point (en particulier, nos équipements sont situés dans plusieurs centres de données en Russie, au Kazakhstan et en Biélorussie ).

Pour faciliter la mise à l'échelle des fonctions existantes et introduire de nouvelles fonctionnalités, nous transférons l'intégralité de notre infrastructure aux microservices dans 1cloud .



Nous voulons les séparer en modules séparés et au lieu d'une base de données complexe obtenir N simples. Ainsi, dans la nouvelle architecture, chaque fonctionnalité aura une base de données distincte. Il est beaucoup plus pratique et efficace en termes de support et de développement.

Nous pourrons répartir le travail sur les services entre plusieurs développeurs (mettre en évidence les spécialisations de l'entreprise) et évoluer efficacement horizontalement - si nécessaire, nous connectons simplement de nouveaux microservices.

Nos clients bénéficieront également d'un certain nombre d'avantages. Étant donné que les microservices ne sont pas connectés les uns aux autres, alors lorsqu'un service particulier échoue, seul il sera indisponible, tout le reste continuera à fonctionner normalement. De plus, même si une baisse globale de notre service se produit, le panneau de contrôle continuera de fonctionner.

Les clients du Kazakhstan et de Biélorussie (et d'autres pays où nous ouvrirons des bureaux de représentation) remarqueront une augmentation significative de la vitesse et de la réactivité des interfaces, car les panneaux de contrôle seront situés localement.

Ce qui a déjà été fait

Jusqu'à présent, nous n'avons mis en œuvre que le premier pilote: «Monitoring Service». Les services restants seront transférés sur une nouvelle piste fin 2018 - début 2019.

Dans le même temps, la nouvelle architecture jette les bases technologiques de la prochaine étape - la migration vers les conteneurs. Maintenant, nous utilisons l'infrastructure Windows et pour passer aux conteneurs, nous devons réécrire tout le code accumulé dans .NetCore et le transférer vers Linux.

Nous prévoyons de commencer une nouvelle transition au début de 2019 et de la terminer à la fin de l'année prochaine.

Que écrivons-nous d'autre sur le blog 1cloud:

• 1cloud Cloud Architecture Evolution: défis de modulation
• Comment IaaS aide les franchisés 1C: expérience 1cloud
• Pourquoi la surveillance est-elle nécessaire?