Hostování a nasazení Blazor Server

  • Článek
  • 8 min ke čtení

Hodnoty konfigurace hostitele

Blazor Server aplikace mohou přijímat konfigurační hodnoty obecného hostitele.

Nasazení

Použití modelu Blazor Server hostováníse provádí na serveru z Blazor ASP.NET Core aplikace. Aktualizace uživatelského rozhraní, zpracování událostí a volání JavaScriptu se zpracovávají přes SignalR připojení.

Webový server schopný hostovat ASP.NET Core aplikace. Visual Studio zahrnuje Blazor Server šablonu projektu aplikace ( blazorserver šablonu při použití příkazu dotnet new ). Další informace o Blazor šablonách projektů najdete v tématu ASP.NET Core Blazor struktura projektu .

Škálovatelnost

Naplánujte nasazení tak, aby se co nejlépe využije dostupná infrastruktura Blazor Server aplikace. Škálovatelnost aplikací řeší Blazor Server následující zdroje informací:

Server nasazení

Při zvažování škálovatelnosti jednoho serveru (škálování nahoru) je paměť dostupná pro aplikaci pravděpodobně prvním zdrojem, který aplikace s rostoucími požadavky uživatelů vyčerpá. Dostupná paměť na serveru ovlivňuje:

  • Počet aktivních okruhů, které může server podporovat
  • Latence uživatelského rozhraní na klientovi.

Pokyny k vytváření zabezpečených a škálovatelných Blazor serverových aplikací najdete v tématu Pokyny pro zmírnění hrozeb pro ASP.NET Core Blazor Server .

Každý okruh používá přibližně 250 kB paměti pro minimální Hello World ve stylu aplikace. Velikost okruhu závisí na kódu aplikace a požadavcích na údržbu stavu spojených s jednotlivými komponentami. Doporučujeme měřit požadavky na prostředky během vývoje pro vaši aplikaci a infrastrukturu, ale následující směrný plán může být výchozím bodem při plánování cíle nasazení: Pokud očekáváte, že vaše aplikace bude podporovat 5 000 souběžných uživatelů, zvažte pro aplikaci rozpočet alespoň 1,3 GB paměti serveru (nebo 273 kB na uživatele).

SignalR Konfigurace

Blazor Serveraplikace používají ASP.NET Core SignalR ke komunikaci s prohlížečem. SignalR platí pro aplikace podmínky hostování a Blazor Server škálování.

Blazorfunguje nejlépe při použití protokolu WebSocket jako přenosu z důvodu nižší SignalR latence, vyšší spolehlivosti a lepšího zabezpečení. Dlouhé dotazování se používá v případě, že není k dispozici webSocket nebo pokud je aplikace explicitně nakonfigurovaná tak, aby používala SignalR dlouhé cyklické dotazování. Při nasazování Azure App Service nakonfigurujte aplikaci tak, aby v nastavení služby Azure Portal webSockety. Podrobnosti o konfiguraci aplikace pro Azure App Service najdete v SignalR pokynech pro publikování.

Blazor Server vysílá upozornění konzoly, pokud zjistí, že se využívá dlouhé dotazování:

Nepovedlo se připojit přes webSockety s využitím záložního přenosu dlouhého cyklického dotazování. Může to být způsobené tím, že připojení blokuje síť VPN nebo proxy server. Pokud chcete tento problém vyřešit, přejděte na https://aka.ms/blazor-server-using-fallback-long-polling .

Služba SignalR Azure

Doporučujeme používat službu Azure SignalR Service for Blazor Server Apps. Služba funguje ve spojení s centrem aplikace pro škálování aplikace na velký počet Blazor Blazor Server souběžných SignalR připojení. Kromě toho globální dosah služby a vysoce výkonná datová centra výrazně pomáhá snížení SignalR latence kvůli zeměpisné oblasti.

Důležité

Když jsou zakázané websockety, Azure App Service simuluje připojení v reálném čase pomocí dlouhého cyklického dotazování HTTP. Dlouhé dotazování HTTP je znatelně pomalejší než spouštění s povolenými protokoly WebSocket, které k simulaci připojení klient-server nepoužuje cyklické dotazování.

