Einführung der Microservices-Referenzarchitektur von NGINX

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

1. Einführung in die NGINX Microservices-Referenzarchitektur (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: Anpassen der Twelve‑Factor‑App für Microservices
6. MRA, Teil 6: Implementieren des Circuit Breaker-Musters mit NGINX Plus

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

Schauen Sie sich auch diese anderen NGINX-Ressourcen zu Microservices an:

• Eine sehr nützliche und beliebte Serie von Chris Richardson über das Design von Microservices-Anwendungen
• Die Artikel von Chris Richardson in einem kostenlosen E-Book zusammengefasst, mit zusätzlichen Tipps zur Implementierung von Microservices mit NGINX und NGINX Plus
• Weitere Blogbeiträge zu Microservices
• Microservices-Webinare
• Seite „Microservices-Lösungen“
• Thema: Mikrodienste

Einführung

NGINX war von Anfang an an der Microservices-Bewegung beteiligt. Die leichte, leistungsstarke und flexible Natur von NGINX eignet sich hervorragend für Microservices.

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

Wir sind davon überzeugt, dass die Umstellung auf Microservices für den Erfolg unserer Kunden von entscheidender Bedeutung ist. Daher haben wir bei NGINX ein spezielles Programm gestartet, um Funktionen und Verfahren zu entwickeln, die diesen grundlegenden Wandel bei der Entwicklung und Bereitstellung von Webanwendungen unterstützen. Wir sind uns auch bewusst, dass es viele unterschiedliche Ansätze zur Implementierung von Microservices gibt, von denen viele neuartig und auf die Anforderungen einzelner Entwicklungsteams zugeschnitten sind. Wir glauben, dass es Bedarf an Modellen gibt, die es Unternehmen einfacher machen, ihre eigenen auf Microservices basierenden Anwendungen zu entwickeln und bereitzustellen.

Vor diesem Hintergrund entwickeln wir hier bei NGINX Professional Services die NGINX Microservices Reference Architecture (MRA) – eine Reihe von Modellen, die Sie zum Erstellen Ihrer eigenen Microservices-Anwendungen verwenden können.

Der MRA besteht aus zwei Komponenten: einer detaillierten Beschreibung jedes der drei Modelle sowie herunterladbarem Code, der unser Beispielprogramm zum Teilen von Fotos, Ingenious, implementiert. Der einzige Unterschied zwischen den drei Modellen ist der Konfigurationscode, der zum Konfigurieren von NGINX Plus für jedes von ihnen verwendet wird. In dieser Blog-Beitragsreihe erhalten Sie Übersichtsbeschreibungen zu den einzelnen Modellen. Detaillierte Beschreibungen, Konfigurationscode und Code für das Ingenious-Beispielprogramm werden im Laufe des Jahres verfügbar gemacht.

Mit dem Aufbau dieser Referenzarchitektur verfolgen wir drei Ziele:

• Um Kunden und der Branche einsatzbereite Blaupausen für den Aufbau von Microservices-basierten Systemen bereitzustellen und so die Entwicklung zu beschleunigen und zu verbessern.
• Schaffung einer Plattform zum Testen neuer Funktionen in NGINX und NGINX Plus, unabhängig davon, ob diese intern oder extern entwickelt und im Produktkern oder als dynamische Module verteilt werden.
• Um uns dabei zu helfen, Partnersysteme und -komponenten zu verstehen, damit wir eine ganzheitliche Perspektive auf das Microservices-Ökosystem gewinnen können

Die Microservices Reference Architecture ist auch ein wichtiger Bestandteil des professionellen Serviceangebots für NGINX-Kunden. Im MRA verwenden wir, soweit möglich, Funktionen, die sowohl bei NGINX Open Source als auch bei NGINX Plus üblich sind, und bei Bedarf NGINX Plus-spezifische Funktionen. Wie unten beschrieben, sind die NGINX Plus-Abhängigkeiten in den komplexeren Modellen stärker. Wir gehen davon aus, dass viele Benutzer des MRA vom Zugriff auf professionelle NGINX-Dienste und technischen Support profitieren werden, der mit einem NGINX Plus-Abonnement einhergeht.

Ein Überblick über die Microservices-Referenzarchitektur

Wir erstellen die Referenzarchitektur so, dass sie den Prinzipien der Zwölf-Faktoren-App entspricht. Die Dienste sind so konzipiert, dass sie leichtgewichtig, flüchtig und zustandslos sind.

Der MRA verwendet Industriestandardkomponenten wie Docker-Container, eine breite Palette von Sprachen – Java, PHP, Python, NodeJS/JavaScript und Ruby – sowie NGINX-basierte Netzwerke.

Eine der größten Änderungen im Anwendungsdesign und in der Architektur bei der Umstellung auf Microservices ist die Verwendung des Netzwerks zur Kommunikation zwischen den Funktionskomponenten der Anwendung. In monolithischen Apps kommunizieren Anwendungskomponenten im Speicher. In einer Microservices-App erfolgt die Kommunikation über das Netzwerk. Daher sind Netzwerkdesign und -implementierung von entscheidender Bedeutung.

Um dies zu berücksichtigen, wurde der MRA mithilfe von drei verschiedenen Netzwerkmodellen implementiert, die alle NGINX oder NGINX Plus verwenden. Sie reichen von relativ einfach bis hin zu funktionsreich und komplexer:

• Proxy-Modell – Ein einfaches Netzwerkmodell, das sich für die Implementierung 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 Ansatz für die Vernetzung mit einem Load Balancer auf jedem Host und Verwaltung der Verbindungen zwischen Systemen. Dieses Modell ähnelt der Architektur von Deis 1.0 .
• Fabric-Modell – Das Kronjuwel des MRA, das Fabric-Modell, verfügt über NGINX Plus in jedem Container und verarbeitet den gesamten ein- und ausgehenden Datenverkehr. Es funktioniert gut für Systeme mit hoher Auslastung und unterstützt SSL/TLS auf allen Ebenen, wobei NGINX Plus reduzierte Latenz, dauerhafte SSL/TLS-Verbindungen, Diensterkennung und das Circuit-Breaker-Muster für alle Microservices bietet.

Wir möchten, dass Sie diese Modelle als Ausgangspunkt für Ihre eigenen Microservices-Implementierungen verwenden und freuen uns über Ihr Feedback zur Verbesserung des MRA. (Sie können beginnen, indem Sie die Kommentare unten ergänzen.)

Es folgt eine kurze Beschreibung jedes Modells. Wir empfehlen Ihnen, alle Beschreibungen zu lesen, um eine Vorstellung davon zu bekommen, wie Sie eines oder mehrere der Modelle am besten verwenden können. In zukünftigen Blogbeiträgen wird jedes Modell ausführlich beschrieben, einer pro Blogbeitrag.

Das Proxy-Modell in Kürze

Das Proxy-Modell ist ein relativ einfaches Netzwerkmodell. Es ist ein hervorragender Ausgangspunkt für eine erste Microservices-Anwendung oder als Zielmodell für die Konvertierung einer mäßig komplexen monolithischen Legacy-App.

Im Proxy-Modell fungiert NGINX oder NGINX Plus als Ingress-Controller und leitet Anfragen an Microservices weiter. NGINX Plus kann beim Erstellen neuer Dienste dynamisches DNS zur Diensterkennung verwenden. Das Proxy-Modell eignet sich auch als Vorlage für die Nutzung von NGINX als API-Gateway .

Wenn eine Kommunikation zwischen Diensten erforderlich ist – und dies ist bei den meisten Anwendungen unabhängig von der Komplexität der Fall – stellt das Dienstregister den Mechanismus innerhalb des Clusters bereit. (Eine detaillierte Liste der Kommunikationsmechanismen 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 den DNS ab und erhält eine IP-Adresse, an die eine Anfrage gesendet werden kann.

Im Allgemeinen ist das Proxy-Modell für einfache bis mäßig komplexe Anwendungen geeignet. Dies ist nicht der effizienteste Ansatz/das effizienteste Modell für den Lastenausgleich, insbesondere bei großem Maßstab. Verwenden Sie eines der unten beschriebenen Modelle, wenn Sie hohe Anforderungen an den Lastenausgleich haben. („Maßstab“ kann sich sowohl auf eine große Anzahl von Mikrodiensten als auch auf hohe Verkehrsmengen beziehen.)

Herausgeber – Eine ausführliche Untersuchung dieses Modells finden Sie unter MRA, Teil 2 – Das Proxy-Modell .

Umstellung auf das Router-Mesh-Modell

Das Router-Mesh-Modell weist eine mittlere Komplexität auf und eignet sich gut für robuste neue Anwendungsdesigns sowie für die Konvertierung komplexerer, monolithischer Legacy-Apps, die die Funktionen des Fabric-Modells nicht benötigen.

Das Router-Mesh-Modell verfolgt einen robusteren Ansatz zur Vernetzung als das Proxy-Modell, indem auf jedem Host ein Load Balancer ausgeführt wird und die Verbindungen zwischen den Microservices aktiv verwaltet werden. Der Hauptvorteil des Router-Mesh-Modells ist ein effizienterer und robusterer Lastausgleich zwischen Diensten. Wenn Sie NGINX Plus verwenden, können Sie aktive Integritätsprüfungen implementieren, um die einzelnen Serviceinstanzen zu überwachen und den Datenverkehr bei ihrer Abschaltung ordnungsgemäß zu drosseln.

Deis Workflow verwendet einen dem Router Mesh Model ähnlichen Ansatz, um den Datenverkehr zwischen Diensten zu leiten, wobei NGINX-Instanzen in einem Container auf jedem Host ausgeführt werden. Wenn neue App-Instanzen hochgefahren werden, extrahiert ein Prozess Serviceinformationen aus dem etcd -Serviceregister und lädt sie in NGINX. NGINX Plus kann ebenfalls in diesem Modus arbeiten und dabei verschiedene Standorte und die zugehörigen Upstreams verwenden.

Herausgeber – Eine ausführliche Untersuchung dieses Modells finden Sie unter MRA, Teil 3 – Das Router-Mesh-Modell .

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

Wir hier bei NGINX sind vom Fabric-Modell am meisten begeistert. Es erweckt einige der aufregendsten Versprechen von Microservices zum Leben, darunter hohe Leistung, Flexibilität beim Lastenausgleich und allgegenwärtiges SSL/TLS bis hinunter auf die Ebene einzelner Microservices. Das Fabric-Modell eignet sich für sichere Anwendungen und ist auf sehr große Anwendungen skalierbar.

Im Fabric-Modell wird NGINX Plus in jedem Container bereitgestellt und wird zum Proxy für den gesamten HTTP-Verkehr, der in die Container hinein und aus ihnen heraus geht. Die Anwendungen kommunizieren für alle Dienstverbindungen mit einem lokalen Hoststandort und verlassen sich bei der Diensterkennung, dem Lastenausgleich und der Integritätsprüfung auf NGINX Plus.

In unserer Konfiguration fragt NGINX Plus ZooKeeper nach allen Instanzen der Dienste ab, mit denen die App eine Verbindung herstellen muss. Wenn die gültige DNS-Frequenzeinstellung beispielsweise auf 1 Sekunde eingestellt ist, durchsucht NGINX Plus ZooKeeper jede Sekunde nach Instanzänderungen und leitet den Datenverkehr entsprechend weiter.

Dank der leistungsstarken HTTP-Verarbeitung in NGINX Plus können wir Keepalives verwenden, um zustandsbehaftete Verbindungen zu Microservices aufrechtzuerhalten und so die Latenz zu reduzieren und die Leistung zu verbessern. Dies ist eine besonders wertvolle Funktion, wenn SSL/TLS zum Sichern des Datenverkehrs zwischen den Microservices verwendet wird.

Schließlich nutzen wir die aktiven Integritätsprüfungen von NGINX Plus, um den Datenverkehr zu fehlerfreien Instanzen zu verwalten und bauen das Circuit-Breaker-Muster im Wesentlichen kostenlos ein.

Herausgeber – Eine ausführliche Untersuchung dieses Modells finden Sie unter MRA, Teil 4 – Das Fabric-Modell .

Eine geniale Demo-App für die MRA

Der MRA enthält eine Beispielanwendung als Demo: die Foto-Sharing-App Ingenious. Ingenious ist in jedem der drei Modelle implementiert – Proxy, Router Mesh und Fabric. Die Ingenious-Demo-App wird später in diesem Jahr der Öffentlichkeit zugänglich gemacht.

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 Anwendung zum Teilen von Fotos entschieden:

• Sowohl Benutzer als auch Entwickler können leicht verstehen, was es tut.
• Es müssen mehrere Datendimensionen verwaltet werden.
• Es ist einfach, ein schönes Design in die App zu integrieren.
• Es bietet asymmetrische Rechenanforderungen – eine Mischung aus hochintensiver und niedrigintensiver Verarbeitung –, die realistische Tests der Failover-, Skalierungs- und Überwachungsfunktionen für verschiedene Funktionstypen ermöglichen.

Abschluss

Die NGINX Microservices Reference Architecture ist eine spannende Entwicklung für uns und für die Kunden und Partner, mit denen wir sie bisher geteilt haben. Wir werden im Laufe der nächsten Monate eine Reihe von Blogbeiträgen veröffentlichen, in denen wir es im Detail beschreiben, und es später in diesem Jahr verfügbar machen. Wir werden es auch ausführlich auf der nginx.conf 2016 vom 7. bis 9. September in Austin, Texas, besprechen. Bitte geben Sie uns Ihr Feedback, wir freuen uns darauf, Sie zu sehen.

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