Bewertung und Bereitschaft von Microservices

  • Artikel

Eine Microservicesarchitektur kann viele Vorteile für Ihre Anwendungen bieten, einschließlich Flexibilität, Skalierbarkeit und Hochverfügbarkeit. Neben diesen Vorteilen bringt diese Architektur auch Herausforderungen mit sich. Wenn Sie auf Microservices basierende Anwendungen erstellen oder vorhandene Anwendungen in eine Microservicesarchitektur transformieren, müssen Sie Ihre aktuelle Situation analysieren und bewerten, um Bereiche zu identifizieren, die verbessert werden müssen.

Dieser Leitfaden soll Ihnen helfen, einige Überlegungen zu verstehen, die Sie bei der Umstellung auf eine Microservicesarchitektur beachten sollten. Sie können diesen Leitfaden verwenden, um den Reifegrad Ihrer Anwendung, Infrastruktur, DevOps, Ihres Entwicklungsmodells und vieles mehr zu bewerten.

Grundlegendes zu geschäftlichen Prioritäten

Um mit der Auswertung einer Microservicesarchitektur zu beginnen, müssen Sie zunächst die wichtigsten Prioritäten Ihres Unternehmens verstehen. Kernprioritäten können z. B. mit Flexibilität, Änderungsakzeptanz oder schneller Entwicklung zusammenhängen. Sie müssen analysieren, ob Ihre Architektur für Ihre wichtigsten Prioritäten geeignet ist. Beachten Sie, dass sich geschäftliche Prioritäten im Laufe der Zeit ändern können. Innovation hat beispielsweise oberste Priorität für Startups, aber nach einigen Jahren können Zuverlässigkeit und Effizienz die Kernprioritäten sein.

Einige zu berücksichtigende Prioritäten sind:

  • Innovation
  • Zuverlässigkeit
  • Effizienz

Dokumentieren Sie die SLAs, die auf die verschiedenen Teile Ihrer Anwendung abgestimmt sind, um eine organisatorische Verpflichtung sicherzustellen, die als Leitfaden für Ihre Bewertung dienen kann.

Aufzeichnen achitektonischer Entscheidungen

Eine Microservicesarchitektur erleichtert Teams, autonom zu werden. Teams können beispielsweise eigene Entscheidungen zu Technologien, Methoden und Infrastrukturkomponenten treffen. Bei diesen Entscheidungen sollten jedoch die formal vereinbarten Prinzipien beachtet werden, die als gemeinsame Governance bezeichnet werden und die Vereinbarung zwischen den Teams zum Ausdruck bringen, wie die breitere Strategie für Microservices angegangen werden kann.

Beachten Sie folgende Faktoren:

  • Ist gemeinsame Governance vorhanden?
  • Verfolgen Sie Entscheidungen und die damit verbundenen Kompromisse in einem Architekturjournal nach?
  • Kann Ihr Team problemlos auf Ihr Architekturjournal zugreifen?
  • Verfügen Sie über einen Prozess zum Auswerten von Tools, Technologien und Frameworks?

Bewerten der Teamzusammenstellung

Sie müssen über die richtige Teamstruktur verfügen, um unnötige Kommunikation zwischen Teams zu vermeiden. Eine Microservicesarchitektur fördert die Bildung kleiner, fokussierter, funktionsübergreifender Teams und erfordert eine Änderung der Mentalität, dem eine Umstrukturierung des Teams vorausgehen muss.

Beachten Sie folgende Faktoren:

  • Sind Ihre Teams den DDD-Prinzipien (Domain-Driven Design, domänengesteuertes Design) entsprechend auf Unterdomänen basierend aufgeteilt?
  • Sind Ihre Teams funktionsübergreifend, und verfügen sie über genügend Kapazität, um zugehörige Microservices unabhängig zu erstellen und zu betreiben?
  • Wie viel Zeit wird für Ad-hoc-Aktivitäten und -Aufgaben aufgewendet, die nicht mit Projekten in Zusammenhang stehen?
  • Wie viel Zeit wird für die teamübergreifende Zusammenarbeit aufgewendet?
  • Verfügen Sie über einen Prozess zum Identifizieren und Minimieren technischer Schulden?
  • Wie werden Erkenntnisse und Erfahrungen zwischen Teams vermittelt?