Pro aplikace nasazené do Azure App Service Blazor Server doporučujeme použít webSockety. Služba Azure SignalR ve výchozím nastavení používá protokoly WebSocket. Pokud aplikace službu Azure nepodporuje, podívejte SignalR se na . Publikování ASP.NET Core do SignalR Azure App Service

Další informace naleznete v tématu:

Konfigurace

Pokud chcete nakonfigurovat aplikaci pro službu Azure, musí aplikace podporovat přichycené relace , kde se klienti při prerenderingu SignalR přesměrují zpět na stejný server. Možnost ServerStickyMode nebo hodnota konfigurace je nastavená na Required . Aplikace obvykle vytvoří konfiguraci pomocí jednoho z následujících přístupů:

  • Program.cs:

    builder.Services.AddSignalR().AddAzureSignalR(options =>
{
    options.ServerStickyMode = 
    Microsoft.Azure.SignalR.ServerStickyMode.Required;
});

  • Konfigurace (použijte jeden z následujících přístupů):

    • V appsettings.json:

      "Azure:SignalR:StickyServerMode": "Required"

    • Nastavení konfigurační aplikace služby App Service v > Azure Portal (Název: Azure__SignalR__StickyServerMode , Hodnota: Required ). Tento přístup se pro aplikaci automaticky používá při zřizování služby SignalR Azure.

Zřízení služby SignalR Azure

Zřízení služby Azure SignalR pro aplikaci v Visual Studio:

  1. Vytvořte profil publikování aplikací Azure v Visual Studio pro Blazor Server aplikaci.
  2. Přidejte do SignalR profilu závislost služby Azure Service. Pokud předplatné Azure nemá existující instanci služby Azure, která by se měla přiřadit k aplikaci, vyberte Vytvořit novou instanci služby Azure a zřaďte SignalR novou instanci služby. SignalR
  3. Publikovat aplikaci do Azure

Zřízení služby Azure v Visual Studio automaticky povolí přichycené relace a přidá připojovací řetězec SignalR do konfigurace služby App SignalR Service.

Azure App Service

Tato část se týká pouze aplikací, které službu Azure SignalR nevyu ít.

Pokud se služba Azure nepoužít, App Service konfigurace spřažení směrování žádostí aplikace SignalR (ARR) a protokolu WebSocket. Klienti připojují své protokoly WebSocket přímo k aplikaci, ne ke službě SignalR Azure.

Ke konfiguraci aplikace použijte následující pokyny:

IIS

Pokud používáte službu IIS, povolte:

Kubernetes

Vytvořte definici příchozího přenosu dat s následujícími poznámkami Kubernetes pro relace typu sticky:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: <ingress-name>
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "affinity"
    nginx.ingress.kubernetes.io/session-cookie-expires: "14400"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "14400"

Linux na serveru Nginx

Aby SignalR protokolu WebSocket správně fungovaly, ověřte, že jsou hlavičky proxy serveru a namapované na jednu z Upgrade těchto Connection $connection_upgrade hodnot:

  • Ve výchozím nastavení má záhlaví Upgrade hodnotu .
  • close , pokud hlavička Upgrade chybí nebo je prázdná.
http {
    map $http_upgrade $connection_upgrade {
        default Upgrade;
        ''      close;
    }

    server {
        listen      80;
        server_name example.com *.example.com
        location / {
            proxy_pass         http://localhost:5000;
            proxy_http_version 1.1;
            proxy_set_header   Upgrade $http_upgrade;
            proxy_set_header   Connection $connection_upgrade;
            proxy_set_header   Host $host;
            proxy_cache_bypass $http_upgrade;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header   X-Forwarded-Proto $scheme;
        }
    }
}

Další informace najdete v následujících článcích:

Linux na serveru Apache

Pokud chcete Blazor hostovat aplikaci za Apache v Linuxu, nakonfigurujte provoz HTTP a ProxyPass WebSocket.

V následujícím příkladu:

  • Kestrel server běží na hostitelském počítači.
  • Aplikace naslouchá provozu na portu 5000.
ProxyRequests       On
ProxyPreserveHost   On
ProxyPassMatch      ^/_blazor/(.*) http://localhost:5000/_blazor/$1
ProxyPass           /_blazor ws://localhost:5000/_blazor
ProxyPass           / http://localhost:5000/
ProxyPassReverse    / http://localhost:5000/

