Viele moderne Anwendungen müssen unternehmensweit erstellt werden, manchmal sogar über das Internet. Jede Anwendung muss die Anforderungen an Skalierbarkeit, Verfügbarkeit, Sicherheit, Zuverlässigkeit und Ausfallsicherheit erfüllen.
In diesem Artikel werde ich einige Entwurfsmuster vorstellen, mit denen Sie die oben genannten Funktionen problemlos erreichen können. Ich werde jedes Muster behandeln, wie dieses Muster in der Cloud verwendet wird und wann und wann nicht.
Einige dieser Muster sind nicht allzu neu, aber in der heutigen Internet-Cloud-Welt sehr nützlich.
Hier ist eine Liste der Muster, die ich in diesem Artikel diskutieren werde:
- Leistungsschalter
- CQRS (Command and Query Responsibility Segregation)
- Event-Beschaffung
- Beiwagen
- Backend für Frontend
- Würger
Also lasst uns anfangen.
1. Leistungsschalter
Verteilte Systeme müssen unter Berücksichtigung von Fehlern entworfen werden. Heutzutage gibt es weltweit Mikrodienste, und diese Dienste hängen hauptsächlich von anderen Remote-Diensten ab. Diese Remote-Dienste reagieren aus verschiedenen Gründen wie Netzwerk, Herunterladen von Anwendungen usw. möglicherweise nicht rechtzeitig. In den meisten Fällen sollte die Implementierung von Wiederholungsversuchen in der Lage sein, Probleme zu lösen.
Aber manchmal kann es ernsthafte Probleme geben, wie z. B. eine Verschlechterung der Dienste oder einen vollständigen Ausfall der Dienste an sich. In solchen Fällen macht es keinen Sinn, es erneut zu versuchen. In diesem Fall kann das Leistungsschaltermodell nützlich sein.
Das obige Diagramm zeigt eine Implementierung eines Leistungsschalterschemas, bei dem, wenn Dienst 1 erkennt, dass der anrufende Dienst 2 kontinuierliche Fehler / Zeitüberschreitungen aufweist, anstatt es erneut zu versuchen, Dienst 1 Anrufe zu Dienst 2 trennt und im Fehlerfall eine Antwort zurückgibt.
Es gibt beliebte Open-Source-Bibliotheken wie Netflix Hystrix
oder Reselience4J , mit denen dieses Muster sehr einfach implementiert werden kann.
Wenn Sie API-Gateways oder Proxys
wie Envoy verwenden , kann dies auf der Proxy-Ebene selbst erreicht werden.
Hinweis:Es ist sehr wichtig, dass genügend Protokolle und Warnungen implementiert werden, wenn die Kette geöffnet ist, um die während dieser Zeit eingegangenen Anforderungen zu verfolgen, und dass das Betriebsteam dies weiß.
Sie können auch einen Halbleistungsschalter implementieren, um weiterhin Kunden mit eingeschränktem Service zu bedienen.
Wann soll dieses Muster verwendet werden?
- Wenn ein Dienst von einem anderen Remotedienst abhängt und in einigen Szenarien wahrscheinlich fehlschlägt.
- Wenn der Dienst eine sehr starke Abhängigkeit aufweist (wie Stammdatendienste).
Wann sollte dieses Muster nicht verwendet werden?
- Beim Umgang mit lokalen Abhängigkeiten kann ein Leistungsschalter Overhead verursachen.
2. Command and Query Responsibility Segregation (CQRS) ( (CQRS))
CQRS ist ein sehr nützliches Modell für moderne Data Warehouse-Anwendungen. Es basiert auf dem Prinzip der Trennung von Lese- (Abfrage) und Schreib- / Aktualisierungsoperationen (Befehl) im Datenspeicher.
Angenommen, Sie erstellen eine Anwendung, bei der Daten in einer Datenbank wie MySQL / PostgreSQL usw. gespeichert werden müssen. Wie jeder weiß, muss ein Vorgang beim Schreiben von Daten in den Speicher mehrere Phasen durchlaufen - beispielsweise Validierung, Modellierung und Persistenz - und daher dauern typische Schreib- / Aktualisierungsvorgänge länger als einfache Lesevorgänge.
Wenn Sie einen einzelnen Datenspeicher verwenden, um Lese- und Schreibvorgänge gleichzeitig und in großem Maßstab auszuführen, können Leistungsprobleme auftreten.
In solchen Fällen kann die CQRS-Vorlage hilfreich sein. Das CQRS-Muster schlägt vor, unterschiedliche Datenmodelle für Lese- und Schreibvorgänge zu verwenden. Einige Variationen schlagen auch vor, separate Datenspeicher für diese Modelle zu verwenden.
Hinweis: Die meisten PaaS-Datenbanken bieten heutzutage die Möglichkeit, lesbare Replikate ( Google Cloud SQL , Azure SQL DB , Amazon RDS
usw.) von Datenspeichern zu erstellen , wodurch die Datenreplikation erheblich vereinfacht wird.
Viele Unternehmensdatenbanken bieten diese Funktion auch, wenn Sie mit lokalen Datenbanken arbeiten.
Hinweis: Einige Benutzer bevorzugen heutzutage auch die Implementierung lesbarer Replikate als schnelle und leistungsfähige NoSQL-Datenbanken wie MongoDB und Elasticsearch.
Wann soll dieses Muster verwendet werden?
- Wenn Sie eine Anwendung skalieren möchten, die eine große Anzahl von Lese- und Schreibvorgängen erwartet
- Wenn Sie Lese- und Schreibvorgänge separat einrichten möchten.
- Wenn Ihre Lesevorgänge nahezu real oder letztendlich konsistent sind.
Wann sollte dieses Muster nicht verwendet werden?
- Wenn Sie eine reguläre CRUD-Anwendung erstellen, die nicht viele Lese- und Schreibvorgänge auf einmal erwartet.
3. Event Sourcing
Eine Ereignisquelle ist ein interessantes Entwurfsmuster, in dem eine Folge von Domänenereignissen als Protokoll gespeichert wird und eine aggregierte Protokollansicht den aktuellen Status der Anwendung angibt.
Dieses Muster wird häufig für Systeme verwendet, die sich keine Datenspeichersperren leisten können und die die Überwachung und den Ereignisverlauf beibehalten müssen, z. B. Anwendungen wie Hotel / Konferenz / Sitzordnung.
Bei einem Hotelzimmer-Reservierungssystem, bei dem Benutzer eine Reservierung buchen oder stornieren sollen. Hier müssen Sie Ihre Reservierung und Stornierung als eine Reihe von Veranstaltungen speichern. Die verfügbaren Zimmer werden vor jeder Buchung in einer Zusammenfassung angezeigt, indem die Veranstaltungsprotokolle überprüft werden.
Hinweis:Die meisten Cloud-Dienstanbieter unterstützen Messaging-Dienste wie Google Pub / Sub, Azure Service Bus, AWS SQS usw. Diese Dienste können in Kombination mit stark konsistenten Datenspeichern zur Implementierung dieses Schemas verwendet werden.
Wann soll dieses Muster verwendet werden?
- Wenn normale CRUD-Operationen nicht gut genug sind, um die Anforderungen zu erfüllen
- In der Regel geeignet für Sitzplatzreservierungssysteme wie Busse, Züge, Konferenzen, Kinos usw. - oder für E-Commerce-Systeme, die aus Aktivitäten wie Einkaufswagen, Zahlungen usw. bestehen.
- Wenn eine starke Überwachung und Ereigniswiedergabe erforderlich ist, um den aktuellen und früheren Status von Anwendungen zu erstellen.
Wann sollte dieses Muster nicht verwendet werden?
- Wenn normale CRUD-Operationen gut genug sind, um die Benutzeranforderungen zu erfüllen.
4. Beiwagen (Sidecar Design Pattern)
Das Sidecar-Muster wurde mit dem Aufkommen von Microservices populär. In diesem Schema wird die Anwendungskomponente in einem separaten Prozess oder Container bereitgestellt. Dies hilft, Abstraktion und Kapselung zu erreichen.
Envoy Proxy ist einer der beliebtesten Sidecar-Proxy-Server und wird häufig verwendet. Es hilft Ihnen, die Hauptfunktionalität einer Anwendung zu entkoppeln, indem Sie einen Nebencomputer verwenden, um allgemeine Funktionen wie Netzwerk, Beobachtbarkeit und Sicherheit zu isolieren.
Diese Art von Beiwagen kann die abstrakte Art der Kommunikation L4 / L7 unterstützen. Beiwagen wie Envoy Proxies tragen sogar zur Erhöhung der Sicherheit bei, indem sie gegenseitiges TLS implementieren.
Sie können dies in Kombination mit einem Service-Grid verwenden, um eine bessere Konnektivität und Sicherheit zwischen verschiedenen Microservices zu erzielen. Sie können mehr darüber in meinem vorherigen Artikel lesen .
Wann soll dieses Muster verwendet werden?
- Wenn Sie mit zahlreichen und heterogenen Microservices in einem Produktportfolio zu tun haben.
- Beim Umgang mit Legacy-Anwendungen, die die Interoperabilitäts- und Sicherheitsherausforderungen der neuen Ära nicht bewältigen können.
Wann sollte dieses Muster nicht verwendet werden?
- Wenn Sie mit einer begrenzten Anzahl von Diensten zu tun haben, die miteinander kommunizieren müssen.
- Kleine Anwendungen, bei denen der Einsatz von Seitenrollstühlen unwirtschaftlich oder unpraktisch sein kann
5. Backend-for-Front (BFF)
In einem typischen Produktentwicklungszyklus sind Back-End-Ingenieure für die Erstellung von Services verantwortlich, die mit Data Warehouses interagieren, während Front-End-Ingenieure für die Erstellung von Benutzeroberflächen zuständig sind. Apps müssen heutzutage sowohl für Mobilgeräte als auch für Desktops entwickelt werden.
Während sich die Kluft zwischen mobilen und Desktop-Geräten in Bezug auf Hardware immer weiter vergrößert, sind Konnektivität und Verwendung für mobile Geräte immer noch eine Herausforderung.
In solchen Szenarien sind BFF-Vorlagen sehr praktisch. Hier wird erwartet, dass Sie interne Dienste für ein bestimmtes Front-End erstellen / konfigurieren.
Um die Leistung mobiler Clients zu optimieren, möchten Sie möglicherweise einen separaten Back-End-Service erstellen, der mit einfachen und paginierten Antworten reagiert.
Möglicherweise möchten Sie dieses Muster auch verwenden, um verschiedene Dienste zusammenzufassen und die Datenkommunikation zwischen Back-End und Front-End zu reduzieren.
Hinweis: Wenn Sie heutzutage ein API-Gateway verwenden, kann das BFF-Muster problemlos im Gateway selbst implementiert werden, und Sie müssen keine separaten Dienste bereitstellen.
Wann soll dieses Muster verwendet werden?
- Wenn Sie verschiedenen Kunden wie Desktop- und Mobilclients ein Produkt / eine Dienstleistung anbieten möchten.
- Wenn Sie Ihre Antwort für einen bestimmten Kundentyp optimieren möchten.
- Wenn Sie den Chat zwischen mobilen Clients und verschiedenen Diensten reduzieren möchten.
- , .
- , .
6. Strangler ( )
Wenn Sie für eine Organisation arbeiten, die auf dem Weg zur Modernisierung von Anwendungen ist, ist das Strangler-Entwurfsmuster ein Muss. Das Strangler-Muster empfiehlt, eine Fassadenüberlagerung auf Ihrem Erbe und Ihrer neuen Anwendung aufzubauen, damit die Verbraucher die Dinge objektiv betrachten können.
Dieses Muster trennt Clients von Migrationsaktivitäten zwischen alten und neuen Teilen der Anwendung.
Hinweis: In einer typischen IT-Organisation ist diese Art von Schema äußerst nützlich, wenn Sie von einem ERP-System auf ein anderes migrieren. Wenn Sie die Gateway-API verwenden, ist es einfacher, dies im Proxy-Gateway selbst zu implementieren.
Sie müssen entscheiden, ob Sie das Add-In (Fassade) am Ende der Migration beibehalten oder entfernen möchten.
Wann soll dieses Muster verwendet werden?
- Wenn Sie eine komplexe, stark abhängige Anwendung wie eine ERP-Migration migrieren oder aktualisieren
Wann sollte dieses Muster nicht verwendet werden?
- Wenn die Migration einfach ist und ein direkter Austausch die beste Option ist.