Freigeben über

Serverkonfiguration

Konfigurieren Sie ein Silo programmgesteuert mithilfe der UseOrleans(IHostBuilder, Action<HostBuilderContext,ISiloBuilder>) Erweiterungsmethode und mehrerer ergänzender Optionsklassen. Optionsklassen folgen Orleans dem Optionsmuster in .NET und können aus Dateien, Umgebungsvariablen oder einem anderen gültigen Konfigurationsanbieter geladen werden.

Es gibt mehrere wichtige Aspekte der Silokonfiguration:

  • Clusteringanbieter
  • (Optional) Orleans Clusterinformationen
  • (Optional) Endpunkte für Silo-zu-Silo- und Client-zu-Silo-Kommunikation

Dieses Beispiel zeigt eine Silokonfiguration, die Clusterinformationen definiert, Azure-Clustering verwendet und Anwendungsteile konfiguriert:

using IHost host = Host.CreateDefaultBuilder(args)
    .UseOrleans(builder =>
    {
        builder.UseAzureStorageClustering(
            options => options.ConfigureTableServiceClient(connectionString));
    })
    .UseConsoleLifetime()
    .Build();

Tipp

Bei der Entwicklung für Orleanskönnen Sie aufrufen UseLocalhostClustering(ISiloBuilder, Int32, Int32, IPEndPoint, String, String) , um einen lokalen Cluster zu konfigurieren. In Produktionsumgebungen sollten Sie einen Clusteringanbieter verwenden, der für Ihre Bereitstellung geeignet ist.

Clusteringanbieter

siloBuilder.UseAzureStorageClustering(
    options => options.ConfigureTableServiceClient(connectionString))

In der Regel stellen Sie einen Dienst bereit, der auf Orleans einem Cluster von Knoten basiert, entweder auf dedizierter Hardware oder in der Cloud. Für Entwicklung und grundlegende Tests können Sie Orleans in einer Konfiguration mit einem einzigen Knoten bereitstellen. Bei der Bereitstellung in einem Cluster von Knoten wird Orleans intern zur Implementierung von Protokollen verwendet, um die Mitgliedschaft der Orleans Silos im Cluster zu ermitteln und zu verwalten, einschließlich der Erkennung von Knotenfehlern sowie der automatischen Neukonfiguration.

Für eine zuverlässige Clustermitgliedschaftsverwaltung Orleans verwendet Azure Table, SQL Server oder Apache ZooKeeper für die Knotensynchronisierung.

In diesem Beispiel verwenden wir Azure Table als Mitgliedschaftsanbieter.

Orleans Clusterinformationen

Um das Clustering optional zu konfigurieren, verwenden Sie ClusterOptions den Typparameter für die Methode für die ConfigureISiloBuilder Instanz.

siloBuilder.Configure<ClusterOptions>(options =>
{
    options.ClusterId = "my-first-cluster";
    options.ServiceId = "SampleApp";
})

Hier geben Sie zwei Optionen an:

  • Legen Sie folgendes ClusterId Fest: "my-first-cluster"Dies ist eine eindeutige ID für den Orleans Cluster. Alle Kunden und Silos, die diese ID verwenden, können direkt miteinander kommunizieren. Sie können jedoch eine andere ClusterId für verschiedene Bereitstellungen verwenden.
  • Setzen Sie ServiceId auf "SampleApp": Dies ist eine eindeutige ID für Ihre Anwendung, die von einigen Anbietern verwendet wird, z. B. Persistenzanbieter. Diese ID sollte stabil bleiben und sich nicht über Bereitstellungen hinweg ändern.

Standardmäßig verwendet Orleans"default" für ServiceId und ClusterId. Diese Werte müssen in den meisten Fällen nicht geändert werden. ServiceId ist wichtiger und unterscheidet unterschiedliche logische Dienste, sodass sie Back-End-Speichersysteme ohne Störungen teilen können. ClusterId bestimmt, welche Hosts eine Verbindung mit einem Cluster herstellen.