Povolte následující moduly:

a2enmod   proxy
a2enmod   proxy_wstunnel

Zkontrolujte chyby protokolu WebSocket v konzole prohlížeče. Příklady chyb:

  • Firefox nemůže navázat připojení k serveru na ws://the-domain-name.tld/_blazor?id=XXX.
  • Chyba: Nepodařilo se spustit přenos WebSockets: Chyba: Při přenosu došlo k chybě.
  • Chyba: Nepodařilo se spustit přenos LongPolling: TypeError: this.transport is undefined
  • Chyba: Nelze se připojit k serveru s žádným z dostupných přenosů. WebSockety selhaly
  • Chyba: Nelze odeslat data, pokud připojení není ve stavu Připojeno.

Další informace najdete v dokumentaci k Apache.

Měření latence sítě

Interoperabilitu JS je možné použít k měření latence sítě, jak ukazuje následující příklad:

@inject IJSRuntime JS

@if (latency is null)
{
    <span>Calculating...</span>
}
else
{
    <span>@(latency.Value.TotalMilliseconds)ms</span>
}

@code {
    private DateTime startTime;
    private TimeSpan? latency;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            startTime = DateTime.UtcNow;
            var _ = await JS.InvokeAsync<string>("toString");
            latency = DateTime.UtcNow - startTime;
            StateHasChanged();
        }
    }
}

Pro rozumné uživatelské rozhraní doporučujeme trvale nízkou latenci uživatelského rozhraní 250 ms nebo méně.

Hodnoty konfigurace hostitele

Blazor Server aplikace můžou přijímat hodnoty konfigurace obecného hostitele.

Nasazení

použití Blazor Server modelu hostování Blazor je spuštěno na serveru aplikace z ASP.NET Core. Aktualizace uživatelského rozhraní, zpracování událostí a volání JavaScriptu se zpracovávají přes SignalR připojení.

vyžaduje se webový server, který je hostitelem aplikace ASP.NET Core. Visual Studio zahrnuje šablonu projektu Blazor Server aplikace ( blazorserver šablona při použití dotnet new příkazu). Další informace o Blazor šablonách projektů naleznete v tématu ASP.NET Core Blazor struktura projektu .

Škálovatelnost

Naplánujte nasazení, aby se zajistilo co nejlepší využití dostupné infrastruktury pro Blazor Server aplikaci. Podívejte se na následující zdroje informací pro řešení Blazor Server škálovatelnosti aplikace:

Server nasazení

Při zvažování škálovatelnosti jednoho serveru (horizontální navýšení kapacity) je pravděpodobným zdrojem dostupným pro aplikaci první prostředek, který bude aplikace vyčerpat při zvýšení požadavků uživatelů. Dostupná paměť na serveru má vliv na:

  • Počet aktivních okruhů, které může server podporovat.
  • Latence uživatelského rozhraní u klienta.

Pokyny k vytváření zabezpečených a škálovatelných Blazor serverových aplikací najdete v tématu Pokyny pro zmírnění hrozeb pro ASP.NET Core Blazor Server .

Každý okruh používá pro minimální aplikaci Hello World ve stylu přibližně 250 kB paměti. Velikost okruhu závisí na kódu aplikace a požadavcích na údržbu stavu přidružených k jednotlivým součástem. Doporučujeme změřit požadavky na prostředky během vývoje vaší aplikace a infrastruktury, ale následující směrný plán může být výchozím bodem plánování cíle nasazení: Pokud očekáváte, že vaše aplikace bude podporovat 5 000 souběžných uživatelů, zvažte rozpočtování aspoň 1,3 GB paměti serveru do aplikace (nebo ~ 273 KB na uživatele).

SignalR rozšířeného

Blazor Serveraplikace používají ASP.NET Core SignalR ke komunikaci s prohlížečem. SignalR podmínky hostování a škálování se vztahují na Blazor Server aplikace.