Verwenden der Zwölf-Faktoren-Methodik

Das grundlegende Ziel der Auswahl einer Microservicesarchitektur ist, durch die Verwendung agiler Methoden einen schnelleren Nutzen zu erzielen und anpassungsfähig zu sein. Die Zwölf-Faktoren-App-Methodik enthält Richtlinien für die Erstellung von wartbaren und skalierbaren Anwendungen. Diese Richtlinien fördern Attribute wie Unveränderlichkeit, Kurzlebigkeit, deklarative Konfiguration und Automatisierung. Indem Sie diese Richtlinien integrieren und häufige Fehler vermeiden, können Sie lose gekoppelte, eigenständige Microservices erstellen.

Grundlegendes zum Zerlegungsansatz

Die Transformation einer monolithischen Anwendung in eine Microservicesarchitektur kostet Zeit. Beginnen Sie mit Edgediensten. Edgedienste weisen weniger Abhängigkeiten von anderen Diensten auf und können problemlos als unabhängige Dienste aus dem System herausgelöst werden. Sie sollten unbedingt Muster wie Strangler-Musterund Muster „Antibeschädigungsebene“ verwenden, um die monolithische Anwendung in einem funktionsfähigen Zustand zu halten, bis alle Dienste in separate Microservices zerlegt sind. Während der Trennung können die DDD-Prinzipien Teams dabei helfen, Komponenten oder Dienste aus der monolithischen Anwendung basierend auf Unterdomänen auszuwählen.

In einem E-Commerce-System verfügen Sie z. B. möglicherweise über die folgenden Module: Warenkorb, Produktverwaltung, Auftragsverwaltung, Preise, Rechnungsgenerierung und Benachrichtigung. Sie entscheiden sich dafür, die Transformation der Anwendung mit dem Benachrichtigungsmodul zu starten, da es keine Abhängigkeiten von anderen Modulen hat. Andere Module können jedoch davon abhängig sein, dass dieses Modul Benachrichtigungen sendet. Das Benachrichtigungsmodul kann leicht in einen separaten Microservice zerlegt werden, aber Sie müssen einige Änderungen an der monolithischen Anwendung vornehmen, um den neuen Benachrichtigungsdienst aufzurufen. Als Nächstes entscheiden Sie sich für die Transformation des Moduls für die Rechnungsgenerierung. Dieses Modul wird aufgerufen, nachdem eine Bestellung generiert wurde. Sie können Muster wie „Strangler“ und „Antibeschädigung“ verwenden, um diese Transformation zu unterstützen.

Datensynchronisierung, mehrfache Schreibvorgänge in monolithische und Microserviceschnittstellen, Datenbesitz, Schemazerlegung, Verknüpfungen, Datenmenge und Datenintegrität können die Datenaufschlüsselung und -migration erschweren. Sie können verschiedene Techniken verwenden, z. B. das Verwalten einer zwischen Microservices freigegebenen Datenbank, das auf Geschäftsfunktionen oder Domänen basierende Entkoppeln von Datenbanken von einer Gruppe von Diensten und das Isolieren von Datenbanken von den Diensten. Die empfohlene Lösung ist, jede Datenbank mit jedem Dienst zu zerlegen. In vielen Fällen ist dies nicht praktikabel. In diesen Fällen können Sie Muster wie „Datenbanksicht“ und „Database Wrapping Service“ verwenden.

Bewerten der DevOps-Bereitschaft

Wenn Sie zu einer Microservicesarchitektur wechseln, ist es wichtig, dass Sie Ihre DevOps-Kompetenz bewerten. Eine Microservicesarchitektur soll die agile Entwicklung in Anwendungen erleichtern, um die Flexibilität der Organisation zu erhöhen. DevOps ist eine der wichtigsten Methoden, die Sie implementieren sollten, um diese Kompetenz zu erreichen.

