ASP.NET Core az Azure Service Fabric Reliable Servicesben

ASP.NET Core egy nyílt forráskódú és platformfüggetlen keretrendszer. Ez a keretrendszer felhőalapú, internetkapcsolattal rendelkező alkalmazások, például webalkalmazások, IoT-alkalmazások és mobil háttéralkalmazások létrehozásához készült.

Ez a cikk részletes útmutató ASP.NET Core szolgáltatások Service Fabric Reliable Servicesben való üzemeltetéséhez a Microsoft.ServiceFabric.AspNetCore. nuGet-csomagok készletével.

A Service Fabricben ASP.NET Core és a fejlesztési környezet beállításával kapcsolatos útmutatásért lásd: Oktatóanyag: Alkalmazás létrehozása és üzembe helyezése ASP.NET Core Webes API előtér-szolgáltatással és állapotalapú háttérszolgáltatással.

A cikk további részében feltételezzük, hogy már ismeri a ASP.NET Core. Ha nem, olvassa el a ASP.NET Core alapjait.

ASP.NET Core Service Fabric-környezetben

A ASP.NET Core és a Service Fabric-alkalmazások egyaránt futtathatók .NET Core-on vagy teljes .NET-keretrendszer. A ASP.NET Core kétféleképpen használható a Service Fabricben:

• Vendégként futtatható. Ez a módszer elsősorban meglévő ASP.NET Core-alkalmazások futtatására használható a Service Fabricben kódmódosítások nélkül.
• Futtassa a parancsot egy megbízható szolgáltatásban. Ez lehetővé teszi a Service Fabric-futtatókörnyezettel való jobb integrációt, és lehetővé teszi az állapotalapú ASP.NET Core szolgáltatásokat.

A cikk további része azt ismerteti, hogyan használható ASP.NET Core egy megbízható szolgáltatáson belül a Service Fabric SDK-val szállítandó ASP.NET Core integrációs összetevőkön keresztül.

Service Fabric szolgáltatás üzemeltetése

A Service Fabricben a szolgáltatás egy vagy több példánya és/vagy replikája egy szolgáltatásgazdafolyamatban fut: egy végrehajtható fájl, amely futtatja a szolgáltatáskódot. Ön, mint szolgáltatásszerző, a szolgáltatásgazdafolyamat tulajdonosa, és a Service Fabric aktiválja és figyeli az Ön számára.

A hagyományos ASP.NET (MVC 5-ig) szorosan kapcsolódik az IIS-hez System.Web.dll keresztül. ASP.NET Core elkülöníti a webkiszolgálót és a webalkalmazást. Ez az elkülönítés lehetővé teszi, hogy a webalkalmazások hordozhatók legyenek a különböző webkiszolgálók között. Emellett lehetővé teszi a webkiszolgálók önálló üzemeltetését is. Ez azt jelenti, hogy a webkiszolgálót a saját folyamatában indíthatja el, nem pedig egy dedikált webkiszolgáló-szoftver, például az IIS tulajdonában lévő folyamattal szemben.

A Service Fabric-szolgáltatás és a ASP.NET kombinálásához vendég végrehajthatóként vagy megbízható szolgáltatásként el kell tudnia indítani ASP.NET a szolgáltatásgazdafolyamaton belül. ASP.NET Core önkiszolgáló üzemeltetés lehetővé teszi ezt.

A ASP.NET Core megbízható szolgáltatásban való üzemeltetése

A saját üzemeltetésű ASP.NET Core alkalmazások általában létrehoznak egy WebHostot az alkalmazás belépési pontjában, például a static void Main() metódusban.Program.cs Ebben az esetben a WebHost életciklusa a folyamat életciklusához van kötve.

Az alkalmazás belépési pontja azonban nem a megfelelő hely a WebHost megbízható szolgáltatásban való létrehozásához. Ennek az az oka, hogy az alkalmazás belépési pontjával csak a Service Fabric-futtatókörnyezetben regisztrálhat egy szolgáltatástípust, hogy ilyen típusú példányokat hozzon létre. A WebHostot egy megbízható szolgáltatásban kell létrehozni. A szolgáltatásgazdafolyamaton belül a szolgáltatáspéldányok és/vagy replikák több életcikluson is átmehetnek.

A Reliable Service-példányokat a vagy StatefulServicea -ből StatelessService származtatott szolgáltatásosztály képviseli. A szolgáltatás kommunikációs vermét a szolgáltatásosztály implementációja ICommunicationListener tartalmazza. A Microsoft.ServiceFabric.AspNetCore.* NuGet-csomagok a ASP.NET Core WebHost implementációit ICommunicationListener tartalmazzák a Kestrel vagy HTTP.sys megbízható szolgáltatásban.

ASP.NET Core ICommunicationListeners

A ICommunicationListener NuGet-csomagokban a Kestrel és a Microsoft.ServiceFabric.AspNetCore.* HTTP.sys implementációi hasonló használati mintákkal rendelkeznek. Az egyes webkiszolgálókon azonban némileg eltérő műveleteket hajtanak végre.

Mindkét kommunikációs figyelő olyan konstruktort biztosít, amely a következő argumentumokat veszi fel:

