Microservices Architektur in NodeJS

8

Ich habe an einem Nebenprojekt gearbeitet und ich habe mein Skelton-Projekt als Microservices neu gestaltet, bis jetzt habe ich kein Open Source-Projekt gefunden, das diesem Muster folgt. Nach viel lesen und suchen schließe ich zu diesem Design, aber ich habe noch einige Fragen und Gedanken.

Hier sind meine Fragen und Gedanken:

  • Wie kann ich das API-Gateway intelligent genug machen, um die Anfrage zu laden, wenn ich 2 Knoten vom selben Microservice habe?
  • wenn einer der Microservice down ist wie die Entdeckung wissen sollte?
  • Gibt es eine ähnliche Implementierung? ist mein Design richtig?
  • sollte ich Eureka oder ähnliche Dinge verwenden?
Sideeq Youssef 06.11.2016, 09:54
quelle

2 Antworten

5

Ihr Design scheint in Ordnung zu sein. Wir bauen auch unser Microservice-Projekt mit API-Gateway-Ansatz. Alle Dienste einschließlich des Gateway-Dienstes (GW) sind containerisiert (wir verwenden docker) Java-Anwendungen ( Spring-Boot oder Dropwizard ). Eine ähnliche Architektur könnte auch mit nodejs erstellt werden. Einige Themen zu Ihrer Frage:

  • Authentifizierung / Autorisierung: Der GW-Dienst ist der einzige Einstiegspunkt für die Clients. Alle Authentifizierungs- / Autorisierungsvorgänge werden im GW mithilfe von JSON-Webtoken (JWT) abgewickelt, die ebenfalls über nodejs libray verfügen. Wir behalten Berechtigungsinformationen wie Benutzerrollen im JWT-Token. Sobald das Token im GW generiert und an den Client zurückgegeben wurde, sendet der Client bei jeder Anforderung das Token im HTTP-Header. Anschließend prüfen wir das Token, ob der Client die erforderliche Rolle hat, um den bestimmten Service anzurufen, oder das Token abgelaufen ist. Bei diesem Ansatz müssen Sie die Benutzersitzung auf der Serverseite nicht verfolgen. Eigentlich gibt es keine Sitzung. Die erforderlichen Informationen befinden sich im JWT-Token.
  • Service Discovery / Lastverteilung: Wir verwenden docker , docker swarm , das ein Docker-Engine-Clustering-Tool in der docker engine ist (nach docker v.12.1 ). Unsere Dienstleistungen sind Docker Container. Containerized Approach mit Docker macht es einfach, die Dienste bereitzustellen, zu warten und zu skalieren. Zu Beginn des Projekts verwendeten wir Haproxy, Registrator und Consul , um Service Discovery und Load Balancing ähnlich wie bei Ihrer Zeichnung zu implementieren. Dann haben wir festgestellt, dass wir sie zur Serviceerkennung und zum Lastenausgleich nicht benötigen, solange wir ein Docker-Netzwerk erstellen und unsere Services mit docker swarm bereitstellen. Mit diesem Ansatz können Sie problemlos isolierte Umgebungen für Ihre Dienste wie dev, beta, prod auf einer oder mehreren Maschinen erstellen, indem Sie für jede Umgebung unterschiedliche Netzwerke erstellen. Nachdem Sie das Netzwerk erstellt und Dienste bereitgestellt haben, geht es nicht mehr um Service Discovery und Load Balancing. In demselben Andocknetzwerk hat jeder Container die DNS-Einträge anderer Container und kann mit ihnen kommunizieren. Mit Docker-Schwarm können Sie Dienste mit einem Befehl problemlos skalieren. Bei jeder Anfrage an einen Dienst verteilt der Docker die Anfrage an eine Instanz des Dienstes (load balances).
sezerug 16.03.2017 14:20
quelle
3

Ihr Design ist in Ordnung.

  1. Wenn Ihr API-Gateway CAS (eine Art von Auth) implementieren muss (und das ist wahrscheinlich der Fall), sollte es auch alle Anfragen verfolgen und die Header ändern die Requester-Metadaten zu tragen (für die interne ACL / Scoping-Nutzung) - Ihr API Gateway sollte in Node ausgeführt werden, sollte aber unter Haproxy sein, das sich um Load-Balancing / HTTPS kümmert

  2. Discovery ist in der richtigen Position - wenn Sie einen suchen, der zu Ihrem Design passt, schauen Sie nirgendwo hin, außer in Konsul .

  3. Sie können consul-template verwenden oder ein eigenes micro-discovery-framework für die Dienste und das API-Gateway verwenden, damit sie beim Booten die Endpunktdaten teilen.

  4. Die ACL / Autorisierung sollte pro Service implementiert werden, und die erste Anfrage von API Gateway sollte von allen Autorisierungen der Middleware abhängig sein.

  5. Es ist schlau, die Anfragen zu verfolgen, wenn das API-Gateway eine Anforderungs-ID für jede Anfrage bereitstellt, damit der Lebenszyklus innerhalb des "inneren" Systems verfolgt werden kann.

  6. Ich würde Redis für Messaging / Worker / Queues / schnelle In-Memory-Sachen wie Cache / Cache Invalidation hinzufügen (Sie können nicht alle MS-Architektur ohne eine behandeln) - oder nehmen RabbitMQ, wenn Sie viel mehr verteilte Transaktion haben und viele Nachrichten

  7. Schleudern Sie alles auf Containern (Docker), so dass es einfacher zu warten und zu montieren ist.

  8. Was BI betrifft, warum brauchen Sie dafür einen Service? Sie könnten externe ELK Elastisearch, Logstash, Kibana) und Dashboards, Log Aggregation und riesige Big Data Warehouse auf einmal haben.

BlackStork 11.03.2017 20:54
quelle

Tags und Links