Les histoires de sciage de monolithes se ressemblent souvent. L'équipe avait un monolithe lourd et maladroit, ils ont décidé de le couper en une dispersion de microservices réguliers et intelligents, tout est devenu cool. Les histoires ne diffèrent que par le degré d'horreur «avant», la joie «après» et un certain nombre de caractéristiques secondaires.
Chez RBK.money, nous avons également des microservices. Mais nous sommes venus à eux un peu différemment que la plupart. Tout était encore pire pour nous que le monolithe - au début, tout était simplement mauvais.
Sous le chat sur la façon dont nous avons, en fait, construit des microservices, pourquoi OpenSource est non seulement excellent en principe, mais fonctionne également comme un élément de motivation pour écrire un bon code.
Donc, tout allait mal. Tant et si bien que cela n'avait aucun sens de le réparer, mais il était logique de ne jamais se souvenir de cette horreur et de tout écrire à partir de zéro. Et immédiatement sur les microservices. Au tout premier stade de développement, nous avons immédiatement fait une règle de garder constamment à l'esprit le fait qu'un jour nous voudrons resensoriser tout ce bien ou une partie de celui-ci. Après tout, tout est enregistré dans l'historique des commits, y compris les surnoms des développeurs, nous nous asseyons donc et essayons immédiatement de tout écrire pour que plus tard nous n'ayons pas honte de notre code devant la communauté. Après tout, personne ne veut rougir de son code ou de l'architecture du projet, de l'histoire.
Rapide vs bon
Dans un monde idéal, vous voulez toujours écrire du code rapidement et bien l'écrire. Eh bien, c'est comme "Mieux vaut être riche et en bonne santé que pauvre et malade." Par conséquent, les microservices sont devenus un excellent moyen de sortir de la situation. Le processus d'écriture du code a été construit sur des tâches métier. Supposons qu'une entreprise ait besoin de fonctionnalités qui prendront en compte les fonds dans les comptes de contrepartie lors des paiements. Cette fonctionnalité se transforme en un microservice, nom de code Accounter, qui est engagé dans des outils de comptabilité. Avec d'autres microservices, la même histoire.
L'essentiel ici était de s'assurer que chaque fonctionnalité de l'entreprise était tellement concrétisée qu'une seule personne pouvait l'écrire. Cela dépend grandement des tâches elles-mêmes à venir au travail et de la façon dont le directeur technique ou le projet traduit cela à l'équipe. Nous avons réussi à le faire, cela donne immédiatement quelques bons avantages significatifs.
Premièrement, il offre une large parallélisation du développement. Au début, nous avions environ 10 personnes, et nous avons réussi à écrire une grande quantité de code en même temps (et à bien écrire). Deuxièmement, cela vous donne la possibilité de faire une rotation complète. Mais c'est déjà un peu plus important qu'il n'y paraît à première vue.
Très souvent, une personne commence à chier, non pas parce qu'elle a obtenu ce travail pour vous, mais parce que ses yeux deviennent ringards et ses yeux deviennent ternes et ennuyés. Si une personne est constamment assise sur le même microservice, elle peut commencer à générer du govnokod. Et ce n'est pas tant une question de professionnalisme qu'une question de temps. Après 7 à 8 mois, les gens seront fatigués de soutenir le même microservice, ils regarderont autour - et là la vie, le printemps est venu après l'hiver, une sorte de mouvement est venu de collègues, encore un nouvel iPhone est sorti, et vous êtes tous assis sur le même microservice . C'est ainsi qu'est né un monolithe avec un seul point de défaillance sous la forme de cette personne fatiguée avec des poches sous les yeux.
Ou, en général, une personne commence à penser que tout n'est que sur elle et repose sur lui. Elle tentera de se rendre indispensable en entourant son travail d'un tas de «connaissances secrètes» et de procédures étranges. Au début de mon voyage, j'ai eu des situations où l'héritage était si sauvage qu'il était impossible de le comprendre sans cette connaissance même. Par exemple, vous avez dû démarrer un service. Comme vous l'imaginez habituellement:
- Démarrez le service.
Comment était:
- Accédez au registre Windows.
- Trouvez-y une clé spécifique.
- Remplacez-le par 1.
- Démarrez le service.
- Réinitialisez la valeur de la clé à 0.
Ceci est un exemple classique de complexité dans un souci de complexité et «Rien ne fonctionne ici sans moi». En fait, sans cela, tout fonctionne. Seulement plus vite et mieux. Vous pouvez vous en débarrasser par rotation - idéalement lorsqu'une personne écrit un microservice pendant environ deux sprints, puis part pour effectuer une autre tâche. De même, nous soutenons un échange constant de connaissances en équipe.
Code du protocole
Si vous prenez des savoirs traditionnels dans les affaires, traduisez-les bien en humains, secouez les coques et évaporez-vous - vous obtenez un protocole, un langage avec lequel la machine communiquera. Autrement dit, nous prenons une tâche commerciale, comprenons par nous-mêmes exactement ce que nous allons faire et comment nous allons le faire, et le transformons en une spécification pour l'épargne ou le swagger (les microservices à l'intérieur communiquent via l'épargne). La première étape consiste à tout décrire en détail: ce que fera le microservice, quels types de données il recevra, à quoi il répondra, quelles seront les structures, etc. Ce protocole passe par le premier examen de ceux qui ont une idée claire du fonctionnement de tout (architectes de facto). Cela fonctionne comme un filtre grossier à travers lequel certaines conneries franches ne passeront pas, même au niveau du concept.
Dès que le protocole apparaît, vous pouvez vous asseoir pour écrire du code. Et si le protocole est complètement auto-révisé par des personnes universelles, alors le code lui-même est dans une équipe de personnes spécifiques. Nous écrivons en trois langues - JS, Java, Erlang. L'essentiel est de ne précipiter personne avec un code de révision ou d'écriture. Oui, les affaires doivent toujours et partout être rapides et cool. Mais je précipite rarement les gars en tant que directeur technique, car je comprends ce qu'ils veulent bien faire. Le résultat est une situation qui m'encourage souvent au fil du temps. Mais n'ont pratiquement pas à rougir de qualité.
Nous nous sommes dépêchés une seule fois lorsque le jackpot a été superposé - un super-client et des délais extrêmement urgents, vient de créer notre portefeuille. Alors oui, nous avons baissé nos manches et fait tout plus vite que prévu (et pire que ce que nous voulions, oui). Idéalement, tout a été conçu comme un tas de microservices soignés. Il s'est avéré un tel morceau de monolithe. Les avantages de la situation sont que nous avons une fois de plus réalisé par nous-mêmes qu'il n'était pas nécessaire de se précipiter. Et le service lui-même est déjà lentement tiré dans des microservices séparés, comme ils le voulaient.
Il y a 50 microservices dans RBK Money, ils sont écrits par environ 20 personnes. L'épargne est partout à l'intérieur, pour les développeurs, c'est un protocole assez compliqué, la dégradation est difficile, la documentation est également difficile à écrire. Et si je laissais échapper sa forme la plus pure, ils me traiteraient de mauvais mots. Par conséquent, nous n'avons rien trouvé - le reste JSON, simple et intuitif, plus OpenAPI, sort avec désinvolture. Pour pouvoir accepter ces demandes de l'extérieur, elles doivent être validées, autorisées, puis lancées sur la plateforme par d'autres microservices. Et nous avons également écrit tout cela comme un microservice indépendant, qui:
- accepte le butin extérieur;
- valide le schéma;
- autorise l'utilisateur;
- transforme tout cela en une demande d'épargne;
- Eh bien, il écrit des journaux, bien sûr.
Est-il pratique d'écrire un système de paiement sur des microservices? Bien sûr, vous avez ici la parallélisation du travail, le maintien de l'intérêt des employés et l'absence d'un point de défaillance unique. Un microservice est tombé en panne ou soudainement la personne qui l'a fait hier est partie - pas de problème, vous pouvez rapidement réparer quelque chose et mettre une nouvelle personne sur le siège du pilote pendant le nouveau sprint.
Mais il y a une opinion que si une personne s'assoit et coupe soigneusement un microservice particulier pendant longtemps, alors elle le fait certainement bien. Depuis que nous avons commencé à en parler, veuillez écrire dans les commentaires quelle approche est la plus proche de vous. Et le plus important - pourquoi.