• ServiceContext serviceContext: Ez az az ServiceContext objektum, amely információkat tartalmaz a futó szolgáltatásról.
• string endpointName: Ez az ServiceManifest.xml konfigurációjának Endpoint neve. Elsősorban itt különbözik a két kommunikációs figyelő. HTTP.sys konfigurációt Endpointigényel, míg a Kestrel nem.
• Func<string, AspNetCoreCommunicationListener, IWebHost> build: Ez egy implementálandó lambda, amelyben létrehoz és visszaad egy IWebHost. Lehetővé teszi, hogy a szokásos módon konfigurálja IWebHost az ASP.NET Core alkalmazásokat. A lambda a használt Service Fabric-integrációs lehetőségektől és az Endpoint Ön által megadott konfigurációtól függően létrehoz egy ÖN számára létrehozott URL-címet. Ezután módosíthatja vagy használhatja ezt az URL-címet a webkiszolgáló elindításához.

Service Fabric-integrációs köztes szoftver

A Microsoft.ServiceFabric.AspNetCore NuGet-csomag tartalmazza a UseServiceFabricIntegration Service Fabric-kompatibilis köztes szoftvereket hozzáadó bővítménymetódust IWebHostBuilder . Ez a köztes szoftver konfigurálja a Kestrelt vagy a HTTP.sys ICommunicationListener , hogy regisztráljon egy egyedi szolgáltatás URL-címét a Service Fabric elnevezési szolgáltatásban. Ezután ellenőrzi az ügyfélkéréseket, hogy az ügyfelek a megfelelő szolgáltatáshoz csatlakozzanak.

Ez a lépés azért szükséges, hogy az ügyfelek ne csatlakozzanak tévesen a rossz szolgáltatáshoz. Ennek az az oka, hogy egy megosztott gazdagép-környezetben, például a Service Fabricben több webalkalmazás is futtatható ugyanazon a fizikai vagy virtuális gépen, de nem használ egyedi gazdagépneveket. Ezt a forgatókönyvet részletesebben a következő szakaszban ismertetjük.

Hibás identitás esete

A szolgáltatásreplikák protokolltól függetlenül egyedi IP:portkombinációt figyelnek. Miután egy szolgáltatásreplika megkezdte az IP:portvégpont figyelését, a szolgáltatás ezt a végpontcímet jelenti a Service Fabric elnevezési szolgáltatásnak. Ott az ügyfelek vagy más szolgáltatások felfedezhetik. Ha a szolgáltatások dinamikusan hozzárendelt alkalmazásportokat használnak, előfordulhat, hogy egy szolgáltatásreplika véletlenül ugyanazt az IP:portvégpontot használja egy másik szolgáltatáshoz, amely korábban ugyanazon a fizikai vagy virtuális gépen volt. Ez azt okozhatja, hogy az ügyfél tévesen nem a megfelelő szolgáltatáshoz csatlakozik. Ez a forgatókönyv akkor fordulhat elő, ha a következő események sorozata következik be:

1. Az A szolgáltatás HTTP-n keresztül figyeli a 10.0.0.1:300000-et.
2. Az ügyfél feloldja az A szolgáltatást, és lekéri a 10.0.0.1:30000 címet.
3. Az A szolgáltatás másik csomópontra kerül.
4. A B szolgáltatás a 10.0.0.1-en van elhelyezve, és véletlenül ugyanazt a 30000-es portot használja.
5. Az ügyfél megpróbál csatlakozni az A szolgáltatáshoz a 10.0.0.1:300000 gyorsítótárazott címmel.
6. Az ügyfél sikeresen csatlakozik a B szolgáltatáshoz, nem pedig azt, hogy nem a megfelelő szolgáltatáshoz kapcsolódik.

Ez véletlenszerű időpontokban hibákat okozhat, amelyeket nehéz lehet diagnosztizálni.

Egyedi szolgáltatás URL-címeinek használata

A hibák elkerülése érdekében a szolgáltatások egy egyedi azonosítóval rendelkező végpontot tehetnek közzé az elnevezési szolgáltatásban, majd ellenőrizhetik ezt az egyedi azonosítót az ügyfélkérések során. Ez egy együttműködési művelet a szolgáltatások között egy nem ellenséges bérlői megbízható környezetben. Nem biztosít biztonságos szolgáltatáshitelesítést ellenséges bérlői környezetben.

Megbízható környezetben a metódus által UseServiceFabricIntegration hozzáadott köztes szoftver automatikusan hozzáfűz egy egyedi azonosítót az elnevezési szolgáltatáshoz feladott címhez. Minden egyes kérelem esetében ellenőrzi ezt az azonosítót. Ha az azonosító nem egyezik, a köztes szoftver azonnal egy HTTP 410 Gone választ ad vissza.

A dinamikusan hozzárendelt portot használó szolgáltatásoknak ezt a köztes szoftvert kell használniuk.

A rögzített egyedi portot használó szolgáltatások nem rendelkeznek ezzel a problémával egy együttműködési környezetben. A rögzített egyedi portokat általában olyan külső szolgáltatásokhoz használják, amelyekhez jól ismert portra van szükség az ügyfélalkalmazások számára a csatlakozáshoz. A legtöbb internetes webalkalmazás például a 80-at vagy a 443-at használja a webböngésző-kapcsolatokhoz. Ebben az esetben az egyedi azonosítót nem szabad engedélyezni.

Az alábbi ábrán a kérelem folyamata látható, amelyen engedélyezve van a köztes szoftver:

