Pour certains, les microservices sont la possibilité de refaire et de refactoriser une application dans un style relativement moderne. Cette solution architecturale ne convient pas aux autres en raison des particularités de l'interaction des différentes parties de l'application. Dans tous les cas, en choisissant une architecture, il est utile d'étudier l'expérience des autres de la transition d'un monolithe à un ensemble de services.
Nous avons demandé à partager notre étude de cas sur le développement et la livraison de microservices Alexei Baitov, ingénieur principal de 2GIS. Parlons des solutions architecturales, du déploiement et de l'évolutivité. Parlons des tendances et des outils pratiques pour travailler.
- Alexey, parlez-nous un peu de vous et de votre équipe dans 2GIS . Sur quoi travaillez-vous maintenant?
Je suis entré dans l'informatique en 2003 en tant qu'administrateur système, j'ai plongé dans le développement en 2011. Pendant ce temps, il a travaillé en PHP, JavaScript, implémenté une série de services RESTful et un pilote Python pour Git. Je travaille dans 2GIS depuis 2015.
Il a participé au développement de deux architectures de microservices. Le premier consistait en un service. C'était un proxy inverse asynchrone avec un cache. En fait, il était engagé dans l'envoi de messages. J'étais le seul impliqué dans l'élaboration des exigences, le développement et la construction de DevOps, mais des experts de notre société 2GIS m'ont aidé.
Le service a été écrit en Go. Une compilation rapide m'a permis de ne pas attendre et j'ai pu me concentrer sur le déploiement continu. Ensuite, nous
commencions à peine à utiliser
GitLab CI ,
Prometheus ,
Grafana et
Deis (analogue open source de
Heroku ). Nous avons une équipe d'Infrastructure et Opérations qui, au moment de mon développement, a amené toutes ces solutions d'infrastructure au niveau de production. J'ai décidé d'essayer tout cela et j'ai implémenté avec succès un microservice indépendant.
Il y a deux ans, j'ai rejoint une autre équipe sur un nouveau projet, où j'ai commencé à m'engager dans la programmation fonctionnelle à Scala. Notre équipe à partir de zéro a développé une architecture de microservices pour le stockage de matériel publicitaire 2GIS en Scala, C # et JavaScript. J'ai jeté les bases de tous les services avec les outils et l'expérience acquise pour construire des pratiques DevOps (Déploiement Continu et Maintenance). L'architecture est passée du prototype à l'exploitation industrielle. Elle a absorbé deux monolithes, se compose désormais de 15 services et est en constante expansion.
- Êtes-vous d'accord pour dire que les microservices sont essentiellement un ensemble de services déployés indépendamment qui ont des caractéristiques communes, c'est-à-dire qu'un ensemble de certaines fonctionnalités leur donne l'apparence d'un microservice? Cette définition doit-elle être élargie? Ou, en fait, les entreprises ont-elles une compréhension différente de l'architecture des microservices?J'aime la
définition suivante. L'architecture de microservice est un style architectural qui structure une application comme une collection de services faiblement couplés qui implémentent une logique métier spécifique. Les services d'une architecture de microservices peuvent ne pas avoir de caractéristiques communes, mais sont combinés dans une logique métier commune.
Bien sûr, chaque entreprise aura son propre microservice. Il s'agit d'un ensemble de pratiques: architecture distribuée, intégration et livraison continues, etc. Si vous étendez le concept de la pratique aux outils utilisés, les options de mise en œuvre des microservices seront très diverses.
- Il existe différentes opinions sur la composition de l'équipe, qui devrait être impliquée dans la rédaction et le soutien des microservices. Qu'en pensez-vous? Quelle est la taille optimale de l'équipe et comment devrait-elle être construite par l'interaction en son sein lors du développement d'une architecture de microservice? Y a-t-il un bon exemple de travail d'équipe de votre pratique?Il est considéré comme correct de développer un service de telle manière que l'ensemble de son domaine puisse tenir dans la tête d'un développeur. Parallèlement, plusieurs personnes peuvent participer au développement de ce service. Cela aidera à éviter le facteur bus lorsque le développeur est parti en vacances ou est tombé malade. Une répartition correcte des services permet à une nouvelle personne d'entrer rapidement dans le contexte.
L'architecture de microservice nous indique qu'elle comprend souvent plusieurs services. Ainsi, un développeur ne peut pas faire. L'architecture de microservice s'appuie sur le modèle de produit (ou la logique métier commune). Les développeurs sont sélectionnés pour qu'il s'avère implémenter ce modèle et en même temps se concentrer sur le client.
La concentration sur le client est organisée par un contact direct entre le développeur et le client. Les développeurs doivent voir comment leur produit est utilisé. De cela, les souhaits de connaissances dans le domaine technologique, la capacité de livrer le produit au client et d'accompagner le produit dès que possible suivent.
C'est difficile à dire sur la taille de l'équipe. Tout le monde connaît probablement déjà la déclaration de Jeff Bezos, le fondateur d'Amazon, selon laquelle la taille de l'équipe de développement orientée services devrait être suffisamment petite pour que tout le monde puisse se nourrir de deux pizzas. Dans les commentaires sur Habré, il y a eu une discussion sur ce sujet, et ils ont écrit qu'une personne peut ne pas avoir assez d'une pizza et qu'une équipe devrait donc être composée d'une ou deux personnes. Martin Fowler, citant une déclaration concernant deux pizzas, a déclaré qu'il s'agissait de grosses pizzas américaines, après quoi il a précisé que l'équipe ne devrait pas avoir 50, mais environ 12 personnes. Je crois que tout dépend du modèle de produit. Mais la clarification de Fowler sur «pas plus de 12 personnes» a gagné dans ma pratique jusqu'à présent. J'ai remarqué qu'au sein de l'équipe, il est souhaitable de se diviser en fonction des intérêts technologiques, de trouver des personnes partageant les mêmes idées.
Il n'est pas nécessaire que tout le monde dans l'équipe connaisse bien tous les domaines technologiques utilisés dans le travail, mais la connaissance totale de l'équipe doit être uniformément approfondie. Par exemple, deux personnes sont engagées dans la construction initiale d'un déploiement et à l'avenir, très probablement, elles l'amélioreront également de manière significative. Mais en même temps, toute l'équipe doit avoir une bonne compréhension du processus de déploiement. Cela lui permettra d'exprimer ses souhaits et d'apporter des modifications. Pourquoi deux personnes? Parce que parfois, une personne peut tomber dans une stupeur créative. Et dans la discussion, la vérité est née.
Nous avons naturellement construit sur ce principe, unis par des intérêts technologiques. Dans le même temps, le développeur peut également s'engager dans la mise en place de pratiques DevOps, et l'ingénieur QA peut développer un service auxiliaire hors production (par exemple, le chauffage du cache ou le service de recherche d'anomalies dans les données dans différents environnements).
- Presque tous les rapports sur les microservices commencent par l'histoire selon laquelle «ici nous avions un iceberg et nous avons scié, scié, scié ... De nouvelles parties de la demande ont été faites sur la base de microservices, puis nous avons commencé à séparer les« pièces »du moteur principal ... "
Dites-moi, êtes-vous un partisan du développement à partir de zéro ou peut-il y avoir des situations où cela vaut la peine de tirer une conclusion progressive d'un monolithe? Comment déterminer la stratégie de sortie?Je suis un partisan du développement à partir de zéro. Mais cela ne fonctionne que si l'ensemble des fonctions n'est pas trop compliqué. Habituellement, un petit monolithe MVP est fabriqué. Et parfois, il est nécessaire de changer radicalement plusieurs fois sa mise en œuvre interne. Cela peut être causé à la fois par un changement dans la tâche technique et par le fait qu'une compréhension de la mise en œuvre vient - des abstractions de haut niveau apparaissent au niveau du modèle commercial. Après cela, vous pouvez passer à l'architecture de microservice.
Mais si vous travaillez sur ces abstractions au tout début et que vous les dessinez dans des notations différentes (UML, BPMN, IDEF), afin que tous les participants au processus comprennent avec quoi ils travaillent, il est tout à fait possible d'implémenter une architecture de microservices immédiatement.
Notre chemin vers l'architecture de microservices n'était pas simple. Au début, il y avait un monolithe. Il a traité du matériel publicitaire textuel. Il y a trois ans et demi, nous devions travailler avec du matériel publicitaire graphique (images, logos). Il y avait un désir d'introduire dans la logique commerciale ce qui manquait lors de l'utilisation de matériel publicitaire textuel.
Pour tester un nouveau modèle commercial, nous avons mis en œuvre des travaux avec du matériel publicitaire graphique comme deuxième monolithe sur une autre pile technologique. Après un an et demi de fonctionnement, nous avons réalisé que cette approche était correcte.
Pendant ce temps, nous avons eu beaucoup de liste de souhaits, révélant la rugosité de la logique métier.
La mise en œuvre du deuxième monolithe a été difficile à étendre au premier. Par conséquent, nous avons décidé de ne pas mener le développement dans deux monolithes à la fois, mais de les combiner dans le cadre de la troisième architecture selon le tout nouveau modèle commercial. Une équipe de sept développeurs, un ingénieur QA et deux analystes a été créée. Deux développeurs de cette équipe ont précédemment créé et pris en charge le premier monolithe, et un de plus - le deuxième monolithe. Autrement dit, notre équipe déjà à l'entrée connaissait bien les pièges des monolithes précédents.
Le premier monolithe a été écrit en C #. Le second est en PHP. Nous ne voulions pas perdre les morceaux volumineux de code débogués du premier monolithe, et en même temps, le multithreading, un code sûr et un typage fort étaient nécessaires. Le code PHP ne répondait pas en partie à ces exigences. Par conséquent, C # est resté comme base et a mis en œuvre ce qu'il a bien fait dans le cadre du premier monolithe - travailler avec le contenu du matériel publicitaire - mais sur la base d'un autre stockage: stockage compatible S3 et Kafka.
Pour travailler avec le tout nouveau modèle économique, Scala et la base de données PostgreSQL ont été sélectionnées cette fois. Scala a répondu à nos exigences techniques. De plus, les développeurs Scala étaient situés au même étage que les développeurs C #. Cela a réduit le temps de communication de l'équipe. La loi de Conway a fonctionné - la structure de l'entreprise a dicté la structure de la demande. Le développeur PHP est devenu un développeur Scala. Je viens de terminer le travail sur un microservice indépendant sur Golang avec un cycle CI / CD complet, après quoi j'ai rejoint l'équipe et suis également devenu développeur Scala.
Il est intéressant de savoir exactement ce que j'ai proposé d'utiliser pour travailler avec la logique métier Scala, et non C #. Le fait est que nous n'avions pas assez de développeurs C #. PHP-shnik et moi voulions nous recycler pour Scala. De plus, nous avons eu l'opportunité d'attirer un développeur Scala expérimenté. Autre point: si nous implémentions tout en C #, nous pourrions obtenir soit une architecture de microservice, soit un autre monolithe en sortie. La division en Scala et C #, les différents besoins de stockage et la disponibilité de développeurs expérimentés dans chacun des domaines requis - tout cela a directement mis en évidence l'architecture de microservice. Et nous en avons seulement profité. Il y a un an, l'architecture de microservices pour travailler avec des matériaux graphiques et textuels est entrée en service commercial et fonctionne avec succès à ce jour.
À la question de savoir s'il est possible de créer une architecture de microservice à partir de zéro. Il y a un an et demi, alors que nous travaillions sur une architecture de microservices, nous avons proposé de soutenir une nouvelle orientation de nos produits: le matériel publicitaire vidéo. Il fallait tester rapidement un nouveau modèle de vente. Notre architecture en était à ses balbutiements. Le travail avec du matériel vidéo a couvert un nouveau domaine technologique. Nous avons décidé de ne pas changer le vecteur de développement et implémenté MVP pour les matériaux vidéo en tant qu'architecture de microservice autonome en C # et hébergement vidéo de confiance. C'est une expérience réussie et nous avons un
rapport sur ce sujet. Ainsi, nous avons deux architectures de microservices existantes parallèles. MVP n'a pas beaucoup développé, Wishlist s'est également accumulé dessus, et bientôt nous combinerons tout dans le cadre d'une architecture de microservice unique - nous aurons un référentiel unique de textes publicitaires, de graphiques et de vidéos.
- Immédiatement, deux facteurs importants parlent en faveur des microservices. Le premier est la capacité de sortir des pièces individuelles vers le cloud et, par conséquent, une évolutivité colossale. La seconde est la possibilité de créer un service distinct dans une autre langue. Quels autres avantages du passage aux microservices voyez-vous? Eh bien, des inconvénients, bien sûr, je veux aussi entendre.Si nous parlons de la composante technologique, les avantages, en plus de ce qui précède, incluent la possibilité d'utiliser une autre pile de technologies. Et s'il ne nous convient pas, nous en choisirons un autre. Les nouvelles technologies contournent les problèmes des anciennes solutions. L'architecture de microservice apporte également stabilité et indépendance: la dégradation d'un service ne doit pas conduire à la dégradation complète de l'ensemble du système. La composabilité des services permet de réutiliser les fonctionnalités des services dans d'autres architectures de microservices. Du point de vue de la composante organisationnelle, la division en services permet de répartir le développement au sein d'équipes réparties ou d'une grande équipe.
Les principaux inconvénients de l'architecture de microservices: elle est beaucoup plus compliquée et sa mise en œuvre est plus coûteuse.
Vous devez également être prêt à prendre en charge les contrats de service, sélectionner le bon protocole d'accès à distance, résoudre les problèmes d'interaction interservices sécurisés, les pannes possibles, ainsi que dédupliquer et gérer les transactions distribuées.
En général, dans le domaine public, vous pouvez trouver beaucoup d'informations et de documents sur la façon de travailler avec. Mais en fait, tout dépend de la tâche. Dans ma pratique, les avantages ont toujours été plus importants que les inconvénients.
Il vaut toujours la peine de rappeler les mots de Sam Newman: moins le service est important, plus tous les avantages et inconvénients de l'architecture de microservice se manifestent.
- Vous avez des rapports intéressants sur les microservices. Déploiement de microservices et approche de déploiement continu dans l'architecture de microservices . Sur l'une des diapositives de la première, il y a des modèles de déploiement, et dans le rapport, vous dites que pour vous, l'approche tendance est la distribution via des conteneurs. Pendant ce temps, rien n'a changé? Un tas de Docker + Kubernetes n'a pas perdu de sa pertinence?Nous transférons de plus en plus de services à ce bundle. Je pense que nous avons choisi la bonne direction et, pour le moment, nous prévoyons d'y adhérer. Si quelque chose change, je vous en parlerai dans un nouveau rapport ou une nouvelle interview.
- Quelle est la fluidité du déploiement et du transfert continus de microservices vers prod?Tout dépend de la façon de construire le processus. Au début, il semble que tout soit simple. Les services sont indépendants, déployés séparément. Une faible cohérence est assurée par les différentes approches de la gestion de l'évolution du contrat. Et ici, vous devez choisir. Par exemple, vous pouvez implémenter la gestion des versions d'un contrat ou ajouter un service pour déconnecter un contrat (découplage de contrat).
Si dans une architecture de microservices en développement actif, il y a 10 services ou plus à la fois et chacun a son propre versioning, alors il y a un problème de cohérence de version. Il faut essayer de ne pas se confondre dans la compatibilité des services des différentes versions.
Le déploiement continu signifie que nous pouvons livrer l'application à tout moment dans n'importe quel environnement.
Une application dans l'architecture de microservices est une collection de services. Donc, à tout moment, nous devons connaître une combinaison stable de versions de service. Et ailleurs, nous devons avoir un ensemble d'adresses de domaine et d'autres paramètres spécifiques aux différents environnements pour configurer les services et les relier les uns aux autres.
Tout cela doit être stocké quelque part, pour corriger les changements à plusieurs endroits (les microservices sont indépendants après tout) et pour ne pas se confondre.
Le déploiement continu signifie la possibilité de revenir à n'importe quelle version à tout moment. Par conséquent, il se peut que vous deviez annuler plusieurs services à la fois et vous devrez observer l'ordre inverse correct du déploiement des services.
Dans un de mes rapports, je parle de notre approche de l'évolution des contrats, comment ils ont résolu le problème de cohérence des versions et comment ils ont construit le processus de déploiement dans l'architecture de micro-services de plus de dix services. Un déploiement continu peut ne pas être sans problème, mais tout est résoluble.
- Quel pourrait être l'ensemble initial d'outils pour un déploiement continu de microservices? Quelles options recommanderiez-vous d'utiliser pour travailler avec des microservices?Le déploiement continu est une séquence de pipelines, y compris l'intégration continue, les tests d'intégration et la fourniture de services à l'environnement d'orchestration. Les outils de séquençage d'étapes les plus populaires sont
Jenkins 2 Pipelines ,
TeamCity Build Chains ,
Bitbucket Pipelines et
GitLab CI Pipelines . Vous devez d'abord automatiser l'intégration continue (CI). Nous avons besoin d'un serveur CI distant pour créer et exécuter des tests sur cet assemblage.
Les outils listés proposent leurs solutions. Nous utilisons GitLab CI, et GitLab Runners agissent en tant que tels serveurs. L'artefact de génération est l'image
Docker . Dans le cadre des tests d'intégration, vous pouvez effectuer des tests de charge et capacitifs à l'aide de
Gatling , en particulier, pour déterminer les ressources dont il a besoin (processeur et mémoire) pour fonctionner dans un environnement d'orchestration (par exemple,
Kubernetes ).
Helm est largement utilisé pour le déploiement, il vous permet de décrire l'architecture de microservice pour différents environnements. Dans notre entreprise, nous n'utilisons pas Helm. Nous avons notre propre outil de déploiement, qui a été créé lorsque Helm était dans la version Classic et ne supportait pas différents environnements. Ces deux outils ont des qualités utiles similaires, mais la mise en œuvre et la distribution sont différentes. Et notre propre outil nous permet d'apporter des améliorations et de tout adapter à notre infrastructure.
- Quelles technologies sont optimales pour les petites et moyennes entreprises qui souhaitent mettre en œuvre des microservices? Est-ce un plaisir trop cher pour eux?De plus en plus, je rencontre des confirmations selon lesquelles les petites et moyennes entreprises ne sont pas appropriées pour élever leur propre environnement d'orchestration (par exemple,
Kubernetes ,
Docker Swarm ou
Apache Mesos ). . (
Google Cloud Platform ,
Amazon Web Services ,
Microsoft Azure Oracle Cloud ) .
GitLab GitLab CI. . GitLab Helm . Helm . Helm , , , .
, , , open source, .
Spinnaker Heroku — , , .
— , , , . . ?, . , , .
( ) . .
. . , (package). .
( ) Docker-, Git. , . ,
. , .
, . : API. . : . , API. , API , — . , API, .
. , ; API, ; , , .
, , . , ?— - .
, API, , . . .
, , . , , . , , .
— , . 2. , ? ?. .
Mesosphere ,
OpenShift PaaS IaaS . Deis
,
Deis . open source
Heroku , Heroku Buildpack', Dockerfile' Docker-. . make Deis. .
Deis2 . Deis, Kubernetes.
Infrastructure & Operations , , Kubernetes Deis2. , , Deis2, , — Kubernetes. . Deis2 : , pod pod' namespace. Infrastructure & Operations. Kubernetes . Deis2 Kubernetes. Deis2 Kubernetes.
— , , , ? ?Helm. , . Helm .
Helm , — : , .
Helm chart' chart, , .
2 , 10 . ( backing : Postgres, Kafka, Zookeeper, Ceph). - , yaml- , IDE, . , . Python, Python . , . , . , . , , . . , , , ( ) . , , Helm, Kubernetes - , yaml.
API
API Gateway . , — .
, : . , , .
DevOps , . DevOpsConf Russia .
DevOpsConf Russia 1 2 RootConf, , , , . DevOps , .
DevOps , , – . 15 .