Udostępnij za pośrednictwem

Konfiguracja serwera

  • Artykuł

Silos jest konfigurowany programowo za pomocą UseOrleans(IHostBuilder, Action<HostBuilderContext,ISiloBuilder>) metody rozszerzenia i kilku dodatkowych klas opcji. Klasy opcji w Orleans programie są zgodne ze wzorcem opcji na platformie .NET i mogą być ładowane za pośrednictwem plików, zmiennych środowiskowych i dowolnego prawidłowego dostawcy konfiguracji.

Istnieje kilka kluczowych aspektów konfiguracji silosu:

  • Dostawca klastrowania
  • (Opcjonalnie) Orleans informacje o klastrowaniu
  • (Opcjonalnie) Punkty końcowe do użycia na potrzeby komunikacji typu silos-to-silos i komunikacji typu klient-silos

Jest to przykład konfiguracji silosu, która definiuje informacje o klastrze, używa klastrowania platformy Azure i konfiguruje części aplikacji:

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

Napiwek

Podczas programowania dla Orleansprogramu można wywołać UseLocalhostClustering(ISiloBuilder, Int32, Int32, IPEndPoint, String, String) metodę w celu skonfigurowania klastra lokalnego. W środowiskach produkcyjnych należy użyć dostawcy klastrowania odpowiedniego dla danego wdrożenia.

Dostawca klastrowania

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

Zazwyczaj usługa oparta na Orleans systemie jest wdrażana w klastrze węzłów na dedykowanym sprzęcie lub w chmurze. Na potrzeby programowania i testowania Orleans podstawowego można wdrożyć w konfiguracji z jednym węzłem. Po wdrożeniu w klastrze węzłów Orleans wewnętrznie implementuje zestaw protokołów w celu odnajdywania i utrzymywania członkostwa silosów Orleans w klastrze, w tym wykrywania awarii węzłów i automatycznej ponownej konfiguracji.

Aby zapewnić niezawodne zarządzanie członkostwem w klastrze, Orleans do synchronizacji węzłów używa usługi Azure Table, SQL Server lub Apache ZooKeeper.

W tym przykładzie jest używana tabela platformy Azure jako dostawca członkostwa.

Orleans informacje o klastrowaniu

Aby opcjonalnie skonfigurować klastrowanie, użyj ClusterOptions jako parametru typu dla Configure metody w wystąpieniu ISiloBuilder .

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

W tym miejscu należy określić dwie opcje:

  • Ustaw wartość na ClusterId "my-first-cluster"wartość : jest to unikatowy identyfikator klastra Orleans . Wszyscy klienci i silosy używające tego identyfikatora będą mogli komunikować się bezpośrednio ze sobą. Możesz jednak użyć innego ClusterId rozwiązania dla różnych wdrożeń.
  • Ustaw wartość na ServiceId "SampleApp"wartość : jest to unikatowy identyfikator aplikacji, który będzie używany przez niektórych dostawców, takich jak dostawcy trwałości. Ten identyfikator powinien pozostać stabilny i nie zmieniać się we wszystkich wdrożeniach.

Domyślnie Orleans parametr będzie używać wartości "default" zarówno dla , jak ServiceId ClusterIdi . Te wartości nie muszą być zmieniane w większości przypadków. ServiceId jest bardziej znaczącym z tych dwóch elementów i służy do odróżnienia od siebie różnych usług logicznych, dzięki czemu mogą współużytkować systemy magazynowania zaplecza bez zakłócania siebie. ClusterId Służy do określania, które hosty będą łączyć się ze sobą i tworzyć klaster.

W każdym klastrze wszystkie hosty muszą używać tego samego ServiceIdelementu . Wiele klastrów może jednak współużytkować klaster ServiceId. Umożliwia to niebieskie/zielone scenariusze wdrażania, w których nowe wdrożenie (klaster) jest uruchamiane przed zamknięciem innego. Jest to typowe dla systemów hostowanych w usłudze aplikacja systemu Azure Service.

Bardziej typowym przypadkiem jest to, że ServiceId i ClusterId pozostaje stały dla okresu istnienia aplikacji i strategii wdrażania stopniowego jest używana. Jest to typowe dla systemów hostowanych na platformie Kubernetes i w usłudze Service Fabric.