A Kestrel és HTTP.sys ICommunicationListener implementációk is pontosan ugyanúgy használják ezt a mechanizmust. Bár HTTP.sys az alapul szolgáló HTTP.sys portmegosztási funkcióval belsőleg megkülönböztetheti az egyedi URL-útvonalakon alapuló kéréseket, ezt a funkciót nem használja a HTTP.sys ICommunicationListener implementáció. Ennek az az oka, hogy HTTP 503- és HTTP 404-hibaállapot-kódokat eredményez a korábban ismertetett forgatókönyvben. Ez megnehezíti az ügyfelek számára a hiba szándékának meghatározását, mivel a HTTP 503 és a HTTP 404 gyakran más hibák jelzésére szolgálnak.

Így a Kestrel és a HTTP.sys ICommunicationListener implementációk is szabványosítják a bővítménymetódus UseServiceFabricIntegration által biztosított köztes szoftvereket. Ezért az ügyfeleknek csak egy szolgáltatásvégpont újrafeloldási műveletet kell végrehajtaniuk a HTTP 410-válaszokon.

HTTP.sys a Reliable Services szolgáltatásban

A HTTP.sys a Reliable Servicesben a Microsoft.ServiceFabric.AspNetCore.HttpSys NuGet-csomag importálásával használható. Ez a csomag tartalmazza HttpSysCommunicationListenera ( ) implementációját ICommunicationListener. HttpSysCommunicationListenerlehetővé teszi egy ASP.NET Core WebHost létrehozását egy megbízható szolgáltatásban a HTTP.sys webkiszolgálóként való használatával.

HTTP.sys a Windows HTTP Server API-ra épül. Ez az API a HTTP.sys kernelillesztővel dolgozza fel a HTTP-kéréseket, és irányítja őket a webalkalmazásokat futtató folyamatokba. Ez lehetővé teszi, hogy ugyanazon a fizikai vagy virtuális gépen több folyamat is üzemeltetjen webalkalmazásokat ugyanazon a porton, amelyet egy egyedi URL-cím vagy állomásnév nem egyértelmű. Ezek a funkciók hasznosak a Service Fabricben több webhely üzemeltetéséhez ugyanabban a fürtben.

Megjegyzés

HTTP.sys implementáció csak a Windows platformon működik.

Az alábbi ábra bemutatja, hogyan használja HTTP.sys a windowsosHTTP.sys kernelillesztőt a portmegosztáshoz:

HTTP.sys állapot nélküli szolgáltatásban

Állapot nélküli szolgáltatásban való használathoz HttpSys bírálja felül a metódust CreateServiceInstanceListeners , és adjon vissza egy példányt HttpSysCommunicationListener :

protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
    return new ServiceInstanceListener[]
    {
        new ServiceInstanceListener(serviceContext =>
            new HttpSysCommunicationListener(serviceContext, "ServiceEndpoint", (url, listener) =>
                new WebHostBuilder()
                    .UseHttpSys()
                    .ConfigureServices(
                        services => services
                            .AddSingleton<StatelessServiceContext>(serviceContext))
                    .UseContentRoot(Directory.GetCurrentDirectory())
                    .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
                    .UseStartup<Startup>()
                    .UseUrls(url)
                    .Build()))
    };
}

állapotalapú szolgáltatásban HTTP.sys

HttpSysCommunicationListener jelenleg nem állapotalapú szolgáltatásokban való használatra tervezték a mögöttes HTTP.sys portmegosztási funkcióval kapcsolatos bonyodalmak miatt. További információkért lásd a dinamikus portok HTTP.sys való kiosztásáról szóló alábbi szakaszt. Állapotalapú szolgáltatások esetén a Kestrel a javasolt webkiszolgáló.

Végpontkonfiguráció

Konfiguráció Endpoint szükséges a Windows HTTP Server API-t használó webkiszolgálókhoz, beleértve a HTTP.sys. A Windows HTTP Server API-t használó webkiszolgálóknak először az URL-címüket HTTP.sys kell lefoglalniuk (ez általában a netsh eszközzel történik).

Ez a művelet olyan emelt szintű jogosultságokat igényel, amelyekkel a szolgáltatások alapértelmezés szerint nem rendelkeznek. Az ServiceManifest.xml konfigurációjának tulajdonságához Endpoint tartozó "http" vagy "https" beállítások Protocol kifejezetten arra utasítják a Service Fabric-futtatókörnyezetet, hogy regisztráljon egy URL-címet HTTP.sys az Ön nevében. Ezt az erős helyettesítő URL-előtag használatával teszi meg.

Ha például egy szolgáltatásra szeretne lefoglalni http://+:80 egy szolgáltatást, használja a következő konfigurációt a ServiceManifest.xml:

<ServiceManifest ... >
    ...
    <Resources>
        <Endpoints>
            <Endpoint Name="ServiceEndpoint" Protocol="http" Port="80" />
        </Endpoints>
    </Resources>

</ServiceManifest>

A végpont nevét pedig át kell adni a HttpSysCommunicationListener konstruktornak:

 new HttpSysCommunicationListener(serviceContext, "ServiceEndpoint", (url, listener) =>
 {
     return new WebHostBuilder()
         .UseHttpSys()
         .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
         .UseUrls(url)
         .Build();
 })

A HTTP.sys használata statikus porttal