In jedem Cluster müssen alle Hosts dasselbe ServiceIdverwenden. Mehrere Cluster können jedoch ein ServiceId gemeinsam nutzen. Dies ermöglicht Blau-/Grün-Bereitstellungsszenarien, in denen Sie eine neue Bereitstellung (Cluster) starten, bevor Sie eine andere herunterfahren. Dies ist typisch für Systeme, die in Azure App Service gehostet werden.

Der häufigere Fall ist, dass ServiceId und ClusterId für die Lebensdauer der Anwendung fest bleiben und Sie eine rollierende Bereitstellungsstrategie verwenden. Dies ist typisch für Systeme, die in Kubernetes und Service Fabric gehostet werden.

Endpunkte

Standardmäßig hört Orleans auf allen Schnittstellen am Port 11111 für die Silo-zu-Silo-Kommunikation und am Port 30000 für die Client-zu-Silo-Kommunikation. Um dieses Verhalten außer Kraft zu setzen, rufen Sie ConfigureEndpoints(ISiloBuilder, Int32, Int32, AddressFamily, Boolean) auf und übergeben die gewünschten Portnummern.

siloBuilder.ConfigureEndpoints(siloPort: 17_256, gatewayPort: 34_512)

Im vorhergehenden Code:

  • Der Silohafen ist auf 17_256.
  • Der Gatewayport ist auf 34_512.

Ein Orleans Silo verfügt über zwei typische Arten von Endpunktkonfigurationen:

  • Silo-zu-Silo-Endpunkte: Wird für die Kommunikation zwischen Silos im selben Cluster verwendet.
  • Client-zu-Silo-Endpunkte (oder Gateway-Endpunkte): Wird für die Kommunikation zwischen Clients und Silos im selben Cluster verwendet.

Diese Methode sollte in den meisten Fällen ausreichen, aber Sie können sie bei Bedarf weiter anpassen. Hier ist ein Beispiel für die Verwendung einer externen IP-Adresse mit Portweiterleitung:

siloBuilder.Configure<EndpointOptions>(options =>
{
    // Port to use for silo-to-silo
    options.SiloPort = 11_111;
    // Port to use for the gateway
    options.GatewayPort = 30_000;
    // IP Address to advertise in the cluster
    options.AdvertisedIPAddress = IPAddress.Parse("172.16.0.42");
    // The socket used for client-to-silo will bind to this endpoint
    options.GatewayListeningEndpoint = new IPEndPoint(IPAddress.Any, 40_000);
    // The socket used by the gateway will bind to this endpoint
    options.SiloListeningEndpoint = new IPEndPoint(IPAddress.Any, 50_000);
})

Intern hört das Silo auf 0.0.0.0:40000 und 0.0.0.0:50000, aber der Wert, der im Mitgliedschaftsanbieter veröffentlicht wird, ist 172.16.0.42:11111 und 172.16.0.42:30000.

Konfigurieren Sie ein Silo programmgesteuert über SiloHostBuilder und mehrere ergänzende Optionsklassen. Optionsklassen folgen Orleans dem Optionsmuster in .NET und können aus Dateien, Umgebungsvariablen oder einem anderen gültigen Konfigurationsanbieter geladen werden.

Es gibt mehrere wichtige Aspekte der Silokonfiguration:

  • Orleans Clusterinformationen
  • Clusteringanbieter
  • Endpunkte für Silo-zu-Silo- und Client-zu-Silo-Kommunikation
  • Teile der Anwendung

Dieses Beispiel zeigt eine Silokonfiguration, die Clusterinformationen definiert, Azure-Clustering verwendet und Anwendungsteile konfiguriert:

var silo = Host.CreateDefaultBuilder(args)
    .UseOrleans(builder =>
    {
        builder
            .UseAzureStorageClustering(
                options => options.ConnectionString = connectionString)
            .Configure<ClusterOptions>(options =>
            {
                options.ClusterId = "my-first-cluster";
                options.ServiceId = "AspNetSampleApp";
            })
            .ConfigureEndpoints(siloPort: 11111, gatewayPort: 30000)
            .ConfigureApplicationParts(
                parts => parts.AddApplicationPart(typeof(ValueGrain).Assembly).WithReferences())
    })
    .UseConsoleLifetime()
    .Build();