Beachten Sie folgende Punkte, wenn Sie Ihre DevOps-Funktionalität für eine Microservicearchitektur auswerten:

  • Kennen Personen in Ihrer Organisation die grundlegenden Methoden und Prinzipien von DevOps?
  • Verstehen Teams Quellcodeverwaltungstools und ihre Integration in CI/CD-Pipelines?
  • Implementieren Sie DevOps-Methoden ordnungsgemäß?
    • Befolgen Sie agile Verfahren?
    • Ist Continuous Integration implementiert?
    • Ist Continuous Delivery implementiert?
    • Ist Continuous Deployment implementiert?
    • Ist kontinuierliche Überwachung implementiert?
    • Ist Infrastructure-as-Code (IaC) vorhanden?
  • Verwenden Sie die richtigen Tools zur Unterstützung von CI/CD?
  • Wie wird die Konfiguration von Staging- und Produktionsumgebungen für die Anwendung verwaltet?
  • Verfügt die Toolkette über Communitysupport und ein Supportmodell und stellt geeignete Kanäle und Dokumentation bereit?

Identifizieren von Geschäftsbereichen, die sich häufig ändern

Eine Microservicesarchitektur ist flexibel und anpassungsfähig. Erörtern Sie während der Bewertung in einer Diskussion in der Organisation, welche Bereiche sich nach Meinung Ihrer Kollegen häufig ändern werden. Durch das Erstellen von Microservices können Teams schnell auf Änderungen reagieren, die Kunden anfordern, und den Aufwand für Regressionstests minimieren. In einer monolithischen Anwendung erfordert eine Änderung in einem Modul zahlreiche Ebenen von Regressionstests und verringert die Agilität bei der Veröffentlichung neuer Versionen.

Beachten Sie folgende Faktoren:

  • Kann der Dienst unabhängig bereitgestellt werden?
  • Folgt der Dienst DDD-Prinzipien?
  • Folgt der Dienst SOLID-Prinzipien?
  • Ist die Datenbank für den Dienst privat?
  • Haben Sie den Dienst mithilfe des unterstützten Microservicesgehäusemusters erstellt?

Bewerten der Infrastrukturbereitschaft

Wenn Sie zu einer Microservicesarchitektur wechseln, ist die Infrastrukturbereitschaft ein wichtiger Punkt, der berücksichtigt werden muss. Die Leistung, Verfügbarkeit und Skalierbarkeit der Anwendung wird beeinträchtigt, wenn die Infrastruktur nicht ordnungsgemäß eingerichtet ist oder nicht die richtigen Dienste oder Komponenten verwendet werden. Manchmal wird eine Anwendung mit allen vorgeschlagenen Methoden und Verfahren erstellt, aber die Infrastruktur ist unzureichend. Dies führt zu schlechter Leistung und Wartung.

Berücksichtigen Sie diese Faktoren, wenn Sie Ihre Infrastrukturbereitschaft auswerten:

  • Stellt die Infrastruktur die Skalierbarkeit der bereitgestellten Dienste sicher?
  • Unterstützt die Infrastruktur die Bereitstellung über Skripts, die über CI/CD automatisiert werden können?
  • Bietet die Bereitstellungsinfrastruktur eine SLA für die Verfügbarkeit?
  • Verfügen Sie über einen Notfallwiederherstellungsplan (Disaster Recovery, DR) und routinemäßige Übungspläne?
  • Werden die Daten für die DR in verschiedene Regionen repliziert?
  • Verfügen Sie über einen Datensicherungsplan?
  • Sind die Bereitstellungsoptionen dokumentiert?
  • Wird die Bereitstellungsinfrastruktur überwacht?
  • Unterstützt die Bereitstellungsinfrastruktur die Selbstreparatur von Diensten?

Bewerten von Releasezyklen