Punkty końcowe

Domyślnie Orleans nasłuchuje wszystkich interfejsów na porcie dla komunikacji silos-to-silos i na porcie 30000 11111 na potrzeby komunikacji między klientem a silosem. Aby zastąpić to zachowanie, wywołaj ConfigureEndpoints(ISiloBuilder, Int32, Int32, AddressFamily, Boolean) i przekaż numery portów, których chcesz użyć.

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

Powyższy kod:

  • Port silosu ma wartość 17_256.
  • Port bramy jest ustawiony na 34_512wartość .

Silos Orleans ma dwa typowe typy konfiguracji punktu końcowego:

  • Punkty końcowe silosu do silosu są używane do komunikacji między silosami w tym samym klastrze.
  • Punkty końcowe typu klient-silos (lub brama) są używane do komunikacji między klientami i silosami w tym samym klastrze.

Ta metoda powinna być wystarczająca w większości przypadków, ale w razie potrzeby można ją jeszcze bardziej dostosować. Oto przykład użycia zewnętrznego adresu IP z pewnym przekazywaniem portów:

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);
})

Wewnętrznie silos będzie nasłuchiwać 0.0.0.0:40000 i 0.0.0.0:50000, ale wartość opublikowana w dostawcy członkostwa będzie i 172.16.0.42:11111 172.16.0.42:30000.

Silos jest konfigurowany programowo za pośrednictwem SiloHostBuilder i kilku dodatkowych klas opcji. Klasy opcji w Orleans programie są zgodne ze wzorcem opcji na platformie .NET i mogą być ładowane za pośrednictwem plików, zmiennych środowiskowych i dowolnego prawidłowego dostawcy konfiguracji.

Istnieje kilka kluczowych aspektów konfiguracji silosu:

  • Orleans informacje o klastrowaniu
  • Dostawca klastrowania
  • Punkty końcowe do użycia na potrzeby komunikacji typu silos-to-silos i komunikacji typu klient-silos
  • Części aplikacji

Jest to przykład konfiguracji silosu, która definiuje informacje o klastrze, używa klastrowania platformy Azure i konfiguruje części aplikacji:

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();

Przyjrzyjmy się krokom użytym w tym przykładzie:

Dostawca klastrowania

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

Zazwyczaj usługa oparta na Orleans systemie jest wdrażana w klastrze węzłów na dedykowanym sprzęcie lub w chmurze. Na potrzeby programowania i testowania Orleans podstawowego można wdrożyć w konfiguracji z jednym węzłem. Po wdrożeniu w klastrze węzłów Orleans wewnętrznie implementuje zestaw protokołów w celu odnajdywania i utrzymywania członkostwa silosów Orleans w klastrze, w tym wykrywania awarii węzłów i automatycznej ponownej konfiguracji.

Aby zapewnić niezawodne zarządzanie członkostwem w klastrze, Orleans do synchronizacji węzłów używa usługi Azure Table, SQL Server lub Apache ZooKeeper.

W tym przykładzie używamy usługi Azure Table jako dostawcy członkostwa.

Orleans informacje o klastrowaniu

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

W tym miejscu robimy dwie rzeczy:

  • Ustaw wartość na ClusterId "my-first-cluster"wartość : jest to unikatowy identyfikator klastra Orleans . Wszyscy klienci i silosy używające tego identyfikatora będą mogli komunikować się bezpośrednio ze sobą. Możesz jednak użyć innego ClusterId rozwiązania dla różnych wdrożeń.
  • Ustaw wartość na ServiceId "AspNetSampleApp"wartość : jest to unikatowy identyfikator aplikacji, który będzie używany przez niektórych dostawców, takich jak dostawcy trwałości. Ten identyfikator powinien pozostać stabilny i nie zmieniać się we wszystkich wdrożeniach.

Domyślnie Orleans parametr będzie używać wartości "default" zarówno dla , jak ServiceId ClusterIdi . Te wartości nie muszą być zmieniane w większości przypadków. ServiceId jest bardziej znaczącym z tych dwóch elementów i służy do odróżnienia od siebie różnych usług logicznych, dzięki czemu mogą współużytkować systemy magazynowania zaplecza bez zakłócania siebie. ClusterId Służy do określania, które hosty będą łączyć się ze sobą i tworzyć klaster.