Lassen Sie uns die in diesem Beispiel verwendeten Schritte aufschlüsseln:

Clusteringanbieter

siloBuilder.UseAzureStorageClustering(
    options => options.ConnectionString = connectionString)

In der Regel stellen Sie einen Dienst bereit, der auf Orleans einem Cluster von Knoten basiert, entweder auf dedizierter Hardware oder in der Cloud. Für Entwicklung und grundlegende Tests können Sie Orleans in einer Konfiguration mit einem einzigen Knoten bereitstellen. Bei der Bereitstellung in einem Cluster von Knoten wird Orleans intern zur Implementierung von Protokollen verwendet, um die Mitgliedschaft der Orleans Silos im Cluster zu ermitteln und zu verwalten, einschließlich der Erkennung von Knotenfehlern sowie der automatischen Neukonfiguration.

Für eine zuverlässige Clustermitgliedschaftsverwaltung Orleans verwendet Azure Table, SQL Server oder Apache ZooKeeper für die Knotensynchronisierung.

In diesem Beispiel verwenden wir Azure Table als Mitgliedschaftsanbieter.

Orleans Clusterinformationen

.Configure<ClusterOptions>(options =>
{
    options.ClusterId = "my-first-cluster";
    options.ServiceId = "AspNetSampleApp";
})

Hier machen wir zwei Dinge:

  • Legen Sie folgendes ClusterId Fest: "my-first-cluster"Dies ist eine eindeutige ID für den Orleans Cluster. Alle Kunden und Silos, die diese ID verwenden, können direkt miteinander kommunizieren. Sie können jedoch eine andere ClusterId für verschiedene Bereitstellungen verwenden.
  • Setzen Sie ServiceId auf "AspNetSampleApp": Dies ist eine eindeutige ID für Ihre Anwendung, die von einigen Anbietern verwendet wird, z. B. Persistenzanbieter. Diese ID sollte stabil bleiben und sich nicht über Bereitstellungen hinweg ändern.

Standardmäßig verwendet Orleans"default" für ServiceId und ClusterId. Diese Werte müssen in den meisten Fällen nicht geändert werden. ServiceId ist wichtiger und unterscheidet unterschiedliche logische Dienste, sodass sie Back-End-Speichersysteme ohne Störungen teilen können. ClusterId bestimmt, welche Hosts eine Verbindung mit einem Cluster herstellen.

In jedem Cluster müssen alle Hosts dasselbe ServiceIdverwenden. Mehrere Cluster können jedoch ein ServiceId gemeinsam nutzen. Dies ermöglicht Blau-/Grün-Bereitstellungsszenarien, in denen Sie eine neue Bereitstellung (Cluster) starten, bevor Sie eine andere herunterfahren. Dies ist typisch für Systeme, die in Azure App Service gehostet werden.

Der häufigere Fall ist, dass ServiceId und ClusterId für die Lebensdauer der Anwendung fest bleiben und Sie eine rollierende Bereitstellungsstrategie verwenden. Dies ist typisch für Systeme, die in Kubernetes und Service Fabric gehostet werden.

Endpunkte

siloBuilder.ConfigureEndpoints(siloPort: 11111, gatewayPort: 30000)

Ein Orleans Silo verfügt über zwei typische Arten von Endpunktkonfigurationen:

  • Silo-zu-Silo-Endpunkte: Wird für die Kommunikation zwischen Silos im selben Cluster verwendet.
  • Client-zu-Silo-Endpunkte (oder Gateway): Wird für die Kommunikation zwischen Clients und Silos im selben Cluster verwendet.

Im Beispiel verwenden wir die Hilfsmethode .ConfigureEndpoints(siloPort: 11111, gatewayPort: 30000), die den Port für die Silo-zu-Silo-Kommunikation auf 11111 und den Gateway-Port auf 30000 setzt. Diese Methode erkennt, welche Schnittstelle abgehört werden soll.