Microservices sind anpassungsfähig für Änderungen und profitieren von der agilen Entwicklung, um Releasezyklen zu verkürzen und Kunden einen größeren Nutzen zu bieten. Berücksichtigen Sie diese Faktoren, wenn Sie Ihre Releasezyklen auswerten:

  • Wie oft erstellen und veröffentlichen Sie Anwendungen?
  • Wie oft treten bei Ihren Releases nach der Bereitstellung Fehler auf?
  • Wie lange dauert die Wiederherstellung oder Behebung von Problemen nach einem Ausfall?
  • Verwenden Sie die semantische Versionsverwaltung für Ihre Anwendungen?
  • Verwalten Sie verschiedene Umgebungen und verteilen dasselbe Release in einer Sequenz (z. B. zuerst in der Stagingumgebung und dann in der Produktionsumgebung)?
  • Verwenden Sie die Versionsverwaltung für Ihre APIs?
  • Halten Sie sich an die richtigen Versionsverwaltungsrichtlinien für APIs?
  • Wann ändern Sie eine API-Version?
  • Welchen Ansatz verfolgen Sie beim Umgang mit der API-Versionsverwaltung?
    • URI-Pfadversionsverwaltung
    • Abfrageparameter-Versionsverwaltung
    • Inhaltstyp-Versionsverwaltung
    • Versionsverwaltung für benutzerdefinierte Header
  • Gibt es eine Methode für die Ereignisversionsverwaltung?

Bewerten der Dienste übergreifenden Kommunikation

Microservices sind eigenständige Dienste, die über Prozessgrenzen hinweg miteinander kommunizieren, um Geschäftsszenarien zu bewältigen. Um eine zuverlässige und verlässliche Kommunikation zu erhalten, müssen Sie ein geeignetes Kommunikationsprotokoll auswählen.

Berücksichtigen Sie diese Faktoren:

  • Verfolgen Sie einen API-First-Ansatz, bei dem APIs als erstklassige Citizens behandelt werden?
  • Haben Sie langkettige Operationen, bei denen mehrere Dienste der Reihe nach über ein synchrones Kommunikationsprotokoll kommunizieren?
  • Haben Sie die asynchrone Kommunikation überall im System in Betracht gezogen?
  • Haben Sie die Nachrichtenbrokertechnologie und ihre Funktionen bewertet?
  • Wissen Sie über den Durchsatz von Nachrichten Bescheid, die Dienste empfangen und verarbeiten?
  • Verwenden Sie die direkte Kommunikation zwischen Client und Dienst?
  • Müssen Sie Nachrichten auf Nachrichtenbrokerebene beibehalten?
  • Verwenden Sie das Muster für materialisierte Sichten, um dem „geschwätzigen“ Verhalten von Microservices gerecht zu werden?
  • Haben Sie Wiederholen, Sicherung, exponentielles Backoff und Jitter für eine zuverlässige Kommunikation implementiert? Eine gängige Methode, dies zu behandeln, ist die Verwendung des Botschaftermusters.
  • Haben Sie Domänenereignisse definiert, um die Kommunikation zwischen Microservices zu erleichtern?

Auswerten der Art und Weise, in der Dienste für Clients verfügbar gemacht werden

Ein API-Gateway ist eine der Kernkomponenten in einer Microservicesarchitektur. Das direkte Verfügbarmachen von Diensten für die Clients verursacht Probleme in Bezug auf Verwaltbarkeit, Kontrolle und verlässliche Kommunikation. Ein API-Gateway dient als Proxyserver, der Datenverkehr abfängt und an Back-End-Dienste weiterleitet. Wenn Sie Datenverkehr nach IP-Adresse, Autorisierung, Pseudoantworten usw. filtern müssen, können Sie dies auf API-Gatewayebene tun, ohne Änderungen an den Diensten vorzunehmen.

