Einführung in die Microservices-Referenzarchitektur von NGINX

Chris Stetson

Anmerkung des Autors – Dieser Blogbeitrag ist der erste einer Reihe:

1. Einführung in die NGINX-Referenzarchitektur für Microservices (dieser Beitrag)
2. MRA, Teil 2: Das Proxy-Modell
3. MRA, Teil 3: Das Router-Mesh-Modell
4. MRA, Teil 4: Das Fabric-Modell
5. MRA, Teil 5: Anpassung der Twelve-Factor App für Microservices
6. MRA, Teil 6: Implementierung des Circuit-Breaker-Musters mit NGINX Plus

Alle sechs Blogbeiträge sowie ein Blogbeitrag über Web-Frontends für Microservices-Anwendungen<.htmla> wurden in einem kostenlosen E-Book zusammengefasst.

Sehen Sie sich auch diese weiteren NGINX-Ressourcen zum Thema Microservices an:

• Eine sehr hilfreiche und beliebte Artikelreihe von Chris Richardson über die Entwicklung von Microservices-Anwendungen
• Die Artikel von Chris Richardson, zusammengefasst in einem kostenlosen E-Book, mit zusätzlichen Tipps zur Implementierung von Microservices mit NGINX und NGINX Plus
• Weitere Blogbeiträge zu Microservices
• Microservices-Webinare
• Microservices-Lösungsseite
• Thema: Microservices

Einleitung

NGINX ist von Anfang an Teil der Microservices-Bewegung gewesen. Dank seiner schlanken, leistungsstarken und flexiblen Architektur eignet sich NGINX hervorragend für Microservices.

Das NGINX-Docker-Image ist das am häufigsten heruntergeladene Anwendungs-Image auf Docker Hub. Zudem enthalten die meisten heute im Web verfügbaren Microservices-Plattformen eine Demo, die NGINX in irgendeiner Form bereitstellt und eine Verbindung zur Willkommensseite herstellt.

Da wir davon überzeugt sind, dass der Umstieg auf Microservices für den Erfolg unserer Kunden von entscheidender Bedeutung ist, haben wir bei NGINX ein spezielles Programm ins Leben gerufen, um Funktionen und Verfahren zu entwickeln, die diesen grundlegenden Wandel bei der Entwicklung und Bereitstellung von Webanwendungen unterstützen. Uns ist auch bewusst, dass es viele verschiedene Ansätze für die Implementierung von Microservices gibt, von denen viele neuartig und speziell auf die Anforderungen einzelner Entwicklungsteams zugeschnitten sind. Wir sind der Ansicht, dass Modelle benötigt werden, die es Unternehmen erleichtern, eigene Microservices-basierte Anwendungen zu entwickeln und bereitzustellen.

Vor diesem Hintergrund entwickeln wir bei NGINX Professional Services die NGINX Microservices Reference Architecture (MRA) – eine Reihe von Modellen, mit denen Sie Ihre eigenen Microservices-Anwendungen erstellen können.

Die MRA besteht aus zwei Komponenten: einer detaillierten Beschreibung jedes der drei Modelle sowie herunterladbarem Code, der unser beispielhaftes Fotofreigabeprogramm Ingenious implementiert. Der einzige Unterschied zwischen den drei Modellen besteht im Konfigurationscode, mit dem NGINX Plus für das jeweilige Modell konfiguriert wird. Diese Blogbeitragsreihe bietet einen Überblick über jedes der Modelle. Detaillierte Beschreibungen, Konfigurationscode und der Code für das Beispielprogramm Ingenious werden im Laufe dieses Jahres zur Verfügung gestellt.

Mit der Entwicklung dieser Referenzarchitektur verfolgen wir drei Ziele:

