Ein Artikel über eine schlechte Entscheidung, die bei der Migration auf Microservices häufig vorkommt. Während Microsoft und andere Unternehmen in ihren Tutorials erwägen, Entity Serivces zu erstellen, gibt es allen Grund, dies als Anti-Pattern zu betrachten. Als Nächstes werden wir darüber sprechen, was ein Entity Service ist und welche Eigenschaften er für das gesamte Endsystem hat.
Das Original befindet sich unter dem Link
Entity Service - was ist das? Und wie kommt die Idee, es zu schaffen?
Jeder hat gehört, dass die Aufteilung eines Monolithen in Microservices viele Vorteile bietet. Erhöht die Flexibilität, Einfachheit, Skalierbarkeit, Fehlertoleranz usw. Man kann jedoch auch Kritik am Microservice-Ansatz für die Komplexität der Gewährleistung der Datenkonsistenz hören, da es unmöglich ist, eine Transaktion zwischen mehreren Microservices zu teilen - sie kommunizieren über http. Und das System selbst als Ganzes wird komplex - es ist viel einfacher, die http-Aufrufe zu entfernen und alles wieder zu einem Monolithen mit normalen Aufrufen aus dem Code zu kombinieren.
Dies deutet darauf hin, dass es nicht ausreicht, den Monolithen einfach in mehrere Bestandteile zu zerlegen. Du musst es richtig machen. Ein typischer Monolith arbeitet mit einer Datenbank und enthält mehrere Instanzen, um die Leistung und Fehlertoleranz zu verbessern.
Nehmen wir an, unser Monolith ist ein Online-Shop. Es enthält eine Liste von Produkten, Sie können sich als Benutzer registrieren, eine Bestellung aufgeben, dafür bezahlen und die Lieferung arrangieren. Eine Idee scheint den Monolithen in Mikrodienste zu schneiden. Es gibt bereits Entitäten im Monolith-Code - Bestellung, Produkt, Benutzer, Lieferung usw. Es ist am einfachsten, sie als separate Mikrodienste zu isolieren. Es reicht aus, die Aufrufe im Code durch Aufrufe über http zu ersetzen, den Entitätscode in einen neuen Dienst zu kopieren, eine API-Fassade zu erstellen usw. Als Ergebnis erhalten wir einen Service für Bestellungen, Benutzer, Waren, Lieferung usw.
In der Abbildung blieben die Auftragsregistrierung und die Lieferplanung innerhalb der Fassade, können jedoch in separate Services verschoben werden - in unserem Beispiel ist dies nicht das Wichtigste.
- Entity Service. , CRUD .
, ( ) entity . . .
:
. , ( ). , .
. - , . , . , - , - .
. , . Jaeger Jaeger: open source, end-to-end distributed tracing.
. , .
Microsoft : Creating a simple data-driven CRUD microservice
Entity Service?
entity service . ( ). :
;
, ;
, . , - ;
( , );
;
.
Entity Service :
API , . , - . , . . , .
entity service. , . , -, - :
- . - . - . , . , . . , , , . . .
. . , , . , , - - . . .
, , . - (immutability). - , . :
.
-.
-.
, .. .
(eventual consistency).
. , .
:
.
.
- . . , .
Eine weitere Option, die sinnvoll ist, ist die Zuordnung von Mikrodiensten nach Subdomänen. Muster: Nach Subdomain zerlegen Es gibt mehr Optionen für die Aufteilung in Microservices gemäß dem obigen Link, aber es ist sinnvoll, die beiden oben genannten zuerst zu betrachten.
Beide Optionen passen gut zusammen - Sie können sie leicht kombinieren. Die Hauptsache ist, alle Nachteile von Entity Service zu vermeiden .
Haben Sie dieses Anti-Muster jemals in Ihrer Praxis erlebt? Wie würden Sie Refactoring-Systeme vorschlagen, bei denen es bereits existiert? Stellen Sie Fragen, drücken Sie Ihre Gedanken in den Kommentaren aus. Ihre Meinung ist interessant!