Meine Meinung über Microservice-Architektur
Microservice ist ein Buzzword in der aktuellen Welt der Softwareentwicklung. Jeder möchte sagen, dass er Microservices entwickelt oder sie unbedingt einführen möchte.
Gründe für Microservices
Microservice – Bringt Agilität in die Architektur
Laut Definition handelt es sich um einen Architekturstil, bei dem das System in kleine autonome Prozesse aufgeteilt wird, die mit einer von der Programmiersprache/Plattform unabhängigen API gekoppelt sind. Es gibt jedoch eine ähnliche Art von Architektur in SOA (Service Oriented Architecture), die ebenfalls eine Art von stabilen unabhängigen APIs kommuniziert. Aber worin besteht der Hauptunterschied oder Vorteil?
Häufige Veröffentlichungen
Ja, die Möglichkeit, häufiger neue Versionen zu veröffentlichen, ist der Schlüssel. Weitere Vorteile sind, dass das System sauber ist und aus kleinen Diensten besteht, die ihre Aufgabe gut erfüllen, dass das System leicht mit verschiedenen Programmiersprachen erstellt werden kann und dass nur die benötigten Komponenten/Dienste skaliert werden können, anstatt das ganze System.
Als agil eingeführt wurde, wurden auch viele entsprechende Vorteile angepriesen. Die Arbeit mit Code statt mit Dokumentation, die Zusammenarbeit mit Kunden und die Reaktion auf Veränderungen waren nur einige der Vorteile, die genannt wurden. Aber was ist der wahre Schlüssel? Der Schlüssel waren 2-3 Wochen dauernde Sprints, die etwas Konkretes liefern. Die meisten Dienstleistungsunternehmen setzen agil nur deshalb ein, weil es in 2-3 Wochen eine neue Version geben wird und die Entwickler nachts durcharbeiten und ihre Wochenenden opfern müssen. Im Wasserfallmodell würde diese Arbeit vielleicht nur einmal in sechs Monaten anfallen.
An den meisten Arbeitsplätzen wurde neben dem Konzept des Sprints der Rest wie die Pflege von Backlogs und die Vermeidung von Dokumentation über den Code nicht umgesetzt. Es gibt keine Veröffentlichung, die nicht von einer Dokumentation begleitet wird, die belegt, dass der Code funktioniert.
Was ist in Microservice vorhanden? Unabhängige Teams, die die Verantwortung für kleine Dienste übernehmen. Die Größe des Dienstes hängt von der Größe des Teams ab, das ihn täglich, ein- oder zweimal täglich oder stündlich bereitstellt.
In den meisten Unternehmen wird bei der Einführung von Microservice der Schwerpunkt auf TDD gelegt, was jedoch in der Eile der Veröffentlichung wieder verworfen werden kann.
Unterm Strich? Die Architektur wird agil sein. Ein Microservice kann zu jedem Zeitpunkt der Entwicklungsphase eingeführt werden. Die Server werden mit Diensten überflutet. Die Komplexität des Systems wird Teil der Orchestrierung von Microservices sein.
Microservice entwerfen
Da sich die Softwareentwicklung immer noch weiterentwickelt, wird nur der Stärkste überleben. Derzeit scheint der Microservice der Stärkste zu sein. Das bedeutet, dass die Microservices-Architektur zu einer alltäglichen Realität werden könnte und die meisten unserer Anwendungen auf Microservices basieren könnten.
Merkmale von Microservices
Sehen wir uns einmal an, was die Merkmale von Microservices sind.
Unabhängige Freigabe
Wenn ein Dienst unabhängig von den anderen Teilen des Systems freigegeben werden kann, kann er als Microservice betrachtet werden. Manchmal haben die neuen API-Methoden, die wir im Microservice veröffentlicht haben, möglicherweise keine Verbraucherkomponenten, da der Verbraucherteil erst nach der Veröffentlichung des Dienstes freigegeben werden kann.
Das Konzept der Unabhängigkeit ist sehr wichtig, wenn wir zu oft neue Versionen veröffentlichen wollen. Wenn es von anderen Komponenten abhängt, können wir nicht schnell und oft veröffentlichen.
Unabhängiger Datenspeicher
Wenn wir einen Dienst unabhängig veröffentlichen wollen, sollte auch sein Datenspeicher unabhängig sein. Wenn es eine Datenbanktabelle gibt und eine Komponente das Schema aktualisiert und dadurch andere Komponenten ausfallen, können wir diese Komponente nicht als Microservice betrachten. Kurz gesagt, ein Microservice sollte der einzige sein, der seinen Datenspeicher besitzt. Wenn andere Komponenten im System etwas in den Speicher schreiben möchten, sollten sie den Dienst aufrufen.
Unabhängiges Entwicklungsteam
Wenn wir unabhängig sein wollen, sollte dies wahrscheinlich von einem unabhängigen Team getan werden. Das hat nichts mit der Technologie zu tun. Eine Organisationsstruktur muss möglicherweise überarbeitet werden und das ist schwierig.
Auch die Geschwindigkeit der Bereitstellung ist fehleranfällig und es ist ratsam, ein Entwicklungsteam zu haben, das den Service unterstützt. Wenn das Team nach jeder Veröffentlichung ausgetauscht wird oder die Mitglieder häufig wechseln, wird es den Dienst nicht mit dem nötigen Verantwortungsbewusstsein unterstützen, und die Microservice-Architektur könnte ein Fehlschlag werden.
Unabhängige Frameworks/Plattformen/Sprachen
Obwohl dies nicht zwingend erforderlich ist, besteht die dringende Notwendigkeit, eine bestimmte Technologie zu verwenden, die sich von der normalen Technologie unterscheidet. Microservice wird empfohlen, sofern es die oben genannten 3 Kriterien erfüllt. Auch wenn wir Microservice-basierte Systeme mit einer einzigen Sprache und Technologie haben können, sollten Sie sich nicht ohne angemessene Bewertung und Planung auf Microservice stürzen. Informieren Sie sich über die folgenden Punkte, bevor Sie sich in die Welt der Microservices stürzen.
Definierte Integrationsrichtlinien zwischen Komponenten. http(s)
Wenn Sie keine definierte Integrationsstrategie für Microservices haben, wird sie scheitern. Die empfohlene Integration erfolgt über das http(s)-Protokoll und hat eine synchrone Interaktion. Im Falle einer asynchronen Integration sollten Sie Message Queuing, Service Bus usw. einsetzen. Vor der Einführung sollten genügend Design-Sitzungen und Vereinbarungen stattfinden.
Vorab-Design der API
Die Systeme/Geschäftsprobleme der realen Welt sind immer komplex. In monolithischen Systemen haben wir die Komplexität in großen Komponenten gehandhabt. Aber im Zeitalter der Microservices sind die einzelnen Komponenten einfach, aber die Interaktion der Dienste ist komplex.
Dies erfordert sorgfältig entwickelte APIs für jeden Microservice. API ist wie die Unterwelt von Mumbai. Sobald wir sie betreten, gibt es kein Zurück mehr. Sobald wir eine API veröffentlichen, wissen wir nicht, wer sie aufrufen wird. Es ist eine kostspielige Angelegenheit, die API zu korrigieren und allen Verbrauchern mitzuteilen, dass sie auf die neue API umgeleitet werden sollen.
Das Deployment ist einfach und automatisiert.
Ein großer Vorteil von Microservice sind die häufigen Releases. Wenn die Installation jedes Mal manuell erfolgt, ist ein Microservice eine schlechte Idee.
Das Deployment sollte immer automatisiert sein. Eine kontinuierliche Integrations- und Bereitstellungspipeline ist unerlässlich.
Starke Automatisierungstests. Bevorzugen Sie eine 100%ige Testabdeckung
Eine 100%ige Testabdeckung ist vorzuziehen, da dann kein Mensch mehr für die tägliche Bereitstellung benötigt wird. Sie richten einfach die CI- und CD-Pipeline zu Beginn ein und das System übernimmt die Bereitstellung automatisch.
Wie sieht es mit dem Testen aus? Erwarten wir von einem manuellen Tester, dass er alle Änderungen testet, bevor wir sie täglich veröffentlichen? Auch das sollte automatisiert werden. Die Entwickler sollten geeignete Testfälle für die API schreiben. Die meisten Unternehmen beschäftigen ein eigenes Team/eine eigene Person für das Testen, in der Annahme, dass ein Entwickler seinen eigenen Code nicht kaputt machen will oder dass er psychologisch gesehen keine Fehler in dem System, das er erstellt, finden kann. Wenn ein Entwickler testet, testet er nur positive oder übliche Szenarien, weil er weiß, wie das System funktioniert. Aber hier in der Microservice-Welt wird es kein separates manuelles Testteam geben. Wie also soll man das Problem angehen?
Einige der Entwickler müssen die Tests schreiben. Wenn das vorhandene Testteam weiß, wie man API-Tests und Integrationstests programmiert. Bitte beachten Sie, dass wir gegen manuelle QA sind und an der automatisierten QA festhalten wollen.
Überwachung und Verwaltung von Diensten
Mit der explosionsartigen Zunahme von Diensten besteht die Möglichkeit, dass jede Klasse/Komponente in Ihrem bestehenden System, wie z.B. Protokollierung oder Caching, zu einem Dienst wird. Einige Dienste werden versioniert sein, andere werden kumulativ/vor Ort aktualisiert. Wir müssen weitere Dienstinstanzen hinzufügen und die Last ausgleichen, wenn die Dienste ausgelastet sind. Einige werden vielleicht gar nicht genutzt. Ein Rechner, auf dem ein Dienst gehostet wird, könnte ausfallen und wir müssen den Dienst ohne oder mit nur minimaler Ausfallzeit verlagern. Wie können wir mit all diesen Szenarien umgehen?
Die Antwort ist eine starke Infrastruktur zur Überwachung und Verwaltung von Diensten. Der einfachste Weg ist das Hosten in der Cloud, wo dies beim Cloud-Anbieter kostenlos ist. Wir müssen keine Infrastrukturverwaltungsanwendung entwickeln, um die Anzahl der Rechner zu erhöhen und den Dienst auf ihnen bereitzustellen. Oder um den Dienst von einem Rechner auf einen anderen zu verschieben usw.
Versionierung, Abhängigkeitsmanagement, Auslaufstrategie
Version 2 des Dienstes A erfordert möglicherweise Version 4 des Dienstes B im System, während Version 1 des Dienstes C Version 3 des Dienstes B erfordert. Das bedeutet, dass Version 3 des Dienstes B nicht außer Dienst gestellt werden kann, bevor Dienst C außer Dienst gestellt ist.
Warum wir einen Dienst stilllegen müssen. Im Laufe der Zeit werden einige Dienste veraltet sein und niemand wird sie mehr aufrufen. Aber er bleibt einfach in der Produktionsumgebung. Es ist die Entscheidung der Beteiligten, einen solchen Dienst einzustellen. Wenn wir planen, solche Dienste einzustellen, sollten die Benutzer benachrichtigt werden, damit keine neuen Dienste die eingestellten Dienste aufrufen.
Ein weiteres interessantes Szenario ist die Frage, ob ein Dienst, sagen wir Dienst X, den Standort eines anderen Dienstes Y kennen sollte. Obwohl es beim Standort viele Dinge zu beachten gibt, nehmen wir hier die Url des Dienstes. Wenn wir uns dafür entscheiden, den Standort von Y in X zu belassen, können wir den Dienst Y nicht auf einen anderen Rechner oder in eine andere Umgebung verschieben. Ein fest kodierter Speicherort wird Probleme verursachen. Angenommen, wir haben mit allen Diensten vor Ort begonnen und beschließen aufgrund der Auslastung, Dienst Y zum Cloud-Dienst X zu verschieben, dann wird Y nicht aufgerufen.
Das liegt daran, dass wir eine Dienstregistrierung benötigen, die alle Dienste und ihre Abhängigkeiten aufzeichnet. Dies kann ein anderer Dienst sein, aber an einem festen Ort.
Wenn Sie Zugang zur Produktion haben
Wenn die Entwicklung für ein Produkt erfolgt, das Ihrem Unternehmen gehört und serverbasiert ist, funktioniert Microservices hervorragend. Wenn das Produkt als Installationsprogramm an Ihre Kunden ausgeliefert wird, wäre es sehr schwierig zu verwalten, da diese möglicherweise noch die Morgenversion installieren, wenn Sie die Abendversion herausgeben.
Wählen Sie also, ob die CI- und CD-Pipeline bis zur Produktion reichen kann. Wir können die anderen Systeme zu Microservice-basierten Systemen umgestalten, aber wir werden nie den Vorteil einer häufigen Veröffentlichung erhalten.
Haftungsausschluss: Ich arbeite in einem Projekt mit über 100 Diensten, obwohl wir offiziell nicht die Microservices-Architektur eingeführt haben. Sie wurde mit dieser Architektur eingeführt und viele Dienste nutzen denselben Datenspeicher. Aufgrund der Datenkopplung geben wir die Dienste nicht unabhängig voneinander frei. Die obige Ansicht basiert also auf der Theorie und der Beobachtung der Schmerzpunkte der Serviceverwaltung.
Dieser Artikel wurde aus dem persönlichen Blog des Autors wiederveröffentlicht. Für eine Referenz klicken Sie bitte hier.