Berücksichtigen Sie diese Faktoren:

  • Werden die Dienste direkt von Clients verwendet?
  • Gibt es ein API-Gateway, das als Fassade für alle Dienste fungiert?
  • Kann das API-Gateway Richtlinien wie Kontingentgrenzen, Pseudoantworten und Filtern von IP-Adressen einrichten?
  • Verwenden Sie mehrere API-Gateways, um die Anforderungen verschiedener Arten von Clients zu erfüllen, wie etwa mobile Apps, Web-Apps und Partner?
  • Bietet Ihr API-Gateway ein Portal, in dem Kunden Dienste entdecken und abonnieren können, wie ein Entwicklerportal in Azure API Management?
  • Bietet Ihre Lösung zusammen mit dem API-Gateway L7-Lastenausgleichs- oder WAF-Funktionen (Web Application Firewall)?

Bewerten der Transaktionsverarbeitung

Verteilte Transaktionen erleichtern die Ausführung mehrerer Vorgänge als einzelne Arbeitseinheit. In einer Microservicesarchitektur wird das System in zahlreiche Dienste zerlegt. Ein einzelner Geschäftsanwendungsfall wird von mehreren Microservices als Teil einer einzelnen verteilten Transaktion behandelt. In einer verteilten Transaktion ist ein Befehl ein Vorgang, der gestartet wird, wenn ein Ereignis auftritt. Das Ereignis löst einen Vorgang im System aus. Wenn der Vorgang erfolgreich ist, wird möglicherweise ein anderer Befehl ausgelöst, der dann ein anderes Ereignis auslösen kann usw., bis alle Transaktionen abgeschlossen oder ein Rollback ausgeführt wurden, je nachdem, ob die Transaktion erfolgreich war.

Berücksichtigen Sie die folgenden Aspekte:

  • Wie viele verteilte Transaktionen gibt es im System?
  • Wie gehen Sie mit verteilten Transaktionen um? Werten Sie die Verwendung des Saga-Musters mit Orchestrierung oder Choreographie aus.
  • Wie viele Transaktionen umfassen mehrere Dienste?
  • Folgen Sie einem ACID- oder BASE-Transaktionsmodell, um Datenkonsistenz und -integrität zu erreichen?
  • Verwenden Sie lange Verkettungsvorgänge für Transaktionen, die mehrere Dienste umfassen?

Bewerten Ihres Dienstentwicklungsmodells

Einer der größten Vorteile von Microservicesarchitekturen ist die Technologievielfalt. Auf Microservices basierende Systeme ermöglichen Teams die Entwicklung von Diensten mithilfe der Technologien, die sie auswählen. Bei der herkömmlichen Anwendungsentwicklung können Sie vorhandenen Code wiederverwenden, wenn Sie neue Komponenten erstellen, oder ein internes Entwicklungsframework erstellen, um den Entwicklungsaufwand zu reduzieren. Die Verwendung mehrerer Technologien kann die Wiederverwendung von Code verhindern.

Beachten Sie folgende Faktoren:

  • Verwenden Sie eine Dienstvorlage, um eine neue Dienstentwicklung zu starten?
  • Befolgen Sie die Zwölf-Faktoren-App-Methodik, und verwenden Sie eine einzelne Codebasis für Microservices, wobei Abhängigkeiten isoliert werden und die Konfiguration externalisiert wird?
  • Speichern Sie sensible Konfigurationen in Schlüsseltresoren?
  • Containerisieren Sie Ihre Dienste?
  • Kennen Sie Ihre Datenkonsistenzanforderungen?

Bewerten Ihres Bereitstellungsansatzes

Ihr Bereitstellungsansatz ist Ihre Methode zum Veröffentlichen von Versionen Ihrer Anwendung in verschiedenen Bereitstellungsumgebungen. Auf Microservices basierende Systeme bieten die Flexibilität, Versionen schneller zu veröffentlichen als mit herkömmlichen Anwendungen.

Berücksichtigen Sie bei der Bewertung Ihres Bereitstellungsplans die folgenden Faktoren:

  • Haben Sie eine Strategie für die Bereitstellung Ihrer Dienste?
  • Verwenden Sie moderne Tools und Technologien, um Ihre Dienste bereitzustellen?
  • Welche Art von Zusammenarbeit ist zwischen Teams erforderlich, wenn Sie Dienste bereitstellen?
  • Stellen Sie Infrastruktur mithilfe von Infrastructure-as-Code (IaC) bereit?
  • Verwenden Sie DevOps-Funktionen, um Bereitstellungen zu automatisieren?
  • Werden dieselben Builds an mehrere Umgebungen verteilt, wie in der Zwölf-Faktoren-App-Methodik vorgeschlagen?

