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 StatefulService
a -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 azServiceContext
objektum, amely információkat tartalmaz a futó szolgáltatásról.string endpointName
: Ez az ServiceManifest.xml konfigurációjánakEndpoint
neve. Elsősorban itt különbözik a két kommunikációs figyelő. HTTP.sys konfigurációtEndpoint
igényel, míg a Kestrel nem.Func<string, AspNetCoreCommunicationListener, IWebHost> build
: Ez egy implementálandó lambda, amelyben létrehoz és visszaad egyIWebHost
. Lehetővé teszi, hogy a szokásos módon konfiguráljaIWebHost
az ASP.NET Core alkalmazásokat. A lambda a használt Service Fabric-integrációs lehetőségektől és azEndpoint
Ö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:
- Az A szolgáltatás HTTP-n keresztül figyeli a 10.0.0.1:300000-et.
- Az ügyfél feloldja az A szolgáltatást, és lekéri a 10.0.0.1:30000 címet.
- Az A szolgáltatás másik csomópontra kerül.
- A B szolgáltatás a 10.0.0.1-en van elhelyezve, és véletlenül ugyanazt a 30000-es portot használja.
- Az ügyfél megpróbál csatlakozni az A szolgáltatáshoz a 10.0.0.1:300000 gyorsítótárazott címmel.
- 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 HttpSysCommunicationListener
a ( ) implementációját ICommunicationListener
. HttpSysCommunicationListener
lehető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 KestrelCommunicationListener
a implementációját ICommunicationListener
. KestrelCommunicationListener
lehető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 KestrelCommunicationListener
HttpSysCommunicationListener
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
Visszajelzés
https://aka.ms/ContentUserFeedback.
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ:Visszajelzés küldése és megtekintése a következőhöz: