Service Fabric Reverse-Proxy Einstellung des Stateful-Service-Ports

Question

Ich habe erfolgreich einen Cluster in Azure implementiert, wobei der Reverse Proxy auf allen Knoten aktiviert ist und https funktioniert. Dies ist ein Cluster mit mehreren Mandanten, jeder Mandanten hat seine eigene Anwendung und einige der statusbehafteten Dienste können einige Web-Sockets verwalten.

Ich habe es geschafft, eine Instanz von Turmfalke lokal für websockets arbeiten, aber in Azure bekomme ich nur 404s. Ich denke, meine Port-Konfiguration ist falsch. Ich habe die gesamte Reverse-Proxy-Dokumentation gelesen, kann aber immer noch nichts herausfinden.

Q1 Müssen alle Zuhörer im zustandsbehafteten Dienst, die Nachrichten vom Reverseproxy empfangen möchten, auf 19081 hören? Ich hätte gedacht, aber die documentation setzt zufällig einen anderen Port (10592?) Und eine super lange ID als eine Art von Bezeichner (die ich glaube, ist die PartitionId und ReplicaId kombiniert), ohne Erklärung, wie es den Namen zuordnen würde an den Abhörport im Naming Service.

Als Beispiel nehmen wir den Stoff nehmen:/MyApp/MyService Dienst dass einen HTTP-Listener auf die folgende URL öffnet:

http://10.0.0.5:10592/3f0d39ad-924b-4233-b4a7-02617c6308a6-130834621071472715/

Bin ich meinte diese super zu verwenden lange id als die hörende Adresse? Ich denke, das bedeutet, Turmfalke ist out - da mehrere versuchen können, auf dem gleichen Knoten zu hören, aber ich kann vielleicht einen Web/Http Listener verwenden, damit ich den Port teilen kann.

Q2 Ist es zwingend erforderlich, einen Listener zu erstellen, wenn der Dienst nur auf den Reverseproxy hören soll. ListenerName scheint wie ein notwendiger Parameter in der URI-Formatierung für Adressierungsdienste. Ist es in diesem Fall nicht möglich, dynamisch erzeugte Hosts aufzurufen? (z. B. WCF-Diensthosts), die generierte Pfade überwachen, z. B. https://fabric:19081/MyApp/MySvc/SomeWcfPath1.

Happy (gebrochen) Code zu schreiben, aber ich denke, das ist eher ein konzeptionelles Problem ist, und sobald ich die Einschränkungen/zugrundeliegenden Architektur besser zu verstehen, kann ich es lösen mich

Grüße

Answer 1

Der Grund, warum Sie das sehen Die superlange URL für Stateful-Services liegt darin, dass Sie in vielen Fällen mehrere Partitionen und Replikate auf demselben Knoten haben. Die Standard Beispiele/templates tun wahrscheinlich eine Konvention von:

http://+:port/partition/replica/newGuid 

Betrachten Sie den folgenden Fall: Sie haben eine Stateful-Service mit zwei Partitionen, die sowohl eine primäre Replikat und zwei sekundäre Repliken haben.

Partition 1: 2446223d-5998-45f3-90fc-2d9705bedb1d 
Partition 2: 7af3a1f0-7845-4003-b192-6a8b64cc47fd 

Sie können Ihre sekundären Replikate einrichten, um die Kommunikation zu öffnen. Wenn Sie nur die Partition-ID als der Hörposition Adresse verwendet dann haben Sie die folgenden Schritte aus:

http://10.10.10.1:19081/2446223d-5998-45f3-90fc-2d9705bedb1d (Primary) 
http://10.10.10.1:19081/2446223d-5998-45f3-90fc-2d9705bedb1d (Secondary) 
http://10.10.10.1:19081/2446223d-5998-45f3-90fc-2d9705bedb1d (Secondary) 
http://10.10.10.1:19081/7af3a1f0-7845-4003-b192-6a8b64cc47fd (Primary) 
http://10.10.10.1:19081/7af3a1f0-7845-4003-b192-6a8b64cc47fd (Secondary) 
http://10.10.10.1:19081/7af3a1f0-7845-4003-b192-6a8b64cc47fd (Secondary) 

Auf einem fünf Knoten-Cluster Sie den gleichen Zuhörer auf einem einzelnen Knoten haben werden, so dass ein Konflikt ist. Du musst es also noch einzigartiger machen, indem du etwas anderes hinzufügst. Die Standardimplementierung OwinCommunicationListener in der statusfreien Web-API-Vorlage verwendet partitionId, replicaId und eine zufällige GUID. Ich glaube nicht, dass Partition + Replikat genug ist, um einzigartig zu sein, deshalb fügen sie dem Pfad eine zufällige GUID hinzu.