Die Idee von Microservices ist nicht neu. Ältere Menschen haben in ihrer Blütezeit möglicherweise mit
EJB gearbeitet . Was ist das?
Samuel Colt verwendete bereits einen modularen Ansatz, um seine Revolver herzustellen. Die standardmäßigen, präzisionsgefertigten Teile seiner Pistolen waren austauschbar, was sowohl die Produktion als auch die Wartung erheblich vereinfachte. Warum sollte die Infrastruktur nicht modular aufgebaut sein?
Es gibt keine grundsätzlichen Einwände dagegen, und die Idee selbst liegt an der Oberfläche. Das Thema Microservices ist jedoch in jüngster Zeit populär geworden. Und dafür gibt es einen Grund.
Die Instandhaltung der Infrastruktur blieb lange Zeit eine mühsame und eher spezialisierte Aufgabe. Nur erfahrene Administratoren können einen Cache oder eine Warteschlange in der Infrastruktur bereitstellen. Dass jeder Teil der Anwendung seine eigene Infrastruktur hatte und es keine Frage gab - wer wird diesen ganzen Zoo bedienen?!
Virtualisierungstechnologie, Container und Tools zur Verwaltung der Infrastrukturkonfiguration haben jedoch einen langen Weg zurückgelegt. Die Bereitstellung einer unabhängigen Infrastruktur für einen separaten Anwendungsdienst ist jetzt noch einfacher und billiger als das Pushen aller Dienste in einer gemeinsamen Infrastruktur. Fortschritt!
Die Anwendung ist bequem in unabhängige Teile unterteilt, auch aus organisatorischen Gründen. In diesem Fall wird die Interaktion zwischen den Teilen über die eine oder andere API ausgeführt. Das Endergebnis ist Service. Ab hier beginnt der Prozess der Aufteilung der Anwendung in Makrodienste, Metroservices, Microservices, Nanoservices, Picoservices und einzeilige Lambda-Funktionen in Amazon.
Es scheint, dass was hier schief gehen könnte?
Leider ist die Aufteilung der Anwendung in Teile nicht kostenlos. Erstens steigen die Kosten für die Unterstützung der API innerhalb der Infrastruktur.
Angenommen, eine Anwendung muss mit Dateien arbeiten. Eine typische Aufgabe. Ein Microservice, der die Dateispeicherinfrastruktur implementiert, wird zugewiesen und bietet zwei Vorgänge: Lesen und Schreiben. Und ohne wesentliche Änderungen an der API kann ein solcher Dienst von einer Schnittstelle zu einem Ordner auf einer lokalen Festplatte zu einer geografisch verteilten Rechenzentrumsinfrastruktur werden. Das perfekte Szenario.
Was aber, wenn die Anwendung so in Dienste unterteilt ist, dass die ungeraden Zeilen der Geschäftslogik in einem Dienst und die geraden Zeilen in einem anderen enden? Eine solche Trennung verlangsamt nicht nur die Anwendung erheblich, da jetzt anstelle des direkten Aufrufs der Methode eine Netzwerkkommunikation stattfindet, sodass sich die API zwischen den Diensten so oft ändert, dass sie in die lange Version für die API-Versionsnummer passt.
Das ist natürlich alles eine Übertreibung. Es gibt jedoch ein klares Bild der möglichen negativen Folgen. Die Entwicklung einer auf diese Weise erstellten Anwendung ist äußerst teuer.
Vor der Aufteilung der Anwendung in Teile sollten zwei Aspekte berücksichtigt werden.
Erster. Wie oft interagieren diese Komponenten in einem einzigen Vorgang? Ist es möglich, dass Sie für jede Aktion Hunderte, wenn nicht Tausende von Netzwerkanrufen ausführen müssen? Dies kann die Anwendungsleistung beeinträchtigen.
Zweiter. Wie oft wechselt die API zwischen den Komponenten? Wenn die Git-Story zeigt, dass sich die API jeden Tag ändert, sind die Kosten für den Support wahrscheinlich unerschwinglich. Dies kann die Entwicklungsproduktivität beeinträchtigen.
Durch die korrekte Aufteilung der Anwendung in Dienste können Sie jedoch erhebliche Vorteile erzielen. Es ist nur so, dass diese Dienste nicht mikro sein müssen.