W każdym klastrze wszystkie hosty muszą używać tego samego ServiceIdelementu . Wiele klastrów może jednak współużytkować klaster ServiceId. Umożliwia to niebieskie/zielone scenariusze wdrażania, w których nowe wdrożenie (klaster) jest uruchamiane przed zamknięciem innego. Jest to typowe dla systemów hostowanych w usłudze aplikacja systemu Azure Service.

Bardziej typowym przypadkiem jest to, że ServiceId i ClusterId pozostaje stały dla okresu istnienia aplikacji i strategii wdrażania stopniowego jest używana. Jest to typowe dla systemów hostowanych na platformie Kubernetes i w usłudze Service Fabric.

Punkty końcowe

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

Silos Orleans ma dwa typowe typy konfiguracji punktu końcowego:

  • Punkty końcowe silosu do silosu używane do komunikacji między silosami w tym samym klastrze
  • Punkty końcowe typu klient-silos (lub brama) używane do komunikacji między klientami i silosami w tym samym klastrze

W przykładzie używamy metody .ConfigureEndpoints(siloPort: 11111, gatewayPort: 30000) pomocniczej, która ustawia port używany do komunikacji 11111 silosu z i port bramy na 30000wartość . Ta metoda wykryje interfejs do nasłuchiwania.

Ta metoda powinna być wystarczająca w większości przypadków, ale w razie potrzeby można ją jeszcze bardziej dostosować. Oto przykład użycia zewnętrznego adresu IP z pewnym przekazywaniem portów:

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);
})

Wewnętrznie silos będzie nasłuchiwać 0.0.0.0:40000 i 0.0.0.0:50000, ale wartość opublikowana w dostawcy członkostwa będzie i 172.16.0.42:11111 172.16.0.42:30000.

Części aplikacji

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

Mimo że ten krok nie jest technicznie wymagany (jeśli nie jest skonfigurowany, Orleans przeskanuje wszystkie zestawy w bieżącym folderze), deweloperzy są zachęcani do skonfigurowania tego. Ten krok pomoże Orleans załadować zestawy i typy użytkowników. Te zestawy są określane jako części aplikacji. Wszystkie ziarna, interfejsy ziarna i serializatory są odnajdywane przy użyciu części aplikacji.

Składniki aplikacji są konfigurowane przy użyciu metody IApplicationPartManager, do której można uzyskać dostęp przy użyciu ConfigureApplicationParts metody rozszerzenia w systemach IClientBuilder i ISiloHostBuilder. Metoda ConfigureApplicationParts akceptuje delegata , Action<IApplicationPartManager>.

Następujące metody rozszerzenia dotyczące IApplicationPartManager obsługi typowych zastosowań:

Zestawy dodane przez powyższe metody można uzupełnić przy użyciu następujących metod rozszerzenia w ich typie zwrotnym: IApplicationPartManagerWithAssemblies

  • ApplicationPartManagerExtensions.WithReferences dodaje wszystkie przywoływanych zestawów z dodanych części. Natychmiast ładuje wszelkie przechodnio przywołyzowane zestawy. Błędy ładowania zestawu są ignorowane.
  • ApplicationPartManagerCodeGenExtensions.WithCodeGeneration Generuje kod pomocy technicznej dla dodanych części i dodaje go do menedżera części. Należy pamiętać, że wymaga Microsoft.Orleans.OrleansCodeGenerator to zainstalowania pakietu i jest często określane jako generowanie kodu środowiska uruchomieniowego.

Odnajdywanie typów wymaga, aby podane części aplikacji zawierały określone atrybuty. Dodanie pakietu generowania kodu w czasie kompilacji (Microsoft.Orleans.CodeGenerator.MSBuild lub Microsoft.Orleans.OrleansCodeGenerator.Build) do każdego projektu zawierającego ziarna, interfejsy ziarna lub serializatory jest zalecanym podejściem do zapewnienia, że te atrybuty są obecne. Generowanie kodu w czasie kompilacji obsługuje tylko język C#. W przypadku języków F#, Visual Basic i innych języków platformy .NET kod można wygenerować w czasie konfiguracji za pomocą metody opisanej WithCodeGeneration powyżej. Więcej informacji na temat generowania kodu można znaleźć w odpowiedniej sekcji.