Bewerten Ihrer Hostingplattform

Skalierbarkeit ist einer der Hauptvorteile von Microservicesarchitekturen. Das liegt daran, dass Microservices Geschäftsdomänen zugeordnet sind, sodass jeder Dienst unabhängig skaliert werden kann. Eine monolithische Anwendung wird als einzelne Einheit auf einer Hostingplattform bereitgestellt und muss ganzheitlich skaliert werden. Dies führt zu Ausfallzeiten, Bereitstellungsrisiko und Wartung. Ihre monolithische Anwendung ist möglicherweise gut entworfen, mit Komponenten für einzelne Geschäftsdomänen. Aber aufgrund fehlender Prozessgrenzen wird das Potenzial, gegen die Prinzipien der einzelnen Verantwortung zu verstoßen, schwieriger. Dies führt schließlich zu Spaghetticode. Da die Anwendung als einzelner Hostingprozess zusammengesetzt ist und bereitgestellt wird, ist die Skalierbarkeit schwierig.

Mit Microservices können Teams die richtige Hostingplattform zur Unterstützung ihrer Skalierbarkeitsanforderungen wählen. Es stehen verschiedene Hostingplattformen zur Verfügung, um diese Herausforderungen zu bewältigen, indem Funktionen wie automatische Skalierung, elastische Bereitstellung, höhere Verfügbarkeit, schnellere Bereitstellung und einfache Überwachung bereitgestellt werden.

Beachten Sie folgende Faktoren:

  • Welche Hostingplattform verwenden Sie zum Bereitstellen Ihrer Dienste (virtuelle Computer, Container, serverlos)?
  • Ist die Hostingplattform skalierbar? Unterstützt Sie die automatische Skalierung?
  • Wie lange dauert es, Ihre Hostingplattform zu skalieren?
  • Verstehen Sie die SLAs, die verschiedene Hostingplattformen bereitstellen?
  • Unterstützt Ihre Hostingplattform die Notfallwiederherstellung?

Bewerten der Überwachung von Diensten

Die Überwachung ist ein wichtiges Element einer auf Microservices basierenden Anwendung. Da die Anwendung in eine Reihe von Diensten unterteilt ist, die unabhängig voneinander ausgeführt werden, kann die Problembehandlung schwierig sein. Wenn Sie die richtige Semantik verwenden, um Ihre Dienste zu überwachen, können Ihre Teams problemlos Fehler überwachen, untersuchen und darauf reagieren.

Beachten Sie folgende Faktoren:

  • Überwachen Sie Ihre bereitgestellten Dienste?
  • Verfügen Sie über einen Protokollierungsmechanismus? Welche Tools verwenden Sie?
  • Verfügen Sie über eine verteilte Ablaufverfolgungsinfrastruktur?
  • Zeichnen Sie Ausnahmen auf?
  • Verwalten Sie Geschäftsfehlercodes, um Probleme schnell zu erkennen?
  • Verwenden Sie Integritätstests für Dienste?
  • Verwenden Sie semantische Protokollierung? Haben Sie wichtige Metriken, Schwellenwerte und Indikatoren implementiert?
  • Maskieren Sie sensible Daten während der Protokollierung?

Bewerten der Korrelationstokenzuweisung

In einer Microservicesarchitektur besteht eine Anwendung aus verschiedenen Microservices, die unabhängig voneinander gehostet werden und miteinander interagieren, um verschiedenen Geschäftsanwendungsfällen gerecht zu werden. Wenn eine Anwendung mit Back-End-Diensten interagiert, um einen Vorgang auszuführen, können Sie der Anforderung ein eindeutiges, als Korrelationstoken bezeichnetes Token zuweisen. Sie sollten Korrelationstoken verwenden, da sie Ihnen bei der Problembehandlung helfen können. Sie helfen Ihnen, die Grundursache eines Problems zu ermitteln, die Auswirkungen zu bewerten und einen Ansatz zur Behebung des Problems zu bestimmen.

