L'idée des microservices n'est pas nouvelle. Les personnes âgées peuvent avoir travaillé avec
EJB à leur apogée. Qu'est-ce que c'est, déjà
Samuel Colt a utilisé une approche modulaire pour fabriquer ses revolvers. Les pièces standard de précision de ses pistolets étaient interchangeables, ce qui simplifiait considérablement la production et la maintenance. Alors pourquoi l'infrastructure ne devrait-elle pas être modulaire?
Il n'y a aucune objection fondamentale à cela, et l'idée elle-même se trouve à la surface. Mais le sujet des microservices est devenu relativement récent. Et il y a une raison à cela.
Pendant longtemps, l'entretien de l'infrastructure est resté une tâche laborieuse et plutôt spécialisée. Seuls les administrateurs qualifiés peuvent déployer un cache ou une file d'attente dans l'infrastructure. Que chaque partie de l'application avait sa propre infrastructure, et il ne faisait aucun doute - qui desservira tout ce zoo?!
Mais la technologie de virtualisation, les conteneurs et les outils de gestion de la configuration de l'infrastructure ont fait du chemin. Et maintenant, déployer une infrastructure indépendante pour un service d'application distinct est devenu encore plus facile et moins cher que de regrouper tous les services dans une infrastructure commune. Progrès!
L'application est commodément divisée en parties indépendantes, y compris pour des raisons d'organisation. Dans ce cas, l'interaction entre les pièces s'effectue via l'une ou l'autre API. L'essentiel est le service. De là commence le processus de division de l'application en macro-services, métroservices, microservices, nanoservices, picoservices et fonctions lambda sur une seule ligne dans Amazon.
Il semblerait que ce qui pourrait mal tourner ici?
Hélas, la division de l'application en plusieurs parties n'est pas gratuite. Tout d'abord, le coût de la prise en charge de l'API à l'intérieur de l'infrastructure augmente.
Supposons qu'une application ait besoin de travailler avec des fichiers. Une tâche typique. Un microservice qui implémente l'infrastructure de stockage de fichiers est alloué; il fournit deux opérations: lecture et écriture. Et sans modifications importantes de l'API, un tel service peut passer d'une interface à un dossier sur un disque local à une infrastructure de centre de données géographiquement distribuée. Le scénario parfait.
Mais que se passe-t-il si l'application est divisée en services de telle manière que les lignes impaires de la logique métier se retrouvent dans un service et les lignes paires dans un autre? Non seulement une telle séparation ralentira considérablement l'application, car maintenant au lieu d'appeler directement la méthode, la communication réseau se produira, de sorte que l'API entre les services changera si souvent qu'elle s'adaptera à la version longue pour le numéro de version de l'API.
Tout cela, bien sûr, est une exagération. Cependant, il donne une image claire des conséquences négatives possibles. Une application ainsi construite est extrêmement coûteuse à développer.
Avant de diviser l'application en plusieurs parties, deux aspects doivent être pris en considération.
Le premier. À quelle fréquence ces composants interagiront-ils en une seule opération? Est-il possible que pour chaque action, vous devez effectuer des centaines, voire des milliers d'appels réseau. Cela peut réduire les performances des applications.
Deuxième. À quelle fréquence l'API changera-t-elle entre les composants? Si l'histoire de Git montre que l'API changera chaque jour, le coût de son support sera probablement prohibitif. Cela peut tuer la productivité du développement.
Néanmoins, avec la division correcte de l'application en services, vous pouvez obtenir des avantages significatifs. C’est juste que ces services ne doivent pas nécessairement être micro.