• Kunden und der Branche sofort einsetzbare Vorlagen für die Entwicklung mikroservicebasierter Systeme bereitzustellen und so die Entwicklung zu beschleunigen und zu verbessern
• Eine Plattform zum Testen neuer Funktionen in NGINX und NGINX Plus zu schaffen, unabhängig davon, ob sie intern oder extern entwickelt und im Produktkern oder als dynamische Module bereitgestellt werden
• Damit wir die Systeme und Komponenten unserer Partner besser verstehen und so eine ganzheitliche Sicht auf das Microservices-Ökosystem gewinnen können

Die Microservices-Referenzarchitektur ist auch ein wichtiger Bestandteil der Professional-Services-Angebote für NGINX-Kunden. In der MRA verwenden wir nach Möglichkeit Funktionen, die sowohl NGINX Open Source als auch NGINX Plus gemeinsam haben, und bei Bedarf NGINX Plus-spezifische Funktionen. Bei den komplexeren Modellen bestehen stärkere Abhängigkeiten von NGINX Plus, wie nachfolgend beschrieben. Wir gehen davon aus, dass viele Nutzer der MRA vom Zugang zu den Professional Services von NGINX und zum technischen Support profitieren werden, der in einem NGINX Plus-Abonnement enthalten ist.

Überblick über die Referenzarchitektur für Microservices

Wir entwickeln die Referenzarchitektur gemäß den Prinzipien der Twelve‑Factor App. Die Dienste sind schlank, kurzlebig und zustandslos konzipiert.

Die MRA verwendet branchenübliche Komponenten wie Docker-Container, eine breite Palette von Programmiersprachen – Java, PHP, Python, NodeJS/JavaScript und Ruby – sowie eine NGINX-basierte Netzwerkinfrastruktur.

Eine der größten Veränderungen beim Anwendungsdesign und bei der Anwendungsarchitektur im Zuge der Umstellung auf Microservices besteht darin, dass die funktionalen Komponenten der Anwendung über das Netzwerk miteinander kommunizieren. In monolithischen Anwendungen kommunizieren die Anwendungskomponenten im Arbeitsspeicher. In einer Microservices-Anwendung erfolgt diese Kommunikation über das Netzwerk, weshalb dessen Konzeption und Implementierung von entscheidender Bedeutung sind.

Um dem Rechnung zu tragen, wurde die MRA mit drei verschiedenen Netzwerkmodellen implementiert, die alle NGINX oder NGINX Plus verwenden. Sie reichen von relativ einfach bis hin zu funktionsreich und komplex:

• Proxy-Modell – Ein einfaches Netzwerkmodell, das sich für den Einsatz von NGINX Plus als Controller oder API-Gateway für eine Microservices-Anwendung eignet. Dieses Modell basiert auf Docker Cloud.
• Router-Mesh-Modell – Ein robusterer Netzwerkansatz mit einem Load Balancer auf jedem Host und einer Verwaltung der Verbindungen zwischen den Systemen. Dieses Modell ähnelt der Architektur von Deis 1.0.
• Fabric-Modell – Das Herzstück der MRA: Beim Fabric-Modell kommt NGINX Plus in jedem Container zum Einsatz und verarbeitet den gesamten ein- und ausgehenden Datenverkehr. Es eignet sich gut für Systeme mit hoher Auslastung und unterstützt SSL/TLS auf allen Ebenen. Dabei sorgt NGINX Plus für geringere Latenz, persistente SSL/TLS-Verbindungen, Service Discovery und das Circuit-Breaker-Muster über alle Microservices hinweg.

Wir möchten, dass Sie diese Modelle als Ausgangspunkt für Ihre eigenen Microservices-Implementierungen verwenden, und freuen uns über Ihr Feedback dazu, wie wir die MRA verbessern können. (Sie können damit beginnen, unten einen Kommentar hinzuzufügen.)

Im Folgenden finden Sie eine kurze Beschreibung der einzelnen Modelle. Wir empfehlen Ihnen, alle Beschreibungen zu lesen, um einen ersten Eindruck davon zu bekommen, wie Sie eines oder mehrere der Modelle am besten einsetzen können. In zukünftigen Blogbeiträgen wird jedes Modell ausführlich vorgestellt – jeweils eines pro Beitrag.