Blazor funguje nejlépe při použití WebSockets jako SignalR přenosu z důvodu nižší latence, spolehlivosti a zabezpečení. Dlouhé cyklické dotazování se používá, SignalR když nejsou objekty WebSocket k dispozici nebo když je aplikace explicitně nakonfigurovaná tak, aby používala dlouhé cyklické dotazování. Při nasazování do Azure App Service nakonfigurujte aplikaci tak, aby používala objekty WebSocket v nastaveních Azure Portal služby. Podrobnosti o konfiguraci aplikace pro Azure App Service najdete v SignalR pokynech k publikování.

SignalRSlužba Azure

Pro aplikace doporučujeme používat SignalR službu Azure Blazor Server . Služba spolupracuje s centrem aplikace Blazor při škálování Blazor Server aplikace na velký počet souběžných SignalR připojení. Kromě toho SignalR globální dostupnost a vysoce výkonná datová centra služby významně pomáhají při snižování latence z důvodu geografické oblasti.

Důležité

Když jsou objekty WebSocket zakázané, Azure App Service simuluje připojení v reálném čase pomocí dlouhého cyklického dotazování http. Dlouhé cyklické dotazování HTTP je výrazně pomalejší než spuštění s povolenými objekty WebSockets, které nepoužívá cyklické dotazování na simulaci připojení typu klient-server.

Pro aplikace nasazené do Azure App Service doporučujeme používat objekty WebSockets Blazor Server . SignalR Služba Azure ve výchozím nastavení používá objekty WebSocket. Pokud aplikace nepoužívá SignalR službu Azure, přečtěte si téma Publikování ASP.NET Core do SignalR Azure App Service .

Další informace naleznete v tématu:

Konfigurace

Pokud chcete nakonfigurovat aplikaci pro službu Azure SignalR , musí aplikace podporovat rychlé relace, kde se klienti při předvykreslování přesměrují zpátky na stejný server. ServerStickyModeMožnost nebo konfigurační hodnota je nastavena na Required . Aplikace obvykle vytváří konfiguraci pomocí jednoho z následujících přístupů:

  • Startup.ConfigureServices:

    services.AddSignalR().AddAzureSignalR(options =>
{
    options.ServerStickyMode = 
    Microsoft.Azure.SignalR.ServerStickyMode.Required;
});

  • Konfigurace (použijte jeden z následujících přístupů):

    • V appsettings.json:

      "Azure:SignalR:StickyServerMode": "Required"

    • Nastavení konfigurační > aplikace služby App Service v Azure Portal (název: Azure__SignalR__StickyServerMode , hodnota: Required ). Tento přístup se přijme pro aplikaci automaticky, když zřizujete SignalR službu Azure.

Zřízení služby Azure SignalR

Zřízení SignalR služby Azure pro aplikaci v Visual Studio:

  1. vytvořte profil publikování aplikací Azure v Visual Studio pro Blazor Server aplikaci.
  2. Přidejte do profilu závislost SignalR služby Azure . Pokud předplatné Azure nemá stávající SignalR instanci služby Azure, která se má přiřadit k aplikaci, vyberte vytvořit novou SignalR instanci služby Azure a zřídit novou instanci služby.
  3. Publikovat aplikaci do Azure

zřizování SignalR služby Azure v Visual Studio automaticky umožňuje rychlé relace a přidává SignalR připojovací řetězec do konfigurace app Service.

Azure App Service

Tato část platí jenom pro aplikace, které nepoužívají SignalR službu Azure.

Pokud se SignalR Služba Azure nepoužívá, App Service vyžaduje konfiguraci spřažení a směrování žádostí o aplikace (ARR) a objekty WebSockets. Klienti připojují své objekty WebSocket přímo k aplikaci, nikoli ke službě Azure SignalR .

Pro konfiguraci aplikace použijte následující pokyny:

IIS

Při použití služby IIS povolte:

Kubernetes

Vytvořte definici příchozího přenosu dat s následujícími Kubernetes poznámkami pro rychlé relace:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: <ingress-name>
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "affinity"
    nginx.ingress.kubernetes.io/session-cookie-expires: "14400"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "14400"

Linux na serveru Nginx

SignalRAby objekty WebSocket fungovaly správně, zkontrolujte, že je proxy Upgrade a Connection hlavičkový Server nastavené na následující hodnoty a zda jsou $connection_upgrade namapovány na jednu z těchto možností:

  • Hodnota hlavičky upgradu je standardně nastavená.
  • close Pokud záhlaví upgradu chybí nebo je prázdné.