Ha statikus portot szeretne használni HTTP.sys, adja meg a portszámot a Endpoint konfigurációban:

  <Resources>
    <Endpoints>
      <Endpoint Protocol="http" Name="ServiceEndpoint" Port="80" />
    </Endpoints>
  </Resources>

A HTTP.sys használata dinamikus porttal

Ha dinamikusan hozzárendelt portot szeretne használni HTTP.sys, hagyja ki a Port tulajdonságot a Endpoint konfigurációból:

  <Resources>
    <Endpoints>
      <Endpoint Protocol="http" Name="ServiceEndpoint" />
    </Endpoints>
  </Resources>

A konfiguráció által Endpoint lefoglalt dinamikus port gazdagépenként csak egy portot biztosít. Az aktuális Service Fabric-üzemeltetési modell lehetővé teszi több szolgáltatáspéldány és/vagy replika üzemeltetését ugyanabban a folyamatban. Ez azt jelenti, hogy mindegyik ugyanazt a portot fogja megosztani, amikor a Endpoint konfiguráción keresztül van lefoglalva. A mögöttes HTTP.sys portmegosztási funkcióval több HTTP.sys példány is megoszthat portokat. Ezt azonban nem támogatja HttpSysCommunicationListener az ügyfélkérésekhez bevezetett bonyodalmak miatt. Dinamikus porthasználat esetén a Kestrel a javasolt webkiszolgáló.

Kestrel a Reliable Servicesben

A Kestrelt a Reliable Servicesben a Microsoft.ServiceFabric.AspNetCore.Kestrel NuGet-csomag importálásával használhatja. Ez a csomag tartalmazza KestrelCommunicationListenera implementációját ICommunicationListener. KestrelCommunicationListenerlehetővé teszi egy ASP.NET Core WebHost létrehozását egy megbízható szolgáltatásban a Kestrel webkiszolgálóként való használatával.

A Kestrel egy platformfüggetlen webkiszolgáló ASP.NET Core. A HTTP.sys ellentétben a Kestrel nem használ központosított végpontkezelőt. A HTTP.sys ellentétben a Kestrel nem támogatja a több folyamat közötti portmegosztást. A Kestrel minden példányának egyedi portot kell használnia. A Kestrelről további információt az Implementáció részletei című témakörben talál.

Kestrel állapot nélküli szolgáltatásban

Állapot nélküli szolgáltatásban való használathoz Kestrel bírálja felül a metódust CreateServiceInstanceListeners , és adjon vissza egy példányt KestrelCommunicationListener :

protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
    return new ServiceInstanceListener[]
    {
        new ServiceInstanceListener(serviceContext =>
            new KestrelCommunicationListener(serviceContext, "ServiceEndpoint", (url, listener) =>
                new WebHostBuilder()
                    .UseKestrel()
                    .ConfigureServices(
                        services => services
                            .AddSingleton<StatelessServiceContext>(serviceContext))
                    .UseContentRoot(Directory.GetCurrentDirectory())
                    .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.UseUniqueServiceUrl)
                    .UseStartup<Startup>()
                    .UseUrls(url)
                    .Build();
            ))
    };
}

Kestrel állapotalapú szolgáltatásban

Állapotalapú szolgáltatásban való használathoz Kestrel felülbírálja a metódust CreateServiceReplicaListeners , és adjon vissza egy példányt KestrelCommunicationListener :

protected override IEnumerable<ServiceReplicaListener> CreateServiceReplicaListeners()
{
    return new ServiceReplicaListener[]
    {
        new ServiceReplicaListener(serviceContext =>
            new KestrelCommunicationListener(serviceContext, (url, listener) =>
                new WebHostBuilder()
                    .UseKestrel()
                    .ConfigureServices(
                         services => services
                             .AddSingleton<StatefulServiceContext>(serviceContext)
                             .AddSingleton<IReliableStateManager>(this.StateManager))
                    .UseContentRoot(Directory.GetCurrentDirectory())
                    .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.UseUniqueServiceUrl)
                    .UseStartup<Startup>()
                    .UseUrls(url)
                    .Build();
            ))
    };
}

Ebben a példában a webhost függőséginjektálási tárolóhoz egyetlen példány IReliableStateManager tartozik. Ez nem feltétlenül szükséges, de lehetővé teszi a és a Reliable Collections használatát IReliableStateManager az MVC vezérlő műveleti módszereiben.

Állapotalapú Endpoint szolgáltatásban nincs megadva KestrelCommunicationListener konfigurációnév. Ezt részletesebben a következő szakaszban ismertetjuk.

A Kestrel konfigurálása HTTPS használatára

Amikor engedélyezi a HTTPS-t a Kestrel használatával a szolgáltatásban, több figyelési beállítást is be kell állítania. Frissítse a-t ServiceInstanceListener egy EndpointHttps-végpont használatára, és figyelje meg egy adott portot (például a 443-as portot). Amikor a webszolgáltatót a Kestrel-webkiszolgáló használatára konfigurálja, a Kestrelt úgy kell konfigurálnia, hogy minden hálózati adapteren figyelje az IPv6-címeket:

new ServiceInstanceListener(
serviceContext =>
    new KestrelCommunicationListener(
        serviceContext,
        "EndpointHttps",
        (url, listener) =>
        {
            ServiceEventSource.Current.ServiceMessage(serviceContext, $"Starting Kestrel on {url}");

            return new WebHostBuilder()
                .UseKestrel(opt =>
                {
                    int port = serviceContext.CodePackageActivationContext.GetEndpoint("EndpointHttps").Port;
                    opt.Listen(IPAddress.IPv6Any, port, listenOptions =>
                    {
                        listenOptions.UseHttps(GetCertificateFromStore());
                        listenOptions.NoDelay = true;
                    });
                })
                .ConfigureAppConfiguration((builderContext, config) =>
                {
                    config.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true);
                })

                .ConfigureServices(
                    services => services
                        .AddSingleton<HttpClient>(new HttpClient())
                        .AddSingleton<FabricClient>(new FabricClient())
                        .AddSingleton<StatelessServiceContext>(serviceContext))
                .UseContentRoot(Directory.GetCurrentDirectory())
                .UseStartup<Startup>()
                .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
                .UseUrls(url)
                .Build();
        }))

Az oktatóanyag teljes példájáért lásd: A Kestrel konfigurálása HTTPS használatára.

Végpontkonfiguráció

A Endpoint Kestrel használatához nincs szükség konfigurációra.

A Kestrel egy egyszerű önálló webkiszolgáló. A HTTP.sys -tól (vagy HttpListenertől) eltérően nincs szükség konfigurációra Endpoint ServiceManifest.xml, mert nem igényel URL-regisztrációt a kezdés előtt.

A Kestrel használata statikus porttal

Konfigurálhat statikus portot a Endpoint ServiceManifest.xml konfigurálásához a Kestrelrel való használatra. Bár ez nem feltétlenül szükséges, két lehetséges előnnyel jár:

• Ha a port nem esik az alkalmazás porttartományára, a Service Fabric az operációs rendszer tűzfalán keresztül nyitja meg.
• A megadott KestrelCommunicationListener URL-cím ezt a portot fogja használni.

  <Resources>
    <Endpoints>
      <Endpoint Protocol="http" Name="ServiceEndpoint" Port="80" />
    </Endpoints>
  </Resources>

Ha egy Endpoint konfigurálva van, a nevét át kell adni a KestrelCommunicationListener konstruktornak:

new KestrelCommunicationListener(serviceContext, "ServiceEndpoint", (url, listener) => ...

Ha ServiceManifest.xml nem használ konfigurációt Endpoint , hagyja ki a nevet a KestrelCommunicationListener konstruktorból. Ebben az esetben dinamikus portot fog használni. Erről további információt a következő szakaszban talál.

A Kestrel használata dinamikus porttal

A Kestrel nem tudja használni az automatikus porthozzárendelést a konfigurációból a Endpoint ServiceManifest.xml. Ennek az az oka, hogy egy Endpoint konfiguráció automatikus port-hozzárendelése gazdagépenként egyedi portot rendel hozzá, és egyetlen gazdafolyamat több Kestrel-példányt is tartalmazhat. Ez nem működik a Kestrelrel, mert nem támogatja a portmegosztást. Ezért minden Kestrel-példányt egy egyedi porton kell megnyitni.

Ha dinamikus port-hozzárendelést szeretne használni a Kestrelrelhez, hagyja ki a konfigurációt teljes egészében ServiceManifest.xml Endpoint , és ne adjon meg végpontnevet a konstruktornak az KestrelCommunicationListener alábbiak szerint:

new KestrelCommunicationListener(serviceContext, (url, listener) => ...

Ebben a konfigurációban KestrelCommunicationListener automatikusan kiválaszt egy nem használt portot az alkalmazásport tartományából.

HTTPS esetén a végpontnak HTTPS protokollal kell konfigurálva lennie a ServiceManifest.xml megadott port nélkül, és át kell adnia a végpont nevét a KestrelCommunicationListener konstruktornak.

IHost és minimális üzemeltetési integráció

Az IWebHost/IWebHostBuilder KestrelCommunicationListenerHttpSysCommunicationListener mellett ASP.NET Core szolgáltatásokat is támogat az IHost/IHostBuilder használatával. Ez a és Microsoft.ServiceFabric.AspNetCore.HttpSys csomagok 5.2.1363-tól Microsoft.ServiceFabric.AspNetCore.Kestrel érhető el.

// Stateless Service
protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
    return new ServiceInstanceListener[]
    {
        new ServiceInstanceListener(serviceContext =>
            new KestrelCommunicationListener(serviceContext, "ServiceEndpoint", (url, listener) =>
            {
                return Host.CreateDefaultBuilder()
                        .ConfigureWebHostDefaults(webBuilder =>
                        {
                            webBuilder.UseKestrel()
                                .UseStartup<Startup>()
                                .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
                                .UseContentRoot(Directory.GetCurrentDirectory())
                                .UseUrls(url);
                        })
                        .ConfigureServices(services => services.AddSingleton<StatelessServiceContext>(serviceContext))
                        .Build();
            }))
    };
}

// Stateful Service
protected override IEnumerable<ServiceReplicaListener> CreateServiceReplicaListeners()
{
    return new ServiceReplicaListener[]
    {
        new ServiceReplicaListener(serviceContext =>
            new KestrelCommunicationListener(serviceContext, "ServiceEndpoint", (url, listener) =>
            {
                return Host.CreateDefaultBuilder()
                        .ConfigureWebHostDefaults(webBuilder =>
                        {
                            webBuilder.UseKestrel()
                                .UseStartup<Startup>()
                                .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.UseUniqueServiceUrl)
                                .UseContentRoot(Directory.GetCurrentDirectory())
                                .UseUrls(url);
                        })
                        .ConfigureServices(services =>
                        {
                            services.AddSingleton<StatefulServiceContext>(serviceContext);
                            services.AddSingleton<IReliableStateManager>(this.StateManager);
                        })
                        .Build();
            }))
    };
}

