Monolith-Sägeschichten sehen oft gleich aus. Das Team hatte einen kräftigen ungeschickten Monolithen, sie beschlossen, ihn in eine Streuung von regulären und intelligenten Mikrodiensten zu schneiden, alles wurde cool. Die Geschichten unterscheiden sich nur in dem Grad des Grauens "vor", der Freude "nach" und einer Reihe von sekundären Merkmalen.
Bei RBK.money haben wir auch Microservices. Aber wir sind etwas anders zu ihnen gekommen als die meisten anderen. Alles war noch schlimmer für uns als der Monolith - am Anfang war alles nur schlecht.
Unter der Katze darüber, wie wir tatsächlich Microservices aufgebaut haben, warum OpenSource nicht nur im Prinzip großartig ist, sondern auch als Motivationskomponente für das Schreiben von gutem Code fungiert.
Also war alles schlecht. So sehr, dass es keinen Sinn machte, es zu reparieren, aber es machte Sinn, zuzustimmen, sich nie an diesen Horror zu erinnern und einfach alles von Grund auf neu zu schreiben. Und sofort auf Microservices. In der allerersten Entwicklungsphase haben wir es uns sofort zur Regel gemacht, ständig daran zu denken, dass wir eines Tages all dieses Gute oder einen Teil davon wieder öffnen wollen. Schließlich wird alles in der Geschichte der Commits gespeichert, einschließlich der Spitznamen der Entwickler. Wir setzen uns einfach hin und versuchen sofort, alles zu schreiben, damit wir uns später nicht für unseren Code vor der Community schämen. Schließlich möchte niemand für seinen Code oder die Architektur des Projekts erröten, so lala Geschichte.
Schnell gegen gut
In einer idealen Welt möchten Sie immer schnell und gut Code schreiben. Nun, es ist wie "Besser reich und gesund zu sein als arm und krank." Daher sind Microservices ein hervorragender Ausweg aus der Situation geworden. Das Schreiben von Code basierte auf Geschäftsaufgaben. Angenommen, ein Unternehmen benötigt Funktionen, die bei Zahlungen Gelder auf Kontrahentenkonten berücksichtigen. Diese Funktionalität wird zu einem Microservice mit dem Codenamen Accounter, der sich mit Buchhaltungstools befasst. Mit anderen Microservices die gleiche Geschichte.
Die Hauptsache dabei war, sicherzustellen, dass jede Geschäftsfunktionalität so konkretisiert wurde, dass eine Person sie schreiben konnte. Es hängt stark davon ab, welche Aufgaben selbst zur Arbeit kommen und wie der technische Direktor oder das Projekt dies auf das Team überträgt. Wir haben es geschafft, es gibt sofort ein paar gute signifikante Vorteile.
Erstens bietet es eine große Parallelisierung der Entwicklung. Zu Beginn hatten wir ungefähr 10 Leute und es gelang uns, gleichzeitig eine große Menge Code zu schreiben (und gut zu schreiben). Zweitens haben Sie die Möglichkeit, sich vollständig zu drehen. Das ist aber schon etwas wichtiger als es auf den ersten Blick scheint.
Sehr oft fängt ein Mensch an zu scheißen, nicht weil er diesen Job für dich bekommen hat, sondern weil seine Augen kitschig und seine Augen langweilig und gelangweilt werden. Wenn eine Person ständig auf demselben Microservice sitzt, kann sie mit der Generierung von Govnokod beginnen. Und das ist weniger eine Frage der Professionalität als der Zeit. Nach 7-8 Monaten werden die Leute es leid sein, denselben Microservice zu unterstützen, sie werden sich umschauen - und da ist das Leben, der Frühling kam nach dem Winter, meine Kollegen haben eine Art Bewegung, wieder kam ein neues iPhone heraus und Sie sitzen alle auf demselben Microservice . Auf diese Weise wird ein Monolith mit einem einzigen Fehlerpunkt in Form dieser müden Person mit Taschen unter den Augen geboren.
Oder im Allgemeinen beginnt ein Mensch zu denken, dass alles nur auf ihm liegt und auf ihm ruht. Sie wird versuchen, sich unentbehrlich zu machen, indem sie ihre Arbeit mit einer Menge „geheimem Wissen“ und seltsamen Verfahren umgibt. Zu Beginn meiner Reise hatte ich Situationen, in denen das Erbe so wild war, dass es ohne dieses Wissen unmöglich war, es herauszufinden. Zum Beispiel mussten Sie einen Dienst starten. Wie Sie sich normalerweise vorstellen:
- Starten Sie den Dienst.
Wie war:
- Wechseln Sie zur Windows-Registrierung.
- Suchen Sie dort einen bestimmten Schlüssel.
- Ändern Sie es auf 1.
- Starten Sie den Dienst.
- Schlüsselwert auf 0 zurücksetzen.
Dies ist ein klassisches Beispiel für Komplexität aus Gründen der Komplexität und "Hier funktioniert nichts ohne mich." In der Tat, ohne dies funktioniert alles. Nur schneller und besser. Sie können dies durch Rotation beseitigen - idealerweise, wenn eine Person einen Microservice für etwa ein paar Sprints schreibt und dann eine andere Aufgabe erledigt. Aus dem gleichen Grund unterstützen wir einen ständigen Wissensaustausch in einem Team.
Code aus dem Protokoll
Wenn Sie einen TK aus dem Geschäft nehmen, ihn gut in einen menschlichen übersetzen, die Schalen abschütteln und verdampfen - Sie erhalten ein Protokoll, eine Sprache, mit der die Maschine kommuniziert. Das heißt, wir übernehmen eine Geschäftsaufgabe, verstehen selbst, was genau und wie wir es tun werden, und verwandeln sie in eine Spezifikation für Sparsamkeit oder Prahlerei (Microservices im Inneren kommunizieren über Sparsamkeit). Der erste Schritt besteht darin, alles im Detail zu beschreiben: Was wird der Mikroservice tun, welche Arten von Daten wird er empfangen, was wird er beantworten, welche Strukturen werden sein und so weiter. Dieses Protokoll durchläuft die erste Überprüfung derjenigen, die eine klare Vorstellung davon haben, wie alles funktioniert (De-facto-Architekten). Es funktioniert wie ein Grobfilter, durch den selbst auf Konzeptebene kein offener Bullshit geht.
Sobald das Protokoll angezeigt wird, können Sie sich hinsetzen, um Code zu schreiben. Und wenn das Protokoll von universellen Personen vollständig selbst überarbeitet wird, befindet sich der Code selbst in einem Team von bestimmten Personen. Wir schreiben in drei Sprachen - JS, Java, Erlang. Die Hauptsache ist, niemanden mit einer Überprüfung oder dem Schreiben von Code zu überstürzen. Ja, Geschäfte müssen immer und überall schnell und cool sein. Aber ich beeile mich selten als technischer Direktor, weil ich verstehe, was sie gut machen wollen. Das Ergebnis ist eine Situation, die mich im Laufe der Zeit oft von Geschäftskunden ermutigt. Aber praktisch müssen Sie nicht für Qualität erröten.
Wir haben uns nur einmal beeilt, als der Jackpot überlagert wurde - ein Superkunde und äußerst dringende Fristen haben gerade unsere Brieftasche erstellt. Dann haben wir ja die Ärmel gesenkt und alles schneller gemacht als geplant (und schlimmer als wir wollten, ja). Im Idealfall wurde alles als ein Bündel ordentlicher Mikrodienste konzipiert. Es stellte sich heraus, ein solches Stück Monolith. Die Vorteile der Situation sind, dass wir uns erneut bewusst gemacht haben, dass es nicht nötig ist, sich zu beeilen. Und der Dienst selbst wird bereits langsam in separate Microservices gezogen, wie sie wollten.
Es gibt 50 Microservices in RBK Money, die von ungefähr 20 Personen geschrieben wurden. Sparsamkeit ist überall im Inneren, für Entwickler ist es ein ziemlich kompliziertes Protokoll, das Entwerten ist schwierig, die Dokumentation ist auch schwer zu schreiben. Und wenn ich Sparsamkeit in seiner reinsten Form herauslassen würde, würden sie mich schlechte Worte nennen. Aus diesem Grund haben wir uns nichts ausgedacht - Rest JSON, einfach und intuitiv, plus OpenAPI, sticht unbeschwert heraus. Um diese Anfragen von außen annehmen zu können, müssen sie validiert, autorisiert und dann von anderen Microservices auf der Plattform gestartet werden. Und wir haben das Ganze auch als unabhängigen Microservice geschrieben, der:
- akzeptiert Beute von außen;
- validiert das Schema;
- autorisiert den Benutzer;
- macht all dies zu einer Sparsamkeitsanfrage;
- Natürlich schreibt er Protokolle.
Ist es bequem, ein Zahlungssystem für Microservices zu schreiben? Natürlich - hier haben Sie eine Parallelisierung der Arbeit, die Wahrung des Interesses der Mitarbeiter und das Fehlen einer einzigen Fehlerquelle. Ein einzelner Microservice ist ausgefallen oder plötzlich ist die Person, die es gestern getan hat, gegangen - kein Problem, Sie können schnell etwas reparieren und während des neuen Sprints eine neue Person auf den Pilotensitz setzen.
Es gibt jedoch die Meinung, dass eine Person, die einen bestimmten Microservice lange Zeit sitzt und sorgfältig schneidet, dies definitiv gut macht. Da wir darüber gesprochen haben, schreiben Sie bitte in die Kommentare, welcher Ansatz näher bei Ihnen ist. Und vor allem - warum.