Mit Korrelationstoken können Sie den Anforderungspfad abrufen, indem Sie ermitteln, welche Dienste das Korrelationstoken enthalten und welche nicht. Bei den Diensten, die nicht über das Korrelationstoken für diese Anforderung verfügen, ist ein Fehler aufgetreten. Wenn ein Fehler auftritt, können Sie die Transaktion später wiederholen. Um Idempotenz zu erzwingen, wird die Anforderung nur von Diensten bedient, die nicht über das Korrelationstoken verfügen.

Wenn beispielsweise eine lange Kette von Vorgängen vorliegt, die viele Dienste umfasst, kann die Übergabe eines Korrelationstokens an Dienste Ihnen helfen, Probleme mühelos zu untersuchen, wenn einer der Dienste während einer Transaktion ausfällt. Jeder Dienst verfügt in der Regel über eine eigene Datenbank. Das Korrelationstoken wird im Datenbankdatensatz gespeichert. Bei einer Transaktionswiedergabe ignorieren Dienste, die über dieses bestimmte Korrelationstoken in ihren Datenbanken verfügen, die Anforderung. Die Anforderung wird nur von Diensten bedient, die nicht über das Token verfügen.

Beachten Sie folgende Faktoren:

  • In welcher Phase weisen Sie das Korrelationstoken zu?
  • Welche Komponente weist das Korrelationstoken zu?
  • Speichern Sie Korrelationstoken in der Datenbank des Diensts?
  • Welches Format haben Korrelationstoken?
  • Protokollieren Sie Korrelationstoken und andere Anforderungsinformationen?

Auswerten der Notwendigkeit eines Microservices-Chassisframeworks

Ein Microservices-Chassisframework ist ein Basisframework, das Funktionen für übergreifende Aspekte wie Protokollierung, Ausnahmebehandlung, verteilte Ablaufverfolgung, Sicherheit und Kommunikation bereitstellt. Wenn Sie ein Chassisframework verwenden, konzentrieren Sie sich eher auf die Implementierung der Dienstgrenze als auf die Interaktion mit der Infrastrukturfunktionalität.

Angenommen, Sie erstellen einen Warenkorb-Verwaltungsdienst. Sie möchten das eingehende Token überprüfen, Protokolle in die Protokollierungsdatenbank schreiben und mit einem anderen Dienst kommunizieren, indem Sie den Endpunkt dieses Diensts aufrufen. Wenn Sie ein Microservices-Chassisframework verwenden, können Sie den Entwicklungsaufwand reduzieren. Dapr ist ein System, das verschiedene Bausteine für die Implementierung übergreifender Belange bereitstellt.

Beachten Sie folgende Faktoren:

  • Verwenden Sie ein Microservices-Chassisframework?
  • Verwenden Sie Dapr für die Interaktion mit übergreifenden Belangen?
  • Ist Ihre Chassisframeworksprache agnostisch?
  • Ist Ihr Chassisframework generisch, sodass es alle Arten von Anwendungen unterstützt? Ein Chassisframework sollte keine anwendungsspezifische Logik enthalten.
  • Stellt Ihr Chassisframework einen Mechanismus bereit, um die ausgewählten Komponenten oder Dienste nach Bedarf zu verwenden?

Bewerten Ihres Ansatzes für Anwendungstests

In der Regel werden Tests nach Abschluss der Entwicklung durchgeführt, und die Anwendung ist für den Rollout für Benutzerakzeptanztests (User Acceptance Testing, UAT) und Produktionsumgebungen bereit. Der derzeitige Trend bei diesem Ansatz sieht vor, die Tests in eine frühe Phase des Anwendungsentwicklungs-Lebenszyklus (nach links) zu verschieben. Das nach links verschobene Testen steigert die Qualität von Anwendungen, da Tests in jeder Phase des Anwendungsentwicklungs-Lebenszyklus einschließlich der Entwurfs-, Entwicklungs- und Nachentwicklungsphase durchgeführt werden.