Megjegyzés

Mivel a KestrelCommunicationListener és a HttpSysCommunicationListener webszolgáltatásokhoz készült, webkiszolgálót kell regisztrálni/konfigurálni ( a ConfigureWebHostDefaults vagy a ConfigureWebHost metódus használatával) az IHoston keresztül

ASP.NET 6 bevezette a minimális üzemeltetési modellt, amely egyszerűbb és egyszerűbb módja a webalkalmazások létrehozásának. A minimális üzemeltetési modell a KestrelCommunicationListener és a HttpSysCommunicationListener használatával is használható.

// Stateless Service
protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
    return new ServiceInstanceListener[]
    {
        new ServiceInstanceListener(serviceContext =>
            new KestrelCommunicationListener(serviceContext, "ServiceEndpoint", (url, listener) =>
            {
                var builder = WebApplication.CreateBuilder();

                builder.Services.AddSingleton<StatelessServiceContext>(serviceContext);
                builder.WebHost
                            .UseKestrel()
                            .UseContentRoot(Directory.GetCurrentDirectory())
                            .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
                            .UseUrls(url);

                builder.Services.AddControllersWithViews();

                var app = builder.Build();

                if (!app.Environment.IsDevelopment())
                {
                    app.UseExceptionHandler("/Home/Error");
                }

                app.UseHttpsRedirection();
                app.UseStaticFiles();
                app.UseRouting();
                app.UseAuthorization();
                app.MapControllerRoute(
                    name: "default",
                    pattern: "{controller=Home}/{action=Index}/{id?}");

                return app;
            }))
    };
}

// Stateful Service
protected override IEnumerable<ServiceReplicaListener> CreateServiceReplicaListeners()
{
    return new ServiceReplicaListener[]
    {
        new ServiceReplicaListener(serviceContext =>
            new KestrelCommunicationListener(serviceContext, "ServiceEndpoint", (url, listener) =>
            {
                var builder = WebApplication.CreateBuilder();

                builder.Services
                            .AddSingleton<StatefulServiceContext>(serviceContext)
                            .AddSingleton<IReliableStateManager>(this.StateManager);
                builder.WebHost
                            .UseKestrel()
                            .UseContentRoot(Directory.GetCurrentDirectory())
                            .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.UseUniqueServiceUrl)
                            .UseUrls(url);

                builder.Services.AddControllersWithViews();

                var app = builder.Build();

                if (!app.Environment.IsDevelopment())
                {
                    app.UseExceptionHandler("/Home/Error");
                }
                app.UseStaticFiles();
                app.UseRouting();
                app.UseAuthorization();
                app.MapControllerRoute(
                    name: "default",
                    pattern: "{controller=Home}/{action=Index}/{id?}");

                return app;
            }))
    };
}

Service Fabric-konfigurációszolgáltató

Az alkalmazáskonfiguráció ASP.NET Core a konfigurációszolgáltató által létrehozott kulcs-érték párokon alapul. Az általános ASP.NET Core konfigurációs támogatással kapcsolatos további információkért olvassa el a konfigurációs ASP.NET Core című cikket.

Ez a szakasz azt ismerteti, hogy a Service Fabric konfigurációszolgáltató hogyan integrálható ASP.NET Core konfigurációval a Microsoft.ServiceFabric.AspNetCore.Configuration NuGet-csomag importálásával.

AddServiceFabricConfiguration indítási bővítmények

A NuGet-csomag importálása Microsoft.ServiceFabric.AspNetCore.Configuration után regisztrálnia kell a Service Fabric konfigurációs forrását ASP.NET Core configuration API-val. Ehhez ellenőrizze az AddServiceFabricConfiguration bővítményeket a névtérben a Microsoft.ServiceFabric.AspNetCore.Configuration értéken IConfigurationBuilder.

using Microsoft.ServiceFabric.AspNetCore.Configuration;

public Startup(IHostingEnvironment env)
{
    var builder = new ConfigurationBuilder()
        .SetBasePath(env.ContentRootPath)
        .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
        .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
        .AddServiceFabricConfiguration() // Add Service Fabric configuration settings.
        .AddEnvironmentVariables();
    Configuration = builder.Build();
}

public IConfigurationRoot Configuration { get; }

Most a ASP.NET Core szolgáltatás ugyanúgy hozzáférhet a Service Fabric konfigurációs beállításaihoz, mint bármely más alkalmazásbeállításhoz. A beállítási mintával például betöltheti a beállításokat erősen beírt objektumokba.

public void ConfigureServices(IServiceCollection services)
{
    services.Configure<MyOptions>(Configuration);  // Strongly typed configuration object.
    services.AddMvc();
}

Alapértelmezett kulcsleképezés

Alapértelmezés szerint a Service Fabric konfigurációszolgáltatója tartalmazza a csomag nevét, a szakasz nevét és a tulajdonság nevét. Ezek együttesen alkotják a ASP.NET Core konfigurációs kulcsot az alábbiak szerint:

