Wie verwende ich Load Balancer Route Verkehr zu REST-basierten statuslosen Diensten, die nicht auf allen Knoten eines bestimmten Knotentyps verteilt

Question

sagen, ich habe einen Service-Fabric-Cluster mit einem Knoten Typ, der 5 Knoten hat, und zwei statusfreie Dienste auf denen 5 Knoten, aber ich würde service_1 auf 3 Knoten und service_2 auf 2 anderen Knoten bereitstellen.

Ich verstehe, dass ein Knoten Typ ist eigentlich ein VMSS und Azure wird ein Load Balancer auf dem VMSS erstellen. Er funktioniert perfekt auf dem statuslosen REST-Dienst, der sich auf alle Knoten eines bestimmten Knotentyps ausbreitet.

Aber in meinem Fall, der Dienst auf einem Teil der Knoten implementiert, kann ich noch den Load Balancer nutzen, um zu Instanzen von zwei separaten Diensten zu routen?

Answer 1

Sie haben mehrere Möglichkeiten:

• Verwenden Sie die von Service-Fabric in HTTP-Gateway-Service aufgebaut. Leider habe ich dazu noch keine Dokumentation gefunden, daher kenne ich die Vor- und Nachteile dieser Lösung nicht. Details finden Sie unter this comment im Projekt service-fabric-issues.

• Implementieren Sie Ihren eigenen statuslosen Gateway-Dienst, der einen InstanceCount von -1 hat (was bedeutet, dass er auf jedem Knoten platziert wird). Dieser Dienst verhält sich wie ein interner Load Balancer und leitet jede Anfrage an den richtigen Dienst weiter. Siehe weidazhao's (ein Microsoft-Mitarbeiter - dieses Projekt könnte Teil des SDK werden) oder our project für vorhandene Gateway-Projekte.

• Verwenden Sie weiterhin einen Lastenausgleich, der auf den gesamten Maßstab verweist, und verwenden Sie Testmethoden, um den Lastenausgleich Knoten deaktivieren zu lassen, auf denen der Dienst nicht ausgeführt wird. Im Falle von Platzierungsänderungen führt dies jedoch zu fehlgeschlagenen Anforderungen, bis der Load Balancer es ermittelt.

• Erstellen Sie separate Knotentypen (VM-Scale-Sets) für jeden Service und erstellen Sie einen separaten Load Balancer für jeden Knotentyp. Dies führt jedoch zu einem Verwaltungsaufwand und ist möglicherweise nicht ideal für die Ressourcennutzung.

Es gibt eine offene feature suggestion für dieses Thema auf der Azure Uservoice Website - Ihre Stimmen wäre willkommen.