http {
    map $http_upgrade $connection_upgrade {
        default Upgrade;
        ''      close;
    }

    server {
        listen      80;
        server_name example.com *.example.com;
        location / {
            proxy_pass         http://localhost:5000;
            proxy_http_version 1.1;
            proxy_set_header   Upgrade $http_upgrade;
            proxy_set_header   Connection $connection_upgrade;
            proxy_set_header   Host $host;
            proxy_cache_bypass $http_upgrade;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header   X-Forwarded-Proto $scheme;
        }
    }
}

Další informace najdete v následujících článcích:

Linux na serveru Apache

Pro hostování Blazor aplikace za Apache v systému Linux nakonfigurujte ProxyPass provoz http a WebSockets.

V následujícím příkladu:

  • Kestrel Server běží na hostitelském počítači.
  • Aplikace naslouchá provozu na portu 5000.
ProxyRequests       On
ProxyPreserveHost   On
ProxyPassMatch      ^/_blazor/(.*) http://localhost:5000/_blazor/$1
ProxyPass           /_blazor ws://localhost:5000/_blazor
ProxyPass           / http://localhost:5000/
ProxyPassReverse    / http://localhost:5000/

Povolte následující moduly:

a2enmod   proxy
a2enmod   proxy_wstunnel

Podívejte se na chyby protokolu WebSocket v konzole prohlížeče. Příklady chyb:

  • Firefox nemůže navázat připojení k serveru na adrese ws://the-domain-name.tld/_blazor?id=XXX.
  • Chyba: Nepodařilo se spustit objekty WebSockets transportu: Chyba: došlo k chybě přenosu.
  • Chyba: nepovedlo se spustit přenos ' LongPolling ': TypeError: this. Transport není definovaný.
  • Chyba: Nelze se připojit k serveru pomocí žádné z dostupných přenosů. Selhání objektu WebSockets
  • Chyba: nelze odeslat data, pokud připojení není ve stavu připojeno.

Další informace najdete v dokumentaci k Apache.

Měření latence sítě

Zprostředkovatel komunikace js lze použít k měření latence sítě, jak ukazuje následující příklad:

@inject IJSRuntime JS

@if (latency is null)
{
    <span>Calculating...</span>
}
else
{
    <span>@(latency.Value.TotalMilliseconds)ms</span>
}

@code {
    private DateTime startTime;
    private TimeSpan? latency;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            startTime = DateTime.UtcNow;
            var _ = await JS.InvokeAsync<string>("toString");
            latency = DateTime.UtcNow - startTime;
            StateHasChanged();
        }
    }
}

Pro přiměřené prostředí uživatelského rozhraní doporučujeme, abyste trvalou latenci uživatelského rozhraní 250 ms nebo méně.

Hodnoty konfigurace hostitele

Blazor Server aplikace můžou přijímat hodnoty konfigurace obecného hostitele.

Nasazení

použití Blazor Server modelu hostování Blazor je spuštěno na serveru aplikace z ASP.NET Core. Aktualizace uživatelského rozhraní, zpracování událostí a volání JavaScriptu se zpracovávají přes SignalR připojení.

vyžaduje se webový server, který je hostitelem aplikace ASP.NET Core. Visual Studio zahrnuje šablonu projektu Blazor Server aplikace ( blazorserver šablona při použití dotnet new příkazu). Další informace o Blazor šablonách projektů naleznete v tématu ASP.NET Core Blazor struktura projektu .

Škálovatelnost

Naplánujte nasazení, aby se zajistilo co nejlepší využití dostupné infrastruktury pro Blazor Server aplikaci. Podívejte se na následující zdroje informací pro řešení Blazor Server škálovatelnosti aplikace:

Server nasazení

Při zvažování škálovatelnosti jednoho serveru (horizontální navýšení kapacity) je pravděpodobným zdrojem dostupným pro aplikaci první prostředek, který bude aplikace vyčerpat při zvýšení požadavků uživatelů. Dostupná paměť na serveru má vliv na:

  • Počet aktivních okruhů, které může server podporovat.
  • Latence uživatelského rozhraní u klienta.