Das Proxy-Modell im Überblick

Das Proxy-Modell ist ein relativ einfaches Netzwerkmodell. Es eignet sich hervorragend als Ausgangspunkt für eine erste Microservices-Anwendung oder als Zielmodell bei der Umwandlung einer mäßig komplexen monolithischen Legacy-Anwendung.

Im Proxy-Modell fungiert NGINX oder NGINX Plus als Ingress-Controller und leitet Anfragen an Microservices weiter. NGINX Plus kann dynamisches DNS für die Serviceerkennung verwenden, wenn neue Services erstellt werden. Das Proxy-Modell eignet sich auch als Vorlage, wenn NGINX als API-Gateway eingesetzt wird.

Wenn eine Kommunikation zwischen Diensten erforderlich ist – und das ist bei den meisten Anwendungen ab einem gewissen Komplexitätsgrad der Fall –, stellt die Service Registry den entsprechenden Mechanismus innerhalb des Clusters bereit. (Eine ausführliche Liste der Mechanismen für die Kommunikation zwischen Diensten finden Sie in diesem Blogbeitrag.) Docker Cloud verwendet diesen Ansatz standardmäßig. Um eine Verbindung zu einem anderen Dienst herzustellen, fragt ein Dienst das DNS ab und erhält eine IP-Adresse, an die er eine Anfrage senden kann.

Im Allgemeinen eignet sich das Proxy-Modell für einfache bis mäßig komplexe Anwendungen. Für den Lastenausgleich ist es jedoch nicht der effizienteste Ansatz bzw. das effizienteste Modell, insbesondere bei umfangreichen Systemen. Wenn Sie hohe Anforderungen an den Lastenausgleich haben, sollten Sie eines der unten beschriebenen Modelle verwenden. („Umfangreich“ kann sich sowohl auf eine große Anzahl von Microservices als auch auf ein hohes Datenverkehrsaufkommen beziehen.)

Anmerkung der Redaktion – Eine ausführliche Erläuterung dieses Modells finden Sie unter MRA, Teil 2 – Das Proxy-Modell.

Der nächste Schritt: das Router-Mesh-Modell

Das Router-Mesh-Modell ist mäßig komplex und eignet sich gut für robuste neue Anwendungsarchitekturen sowie für die Migration komplexerer monolithischer Legacy-Anwendungen, die die Funktionen des Fabric-Modells nicht benötigen.

Das Router Mesh Model verfolgt einen robusteren Netzwerkansatz als das Proxy Model, indem auf jedem Host ein Load Balancer ausgeführt wird und die Verbindungen zwischen Microservices aktiv verwaltet werden. Der Hauptvorteil des Router Mesh Model ist ein effizienterer und robusterer Lastausgleich zwischen den Diensten. Wenn Sie NGINX Plus verwenden, können Sie aktive Zustandsprüfungen implementieren, um die einzelnen Dienstinstanzen zu überwachen und den Datenverkehr kontrolliert zu drosseln, wenn sie außer Betrieb genommen werden.

Deis Workflow verwendet einen dem Router-Mesh-Modell ähnlichen Ansatz, um Datenverkehr zwischen Diensten weiterzuleiten. Dabei werden NGINX-Instanzen in einem Container auf jedem Host ausgeführt. Wenn neue Anwendungsinstanzen gestartet werden, extrahiert ein Prozess Dienstinformationen aus der etcd-Dienstregistrierung und lädt sie in NGINX. NGINX Plus kann ebenfalls in diesem Modus betrieben werden und dabei verschiedene Locations und die zugehörigen Upstreams verwenden.

Anmerkung der Redaktion – Eine ausführliche Erläuterung dieses Modells finden Sie unter „MRA, Teil 3 – Das Router-Mesh-Modell“.

Und schließlich – das Fabric-Modell mit optionalem SSL/TLS

