Als Entwickler haben wir Microservices auf Azure Service Fabric geschrieben und können sie in Azure in einer Art PaaS-Konzept für viele Kunden ausführen. Aber einige unserer Kunden wollen nicht in der Cloud laufen, da Datenbanken lokal verfügbar sind und nicht von außen verfügbar sind, auch nicht über eine DMZ. Es ist in Ordnung, wir haben versprochen, es zu unterstützen, da Azure Service Fabric lokal als Cluster installiert werden kann.
Wir haben einen API-Gateway-Microservice im Cluster auf jeder virtuellen Maschine, der den Namens-Resolver verwendet, und Anforderungen werden weitergeleitet und verteilt, aber die API, die der API-Gateway-Microservice bietet, ist der Eingang für einen anderen Client Software, die unsere Kunden verwenden, diese Software läuft außerhalb des Clusters und muss Anfragen an die API senden.
Ich habe vorgeschlagen, einen Load Balancer wie HA-Proxy oder Nginx auf einem separaten Rechner (oder mehreren Rechnern) zu verwenden, an den die Client-Software ihre Anfragen sendet und der Reverse-Proxy ihn dann an einen verfügbaren Rechner innerhalb des Clusters weiterleitet. p>
Es scheint, dass unser Kunde das nicht möchte, eine andere Maschine als Load Balancer ist keine Option. Sie schlagen vor: Machen Sie die Client-Software intelligenter, um herauszufinden, welcher Host zu welchem Zweck verwendet wird, mit anderen Worten: Wir sollten unseren eigenen Failover / Load Balancer in der Client-Software schreiben.
Welche anderen Möglichkeiten haben wir?
Installieren Sie die Funktion Network Load Balancer auf jeder virtuellen Maschine, um dem Cluster eine einzige IP-Adresse zu geben. Ist dies überhaupt möglich? So etwas wie Ссылка
Schlagen Sie ein API-Gateway außerhalb des Clusters wie KONG Ссылка
Noch etwas?
PS: Die Client-Anwendungen senden nicht viele Anfragen pro Sekunde, vielleicht einige pro Minute.
Sehr ähnliches Problem, wir haben viele Dienste und einen Service Fabric-Cluster, der lokal ausgeführt wird. Wenn es Zeit ist, den Lastenausgleich zu verwenden, installieren wir IIS auf demselben Computer, auf dem der Service Fabric-Cluster ausgeführt wird. Da der IIS ein guter Lastenausgleich ist, verwenden wir IIS als Reverse-Proxy nur für API-Gateway. Kestrel-Hosting verwendet für andere Dienste, die über HTTP kommunizieren. Der API-Gateway-Microservice ist der einzige Einstiegspunkt für alle Clients und hat immer einen statischen URI in SF. Wir haben diesen URI zur Konfiguration von IIS verwendet
Wenn Sie keine Möglichkeit haben, IIS zu verwenden, sehen Sie sich nginx als HTTP-Lastenausgleich
Sie benötigen keine andere Maschine nur für die HTTP-Weiterleitung. Verwenden Sie / verwenden Sie es als Dienst auf dem Cluster.
Haben Sie in Betracht gezogen, den integrierten Reverse Proxy des Dienstes zu verwenden? Stoff? Dies wird auf allen Knoten ausgeführt und leitet HTTP-Aufrufe an Dienste innerhalb des Clusters weiter.
Sie können nginx auch als Gast-Programm oder in einem Container auf dem Cluster .
Wir hatten auch die gleiche Situation, als wir mit dem Service-Fabric-Cluster arbeiteten. Wir haben Application Gateway als Proxy konfiguriert, aber es würde nicht die Funktion wie HTTP zur HTTPS-Umleitung bereitstellen.
Dafür haben wir Nginx anstelle von Azure Application Gateway als Proxy für die Service Fabric-Anwendung konfiguriert.
Tags und Links azure nginx azure-service-fabric internal-load-balancer