Pokyny k vytváření zabezpečených a škálovatelných Blazor serverových aplikací najdete v tématu Pokyny pro zmírnění hrozeb pro ASP.NET Core Blazor Server .

Každý okruh používá pro minimální aplikaci Hello World ve stylu přibližně 250 kB paměti. Velikost okruhu závisí na kódu aplikace a požadavcích na údržbu stavu přidružených k jednotlivým součástem. Doporučujeme změřit požadavky na prostředky během vývoje vaší aplikace a infrastruktury, ale následující směrný plán může být výchozím bodem plánování cíle nasazení: Pokud očekáváte, že vaše aplikace bude podporovat 5 000 souběžných uživatelů, zvažte rozpočtování aspoň 1,3 GB paměti serveru do aplikace (nebo ~ 273 KB na uživatele).

SignalR rozšířeného

Blazor Serveraplikace používají ASP.NET Core SignalR ke komunikaci s prohlížečem. SignalR podmínky hostování a škálování se vztahují na Blazor Server aplikace.

Blazor funguje nejlépe při použití WebSockets jako SignalR přenosu z důvodu nižší latence, spolehlivosti a zabezpečení. Dlouhé cyklické dotazování se používá, SignalR když nejsou objekty WebSocket k dispozici nebo když je aplikace explicitně nakonfigurovaná tak, aby používala dlouhé cyklické dotazování. Při nasazování do Azure App Service nakonfigurujte aplikaci tak, aby používala objekty WebSocket v nastaveních Azure Portal služby. Podrobnosti o konfiguraci aplikace pro Azure App Service najdete v SignalR pokynech k publikování.

SignalRSlužba Azure

Pro aplikace doporučujeme používat SignalR službu Azure Blazor Server . Služba spolupracuje s centrem aplikace Blazor při škálování Blazor Server aplikace na velký počet souběžných SignalR připojení. Kromě toho SignalR globální dostupnost a vysoce výkonná datová centra služby významně pomáhají při snižování latence z důvodu geografické oblasti.

Důležité

Když jsou objekty WebSocket zakázané, Azure App Service simuluje připojení v reálném čase pomocí dlouhého cyklického dotazování http. Dlouhé cyklické dotazování HTTP je výrazně pomalejší než spuštění s povolenými objekty WebSockets, které nepoužívá cyklické dotazování na simulaci připojení typu klient-server.

Pro aplikace nasazené do Azure App Service doporučujeme používat objekty WebSockets Blazor Server . SignalR Služba Azure ve výchozím nastavení používá objekty WebSocket. Pokud aplikace nepoužívá SignalR službu Azure, přečtěte si téma Publikování ASP.NET Core do SignalR Azure App Service .

Další informace naleznete v tématu:

Konfigurace

Pokud chcete nakonfigurovat aplikaci pro službu Azure SignalR , musí aplikace podporovat rychlé relace, kde se klienti při předvykreslování přesměrují zpátky na stejný server. ServerStickyModeMožnost nebo konfigurační hodnota je nastavena na Required . Aplikace obvykle vytváří konfiguraci pomocí jednoho z následujících přístupů:

  • Startup.ConfigureServices:

    services.AddSignalR().AddAzureSignalR(options =>
{
    options.ServerStickyMode = 
    Microsoft.Azure.SignalR.ServerStickyMode.Required;
});

  • Konfigurace (použijte jeden z následujících přístupů):

    • V appsettings.json:

      "Azure:SignalR:StickyServerMode": "Required"

    • Nastavení konfigurační > aplikace služby App Service v Azure Portal (název: Azure__SignalR__StickyServerMode , hodnota: Required ). Tento přístup se přijme pro aplikaci automaticky, když zřizujete SignalR službu Azure.

Zřízení služby Azure SignalR

Zřízení SignalR služby Azure pro aplikaci v Visual Studio:

  1. vytvořte profil publikování aplikací Azure v Visual Studio pro Blazor Server aplikaci.
  2. Přidejte do profilu závislost SignalR služby Azure . Pokud předplatné Azure nemá stávající SignalR instanci služby Azure, která se má přiřadit k aplikaci, vyberte vytvořit novou SignalR instanci služby Azure a zřídit novou instanci služby.
  3. Publikovat aplikaci do Azure