Wir bei NGINX sind vom Fabric Model besonders begeistert. Es lässt einige der spannendsten Versprechen von Microservices Wirklichkeit werden, darunter hohe Leistung, Flexibilität beim Load Balancing und durchgängiges SSL/TLS bis hinunter auf die Ebene einzelner Microservices. Das Fabric Model eignet sich für sichere Anwendungen und lässt sich für sehr große Anwendungen skalieren.

Beim Fabric Model wird NGINX Plus in jedem Container bereitgestellt und fungiert als Proxy für den gesamten ein- und ausgehenden HTTP-Datenverkehr der Container. Die Anwendungen stellen für alle Dienstverbindungen eine Verbindung zu einer localhost-Adresse her und überlassen NGINX Plus die Diensterkennung, den Lastenausgleich und die Zustandsprüfung.

In unserer Konfiguration fragt NGINX Plus bei ZooKeeper alle Instanzen der Dienste ab, mit denen die App eine Verbindung herstellen muss. Wenn beispielsweise für die DNS-Aktualisierungsfrequenz valid ein Wert von 1 Sekunde festgelegt ist, prüft NGINX Plus ZooKeeper jede Sekunde auf Änderungen an den Instanzen und leitet den Datenverkehr entsprechend weiter.

Dank der leistungsstarken HTTP-Verarbeitung in NGINX Plus können wir Keepalive-Verbindungen nutzen, um zustandsbehaftete Verbindungen zu Microservices aufrechtzuerhalten. Dadurch werden die Latenz reduziert und die Leistung verbessert. Diese Funktion ist besonders wertvoll, wenn SSL/TLS zur Absicherung des Datenverkehrs zwischen den Microservices eingesetzt wird.

Schließlich verwenden wir die aktiven Zustandsprüfungen von NGINX Plus, um den Datenverkehr an fehlerfreie Instanzen zu leiten und so im Wesentlichen das Circuit-Breaker-Muster ohne zusätzlichen Aufwand zu implementieren.

Anmerkung der Redaktion – Eine ausführliche Erläuterung dieses Modells finden Sie unter „MRA, Teil 4 – Das Fabric-Modell“.

Eine geniale Demo-App für die MRA

Die MRA enthält als Demo eine Beispielanwendung: die Foto-Sharing-App Ingenious. Ingenious ist in jedem der drei Modelle implementiert – Proxy, Router Mesh und Fabric. Die Ingenious-Demo-App wird im Laufe dieses Jahres veröffentlicht.

Ingenious ist eine vereinfachte Version einer Anwendung zum Speichern und Teilen von Fotos, ähnlich wie Flickr oder Shutterfly. Wir haben uns aus mehreren Gründen für eine Foto-Sharing-Anwendung entschieden:

• Sowohl Nutzer als auch Entwickler können leicht nachvollziehen, was die Anwendung macht.
• Es müssen mehrere Datendimensionen verwaltet werden.
• Ein ansprechendes Design lässt sich leicht in die App integrieren.
• Sie stellt asymmetrische Rechenanforderungen bereit – eine Mischung aus rechenintensiver und weniger rechenintensiver Verarbeitung – und ermöglicht so realistische Tests von Failover-, Skalierungs- und Überwachungsfunktionen für verschiedene Arten von Funktionalität.

Fazit

Die NGINX Microservices Reference Architecture ist eine spannende Entwicklung für uns sowie für die Kunden und Partner, denen wir sie bisher vorgestellt haben. In den nächsten Monaten werden wir eine Reihe von Blogbeiträgen veröffentlichen, in denen wir sie ausführlich beschreiben, und sie im Laufe dieses Jahres verfügbar machen. Außerdem werden wir sie ausführlich auf der nginx.conf 2016 vom 7. bis 9. September in Austin, Texas, vorstellen. Wir freuen uns auf Ihr Feedback und darauf, Sie dort zu sehen.

Testen Sie in der Zwischenzeit die MRA mit NGINX Plus selbst – starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.

Über den Autor

Chris Stetson

Weitere Blogbeiträge von Chris Stetson