$"{this.PackageName}{ConfigurationPath.KeyDelimiter}{section.Name}{ConfigurationPath.KeyDelimiter}{property.Name}"

Ha például rendelkezik egy nevű MyConfigPackage konfigurációs csomaggal, amely a következő tartalommal rendelkezik, akkor a konfigurációs érték a MyConfigPackage:MyConfigSection:MyParameter fájlon keresztül lesz elérhető ASP.NET CoreIConfiguration.

<?xml version="1.0" encoding="utf-8" ?>
<Settings xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2011/01/fabric">  
  <Section Name="MyConfigSection">
    <Parameter Name="MyParameter" Value="Value1" />
  </Section>  
</Settings>

A Service Fabric konfigurációs beállításai

A Service Fabric konfigurációszolgáltatója támogatja ServiceFabricConfigurationOptions a kulcsleképezés alapértelmezett viselkedésének módosítását is.

Titkosított beállítások

A Service Fabric támogatja a titkosított beállításokat, ahogyan a Service Fabric konfigurációszolgáltatója is. A titkosított beállításokat a rendszer alapértelmezés szerint nem fejti vissza ASP.NET CoreIConfiguration. A titkosított értékeket ehelyett ott tárolja a rendszer. Ha azonban vissza szeretné fejteni az IConfiguration ASP.NET Core tárolni kívánt értéket, állítsa a DecryptValue jelzőt false (hamis) értékre a bővítményben az AddServiceFabricConfiguration alábbiak szerint:

public Startup()
{
    ICodePackageActivationContext activationContext = FabricRuntime.GetActivationContext();
    var builder = new ConfigurationBuilder()        
        .AddServiceFabricConfiguration(activationContext, (options) => options.DecryptValue = false); // set flag to decrypt the value
    Configuration = builder.Build();
}

Több konfigurációs csomag

A Service Fabric több konfigurációs csomagot is támogat. Alapértelmezés szerint a csomag neve szerepel a konfigurációs kulcsban. A jelölőt IncludePackageName azonban a következőképpen állíthatja be hamis értékre:

public Startup()
{
    ICodePackageActivationContext activationContext = FabricRuntime.GetActivationContext();
    var builder = new ConfigurationBuilder()        
        // exclude package name from key.
        .AddServiceFabricConfiguration(activationContext, (options) => options.IncludePackageName = false); 
    Configuration = builder.Build();
}

Egyéni kulcsleképezés, értékkinyerés és adatpopuláció

A Service Fabric konfigurációszolgáltatója speciálisabb forgatókönyveket is támogat a kulcsleképezés ExtractKeyFunc testreszabásához és az értékek egyéni kinyeréséhez a használatával ExtractValueFunc. Az adatok Service Fabric-konfigurációról ASP.NET Core konfigurációra való feltöltésének teljes folyamatát is módosíthatja a használatávalConfigAction.

Az alábbi példák bemutatják, hogyan szabhatók ConfigAction testre az adatpopulációk:

public Startup()
{
    ICodePackageActivationContext activationContext = FabricRuntime.GetActivationContext();
    
    this.valueCount = 0;
    this.sectionCount = 0;
    var builder = new ConfigurationBuilder();
    builder.AddServiceFabricConfiguration(activationContext, (options) =>
        {
            options.ConfigAction = (package, configData) =>
            {
                ILogger logger = new ConsoleLogger("Test", null, false);
                logger.LogInformation($"Config Update for package {package.Path} started");

                foreach (var section in package.Settings.Sections)
                {
                    this.sectionCount++;

                    foreach (var param in section.Parameters)
                    {
                        configData[options.ExtractKeyFunc(section, param)] = options.ExtractValueFunc(section, param);
                        this.valueCount++;
                    }
                }

                logger.LogInformation($"Config Update for package {package.Path} finished");
            };
        });
  Configuration = builder.Build();
}

Konfigurációfrissítések

A Service Fabric konfigurációszolgáltatója a konfigurációfrissítéseket is támogatja. A ASP.NET Core IOptionsMonitor használatával változásértesítéseket kaphat, majd IOptionsSnapshot újra betöltheti a konfigurációs adatokat. További információ: ASP.NET Core beállítások.

Ezek a beállítások alapértelmezés szerint támogatottak. A konfigurációs frissítések engedélyezéséhez nincs szükség további kódolásra.

Forgatókönyvek és konfigurációk

Ez a szakasz a webkiszolgáló, a portkonfiguráció, a Service Fabric-integrációs beállítások és a különféle beállítások kombinációját ismerteti, a következő forgatókönyvek hibaelhárításához javasoljuk:

• Külsőleg közzétett ASP.NET Core állapot nélküli szolgáltatások
• Csak belső ASP.NET Core állapot nélküli szolgáltatások
• Csak belső ASP.NET Core állapotalapú szolgáltatások

A külsőleg közzétett szolgáltatás egy olyan szolgáltatás, amely a fürtön kívülről, általában terheléselosztón keresztül elérhetővé tesz egy végpontot.

A csak belső szolgáltatás az, amelynek végpontja csak a fürtből van meghívva.

Megjegyzés