Diese Methode sollte in den meisten Fällen ausreichen, aber Sie können sie bei Bedarf weiter anpassen. Hier ist ein Beispiel für die Verwendung einer externen IP-Adresse mit Portweiterleitung:

siloBuilder.Configure<EndpointOptions>(options =>
{
    // Port to use for silo-to-silo
    options.SiloPort = 11111;
    // Port to use for the gateway
    options.GatewayPort = 30000;
    // IP Address to advertise in the cluster
    options.AdvertisedIPAddress = IPAddress.Parse("172.16.0.42");
    // The socket used for client-to-silo will bind to this endpoint
    options.GatewayListeningEndpoint = new IPEndPoint(IPAddress.Any, 40000);
    // The socket used by the gateway will bind to this endpoint
    options.SiloListeningEndpoint = new IPEndPoint(IPAddress.Any, 50000);
})

Intern hört das Silo auf 0.0.0.0:40000 und 0.0.0.0:50000, aber der Wert, der im Mitgliedschaftsanbieter veröffentlicht wird, ist 172.16.0.42:11111 und 172.16.0.42:30000.

Teile der Anwendung

siloBuilder.ConfigureApplicationParts(
    parts => parts.AddApplicationPart(
        typeof(ValueGrain).Assembly)
        .WithReferences())

Obwohl dieser Schritt technisch nicht erforderlich ist (falls nicht konfiguriert, Orleans überprüft alle Assemblys im aktuellen Ordner), empfehlen wir Ihnen, sie zu konfigurieren. Dieser Schritt hilft, Orleans Benutzerassemblys und -typen zu laden. Diese Assemblys werden als Anwendungsteile bezeichnet. Orleans ermittelt alle Getreide-, Getreideschnittstellen- und Serialisierer mithilfe von Anwendungsteilen.

Konfigurieren Sie Anwendungsteile mit Hilfe von IApplicationPartManager, verfügbar über die Erweiterungsmethode ConfigureApplicationParts auf IClientBuilder und ISiloHostBuilder. Die ConfigureApplicationParts Methode akzeptiert eine Stellvertretung. Action<IApplicationPartManager>

Die folgenden Erweiterungsmethoden bei IApplicationPartManager unterstützen allgemeine Verwendungen:

Ergänzen Sie Assemblys, die von den oben genannten Methoden hinzugefügt werden, indem Sie die folgenden Erweiterungsmethoden für ihren Rückgabetyp verwenden: IApplicationPartManagerWithAssemblies

  • ApplicationPartManagerExtensions.WithReferences: Fügt alle referenzierten Assemblys aus den hinzugefügten Komponenten hinzu. Dadurch werden alle transitiv referenzierten Assemblys sofort geladen. Assemblyladefehler werden ignoriert.
  • ApplicationPartManagerCodeGenExtensions.WithCodeGeneration: Generiert Unterstützungscode für die hinzugefügten Teile und fügt ihn dem Webpart-Manager hinzu. Beachten Sie, dass dies die Installation des Microsoft.Orleans.OrleansCodeGenerator Pakets erfordert und häufig als Laufzeitcodegenerierung bezeichnet wird.

Für die Typermittlung müssen die bereitgestellten Anwendungsteile bestimmte Attribute enthalten. Das Hinzufügen des Buildzeitcodegenerierungspakets (Microsoft.Orleans.CodeGenerator.MSBuild oder Microsoft.Orleans.OrleansCodeGenerator.Build) zu jedem Projekt, das Grains, Grain Interfaces oder Serializer enthält, ist der empfohlene Ansatz, um sicherzustellen, dass diese Attribute vorhanden sind. Buildzeitcodegenerierung unterstützt nur C#. Für F#, Visual Basic und andere .NET-Sprachen können Sie Code während der Konfiguration über die WithCodeGeneration oben beschriebene Methode generieren. Weitere Informationen zur Codegenerierung finden Sie im entsprechenden Abschnitt.

  • Last updated on