zřizování SignalR služby Azure v Visual Studio automaticky umožňuje rychlé relace a přidává SignalR připojovací řetězec do konfigurace app Service.

Azure App Service

Tato část platí jenom pro aplikace, které nepoužívají SignalR službu Azure.

Pokud se SignalR Služba Azure nepoužívá, App Service vyžaduje konfiguraci spřažení a směrování žádostí o aplikace (ARR) a objekty WebSockets. Klienti připojují své objekty WebSocket přímo k aplikaci, nikoli ke službě Azure SignalR .

Pro konfiguraci aplikace použijte následující pokyny:

IIS

Při použití služby IIS povolte:

Kubernetes

Vytvořte definici příchozího přenosu dat s následujícími Kubernetes poznámkami pro rychlé relace:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: <ingress-name>
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "affinity"
    nginx.ingress.kubernetes.io/session-cookie-expires: "14400"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "14400"

Linux na serveru Nginx

SignalRAby objekty WebSocket fungovaly správně, zkontrolujte, že je proxy Upgrade a Connection hlavičkový Server nastavené na následující hodnoty a zda jsou $connection_upgrade namapovány na jednu z těchto možností:

  • Hodnota hlavičky upgradu je standardně nastavená.
  • close Pokud záhlaví upgradu chybí nebo je prázdné.
http {
    map $http_upgrade $connection_upgrade {
        default Upgrade;
        ''      close;
    }

    server {
        listen      80;
        server_name example.com *.example.com
        location / {
            proxy_pass         http://localhost:5000;
            proxy_http_version 1.1;
            proxy_set_header   Upgrade $http_upgrade;
            proxy_set_header   Connection $connection_upgrade;
            proxy_set_header   Host $host;
            proxy_cache_bypass $http_upgrade;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header   X-Forwarded-Proto $scheme;
        }
    }
}

Další informace najdete v následujících článcích:

Linux na serveru Apache

Pro hostování Blazor aplikace za Apache v systému Linux nakonfigurujte ProxyPass provoz http a WebSockets.

V následujícím příkladu:

  • Kestrel Server běží na hostitelském počítači.
  • Aplikace naslouchá provozu na portu 5000.
ProxyRequests       On
ProxyPreserveHost   On
ProxyPassMatch      ^/_blazor/(.*) http://localhost:5000/_blazor/$1
ProxyPass           /_blazor ws://localhost:5000/_blazor
ProxyPass           / http://localhost:5000/
ProxyPassReverse    / http://localhost:5000/

Povolte následující moduly:

a2enmod   proxy
a2enmod   proxy_wstunnel

Podívejte se na chyby protokolu WebSocket v konzole prohlížeče. Příklady chyb:

  • Firefox nemůže navázat připojení k serveru na adrese ws://the-domain-name.tld/_blazor?id=XXX.
  • Chyba: Nepodařilo se spustit objekty WebSockets transportu: Chyba: došlo k chybě přenosu.
  • Chyba: nepovedlo se spustit přenos ' LongPolling ': TypeError: this. Transport není definovaný.
  • Chyba: Nelze se připojit k serveru pomocí žádné z dostupných přenosů. Selhání objektu WebSockets
  • Chyba: nelze odeslat data, pokud připojení není ve stavu připojeno.

Další informace najdete v dokumentaci k Apache.

Měření latence sítě

Zprostředkovatel komunikace js lze použít k měření latence sítě, jak ukazuje následující příklad:

@inject IJSRuntime JS

@if (latency is null)
{
    <span>Calculating...</span>
}
else
{
    <span>@(latency.Value.TotalMilliseconds)ms</span>
}

@code {
    private DateTime startTime;
    private TimeSpan? latency;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            startTime = DateTime.UtcNow;
            var _ = await JS.InvokeAsync<string>("toString");
            latency = DateTime.UtcNow - startTime;
            StateHasChanged();
        }
    }
}

Pro přiměřené prostředí uživatelského rozhraní doporučujeme, abyste trvalou latenci uživatelského rozhraní 250 ms nebo méně.