Mikrodienste sind ein Architekturmuster für die Anwendungsentwicklung. Mit Mikrodiensten kann eine große Anwendung in unabhängige Bestandteile zerlegt werden, die jeweils einen eigenen Zuständigkeitsbereich haben. Zur Verarbeitung einer einzelnen Nutzer- oder API-Anfrage kann eine auf Mikrodiensten beruhende Anwendung viele interne Mikrodienste aufrufen.
Mit einer auf Mikrodiensten beruhenden Anwendung, die ordnungsgemäß implementiert wurde, können Sie folgende Ziele erreichen:
- Definition starker Verträge zwischen den verschiedenen Mikrodiensten
- Unabhängige Bereitstellungszyklen, einschließlich Rollback
- Vereinfachung gleichzeitiger A/B-Release-Tests auf Subsystemen
- Minimierung des Aufwands für Testautomatisierung und Qualitätssicherung
- Verbesserung der Übersichtlichkeit von Logging und Monitoring
- Bereitstellung einer detaillierten Kostenrechnung
- Erhöhung der Anwendungsskalierbarkeit und -zuverlässigkeit
Google App Engine bietet eine Reihe von Funktionen, die gut für Mikrodienstanwendungen geeignet sind. Auf dieser Seite werden Best Practices für die Bereitstellung einer auf Mikrodiensten beruhenden Anwendung in Google App Engine beschrieben.
App Engine-Dienste als Mikrodienste
In einem App Engine-Projekt können mehrere Mikrodienste als separate Dienste bereitgestellt werden. Diese wurden in App Engine früher als Module bezeichnet. Der Code dieser Dienste ist vollständig isoliert. Die einzige Möglichkeit zum Ausführen von Code in diesen Diensten ist ein HTTP-Aufruf, z. B. eine Nutzeranfrage oder der Aufruf über eine RESTful API. Der Code in einem Dienst kann den Code in einem anderen Dienst nicht direkt aufrufen. Code kann jeweils unabhängig für die Dienste bereitgestellt werden und verschiedene Dienste können in unterschiedlichen Sprachen wie Python, Java, Go und PHP geschrieben werden. Autoscaling, Load-Balancing und Maschineninstanztypen werden jeweils unabhängig für die Dienste verwaltet.
Versionen innerhalb von Diensten
Für jeden Dienst können mehrere Versionen gleichzeitig bereitgestellt werden. Eine dieser Versionen ist für jeden Dienst die Standard-Bereitstellungsversion. Es ist jedoch möglich, direkt auf jede bereitgestellte Version zuzugreifen, da jede Version über eine eigene Adresse verfügt. Diese Struktur eröffnet unzählige Möglichkeiten, z. B. Fehlertests für neue Versionen, A/B-Tests zwischen verschiedenen Versionen und vereinfachte Rollforward- und Rollback-Vorgänge. Das App Engine-Framework stellt Mechanismen bereit, die Sie bei den meisten dieser Funktionen unterstützen. Diese Mechanismen werden in den nächsten Abschnitten ausführlicher behandelt.
Dienstisolation
Obwohl die Dienste größtenteils isoliert sind, teilen sie sich einige App Engine-Ressourcen. Cloud Datastore, Memcache und Aufgabenwarteschlangen sind z. B. Ressourcen, die von den Diensten in einem App Engine-Projekt gemeinsam genutzt werden. Auch wenn diese gemeinsame Nutzung gewisse Vorteile hat, ist es für eine auf Mikrodiensten beruhende Anwendung wichtig, die Code- und Datenisolation zwischen Mikrodiensten aufrechtzuerhalten. Es gibt Architekturmuster, die dazu beitragen, eine unerwünschte gemeinsame Nutzung von Ressourcen zu reduzieren. Diese Muster werden weiter unten in diesem Artikel beschrieben.
Projektisolation
Wenn Sie sich nicht auf diese Muster verlassen möchten, um eine Isolation zu erreichen, können Sie mehrere App Engine-Projekte verwenden, um die Trennung auf formalere Weise durchzusetzen. Die Verwendung von Projekten anstelle von Diensten hat Vor- und Nachteile, die Sie je nach Situation gegeneinander abwägen müssen. Sofern Sie keinen besonderen Bedarf für die Vorteile haben, die die Verwendung mehrerer Projekte bietet, empfiehlt es sich, mit der Verwendung mehrerer Dienste in einem einzelnen Projekt zu beginnen. Dies ermöglicht eine bessere Leistung und minimiert den Verwaltungsaufwand. Sie können sich natürlich auch für eine Mischung aus beiden Ansätzen entscheiden.
Dienstisolation und Projektisolation im Vergleich
In der folgenden Tabelle wird die Verwendung mehrerer Dienste mit der Verwendung mehrerer Projekte in einer Mikrodienste-Architektur verglichen:
| Mehrere Dienste | Mehrere Projekte | |
|---|---|---|
| Codeisolation | Der bereitgestellte Code ist zwischen Diensten und Versionen vollständig getrennt. | Der bereitgestellte Code ist zwischen Projekten sowie zwischen Diensten und Versionen jedes Projekts vollständig getrennt. |
| Datenisolation |
Cloud Datastore und Memcache werden von den verschiedenen Diensten und Versionen gemeinsam verwendet. Es können jedoch Namespaces als Entwicklermuster verwendet werden, um die Daten zu isolieren.
Für die Isolation von Aufgabenwarteschlangen können die Entwickler eine Konvention für Warteschlangennamen nutzen, z. B. user-service-queue-1
|
Cloud Datastore, Memcache und Aufgabenwarteschlangen sind zwischen Projekten vollständig unabhängig. |
| Logisolation | Jeder Dienst (und jede Version) verfügt über getrennte Logs, die jedoch zusammen angezeigt werden können. | Jedes Projekt (und jeder Dienst und jede Version jedes Dienstes) verfügt über eigene Logs. Die Logs für ein bestimmtes Projekt können aber alle zusammen angezeigt werden. Logs aus verschiedenen Projekten können nicht zusammen angezeigt werden. |
| Leistungsaufwand | Dienste desselben Projekts werden im selben Rechenzentrum bereitgestellt, sodass die Latenz beim Aufrufen eines Dienstes von einem anderen Dienst aus mithilfe von HTTP sehr niedrig ist. | Projekte werden möglicherweise in verschiedenen Rechenzentren bereitgestellt, sodass die HTTP-Latenzen höher sein können. Sie sind jedoch immer noch sehr niedrig, da Google über ein erstklassiges Netzwerk verfügt. |
| Kostenrechnung | Die Kosten für Instanzstunden (CPU und Arbeitsspeicher zum Ausführen des Codes) werden für die Dienste nicht getrennt berechnet. Vielmehr werden alle Instanzstunden eines gesamten Projekts zusammengelegt. | Die Kosten für verschiedene Projekte werden aufgeteilt, sodass die Kosten der einzelnen Mikrodienste sehr einfach unterschieden werden können. |
| Operatorberechtigungen | Ein Operator hat die Möglichkeit, Code bereitzustellen, Rollforward- und Rollback-Vorgänge für Versionen durchzuführen und die Logs für alle Dienste eines Projekts einzusehen. Es gibt keine Möglichkeit, den Zugriff auf bestimmte Dienste zu beschränken. | Der Operatorzugriff kann für individuelle Projekte separat gesteuert werden. |
| Anfrage-Tracing | Mit Google Cloud Trace können Sie eine Anfrage und die daraus resultierenden Mikrodienstanfragen für Dienste im selben Projekt als einzeln erstellten Trace aufrufen. Diese Funktion kann die Leistungsoptimierung vereinfachen. | Cloud Trace-Aufrufe können über GCP-Projekte hinweg visualisiert werden, wenn sie sich in derselben Organisation befinden. |
Weitere Informationen
- Mit Mikrodiensten in App Engine Entwicklungs-, Test-, QA-, Staging- und Produktionsumgebungen erstellen und benennen
- Best Practices für die Erstellung von APIs zur Kommunikation zwischen Mikrodiensten
- Best Practices für leistungsfähige Mikrodienste
- Von einer monolithischen Anwendung auf Mikrodienste migrieren
- Eignen sich Mikrodienste für Ihre Situation? Der Google Solution Architect Preston Holmes hat in seinem persönlichen Blog einen Post über einige der Nachteile veröffentlicht, die er in Bezug auf Mikrodienste sieht.