Az állapotalapú szolgáltatásvégpontokat általában nem szabad az internetre kitenni. Azok a terheléselosztók mögötti fürtök, amelyek nem ismerik a Service Fabric szolgáltatásfeloldását, például Azure Load Balancer, nem fogják tudni elérhetővé tenni az állapotalapú szolgáltatásokat. Ennek az az oka, hogy a terheléselosztó nem fogja tudni megkeresni és átirányítani a forgalmat a megfelelő állapotalapú szolgáltatásreplikára.

Külsőleg közzétett ASP.NET Core állapot nélküli szolgáltatások

A Kestrel a külső, internetre néző HTTP-végpontokat elérhetővé tevő előtér-szolgáltatások javasolt webkiszolgálója. Windows rendszeren a HTTP.sys portmegosztási képességet biztosíthat, amely lehetővé teszi több webszolgáltatás üzemeltetését ugyanazon a csomópontkészleten ugyanazon a porton. Ebben a forgatókönyvben a webszolgáltatások gazdagépnév vagy elérési út alapján vannak megkülönböztetve, anélkül, hogy előtér-proxyra vagy átjáróra támaszkodnak a HTTP-útválasztás biztosításához.

Az interneten keresztül elérhető állapot nélküli szolgáltatásnak egy jól ismert és stabil végpontot kell használnia, amely egy terheléselosztón keresztül érhető el. Ezt az URL-címet meg kell adnia az alkalmazás felhasználóinak. A következő konfigurációt javasoljuk:

Típus	Ajánlás	Jegyzetek
Webkiszolgáló	Vércse	A Kestrel az előnyben részesített webkiszolgáló, mivel windowsos és Linux rendszeren is támogatott.
Portkonfiguráció	Statikus	Egy jól ismert statikus portot kell konfigurálni a Endpoints ServiceManifest.xml konfigurációjában, például 80 HTTP-hez vagy 443 HTTPS-hez.
ServiceFabricIntegrationOptions	None	Használja ezt a lehetőséget a ServiceFabricIntegrationOptions.None Service Fabric integrációs köztes szoftver konfigurálásakor, hogy a szolgáltatás ne kísérelje meg ellenőrizni az egyedi azonosító bejövő kéréseit. Az alkalmazás külső felhasználói nem ismerik a köztes szoftver által használt egyedi azonosító adatokat.
Példányszám	-1	Tipikus használati esetekben a példányszám beállítást -1 értékre kell állítani. Ez úgy történik, hogy a példány minden olyan csomóponton elérhető legyen, amely egy terheléselosztótól fogad forgalmat.

Ha több külsőleg közzétett szolgáltatás osztozik ugyanazon csomópontkészleten, használhatja HTTP.sys egyedi, de stabil URL-elérési úttal. Ezt az IWebHost konfigurálásakor megadott URL-cím módosításával teheti meg. Vegye figyelembe, hogy ez csak HTTP.sys vonatkozik.

new HttpSysCommunicationListener(serviceContext, "ServiceEndpoint", (url, listener) =>
{
    url += "/MyUniqueServicePath";

    return new WebHostBuilder()
        .UseHttpSys()
        ...
        .UseUrls(url)
        .Build();
})

Csak belső állapot nélküli ASP.NET Core szolgáltatás

Az állapot nélküli szolgáltatásoknak, amelyek csak a fürtből vannak meghívva, egyedi URL-címeket és dinamikusan hozzárendelt portokat kell használniuk a több szolgáltatás közötti együttműködés biztosításához. A következő konfigurációt javasoljuk:

Típus	Ajánlás	Jegyzetek
Webkiszolgáló	Vércse	Bár a HTTP.sys belső állapot nélküli szolgáltatásokhoz is használhatja, a Kestrel a legjobb kiszolgáló, amely lehetővé teszi több szolgáltatáspéldány számára a gazdagép megosztását.
Portkonfiguráció	dinamikusan hozzárendelve	Egy állapotalapú szolgáltatás több replikája is megoszthat egy gazdagépfolyamatot vagy gazdagép operációs rendszerét, így egyedi portokra lesz szüksége.
ServiceFabricIntegrationOptions	UseUniqueServiceUrl	Dinamikus port-hozzárendelés esetén ez a beállítás megakadályozza a korábban ismertetett hibás identitáshibát.
InstanceCount	bármelyik	A példányszám beállítás bármilyen értékre beállítható, amely a szolgáltatás működtetéséhez szükséges.

Csak belső állapotalapú ASP.NET Core szolgáltatás

A csak a fürtön belülről meghívott állapotalapú szolgáltatásoknak dinamikusan hozzárendelt portokat kell használniuk a több szolgáltatás közötti együttműködés biztosításához. A következő konfigurációt javasoljuk:

Típus	Ajánlás	Jegyzetek
Webkiszolgáló	Vércse	A HttpSysCommunicationListener nem olyan állapotalapú szolgáltatásokhoz készült, amelyekben a replikák megosztanak egy gazdagépfolyamatot.
Portkonfiguráció	dinamikusan hozzárendelve	Egy állapotalapú szolgáltatás több replikája is megoszthat egy gazdagépfolyamatot vagy gazdagép operációs rendszerét, így egyedi portokra lesz szüksége.
ServiceFabricIntegrationOptions	UseUniqueServiceUrl	Dinamikus port-hozzárendelés esetén ez a beállítás megakadályozza a korábban ismertetett hibás identitáshibát.

Következő lépések

Service Fabric-alkalmazás hibakeresése a Visual Studióval