Wenn Sie beispielsweise eine Anwendung erstellen, beginnen Sie mit dem Entwerfen einer Architektur. Wenn Sie den nach links verschobenen Ansatz verwenden, testen Sie den Entwurf mithilfe von Tools wie Microsoft Threat Modeling auf Sicherheitsrisiken. Wenn Sie mit der Entwicklung beginnen, können Sie Ihren Quellcode überprüfen, indem Sie Tools wie statische Anwendungssicherheitstests (Static Application Security Testing, SAST) ausführen und andere Analysetools verwenden, um Probleme aufzudecken. Nachdem Sie die Anwendung bereitgestellt haben, können Sie sie mit Tools wie dynamischen Anwendungssicherheitstests (Dynamic Application Security Testing, DAST) testen, während sie gehostet wird. Funktionstests, Chaostests, Penetrationstests und andere Arten von Tests werden später durchgeführt.

Beachten Sie folgende Faktoren:

  • Schreiben Sie Testpläne, die den gesamten Entwicklungslebenszyklus abdecken?
  • Beziehen Sie Tester in Anforderungsbesprechungen und den gesamten Anwendungsentwicklungs-Lebenszyklus ein?
  • Verwenden Sie testgesteuertes oder verhaltensgesteuertes Design?
  • Testen Sie User Storys? Fügen Sie Akzeptanzkriterien in Ihre User Storys ein?
  • Testen Sie Ihren Entwurf mithilfe von Tools wie Microsoft Threat Modeling?
  • Schreiben Sie Komponententests?
  • Verwenden Sie statische Codeanalysetools oder andere Tools, um die Codequalität zu messen?
  • Verwenden Sie automatisierte Tools zum Testen von Anwendungen?
  • Implementieren Sie Secure DevOps-Methoden?
  • Werden Integrationstests, End-to-End-Anwendungstests, Auslastungs-/Leistungstests, Penetrationstests und Chaostests durchgeführt?

Bewerten der Sicherheit von Microservices

Dienstschutz, sicherer Zugriff und sichere Kommunikation gehören zu den wichtigsten Überlegungen für eine Microservicesarchitektur. Beispielsweise ist ein auf Microservices basierendes System, das mehrere Dienste umfasst und die Tokenvalidierung für jeden Dienst verwendet, keine praktikable Lösung. Dieses System würde sich auf die Agilität des Gesamtsystems und das Potenzial der Einführung von Implementierungsabweichungen zwischen Diensten auswirken.

Sicherheitsfragen werden in der Regel vom API-Gateway und der Anwendungsfirewall behandelt. Das Gateway und die Firewall übernehmen eingehende Anforderungen, überprüfen Token und wenden verschiedene Filter und Richtlinien an, z. B. die Implementierung von OWASP Top 10-Prinzipien zum Abfangen von Datenverkehr. Schließlich senden sie die Anforderung an die Back-End-Microservices. Diese Konfiguration hilft Entwicklern, sich auf geschäftsbezogene Anforderungen und nicht auf das übergreifende Sicherheitsproblem zu konzentrieren.

Beachten Sie folgende Faktoren:

  • Sind Authentifizierung und Autorisierung für den Dienst erforderlich?
  • Verwenden Sie ein API-Gateway, um Token und eingehende Anforderungen zu überprüfen?
  • Verwenden Sie SSL oder mTLS, um die Sicherheit für die Dienstkommunikation zu gewährleisten?
  • Verfügen Sie über Netzwerksicherheitsrichtlinien, um die erforderliche Kommunikation zwischen Diensten zu ermöglichen?
  • Verwenden Sie ggf. Firewalls (L4, L7), um die Sicherheit der internen und externen Kommunikation zu gewährleisten?
  • Verwenden Sie Sicherheitsrichtlinien in API-Gateway, um den Datenverkehr zu steuern?

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte