Sdílet prostřednictvím

Úvod do škálování aplikace SignalR

  • Článek

Patrick Fletcher

Upozornění

Tato dokumentace není určená pro nejnovější verzi služby SignalR. Podívejte se na ASP.NET Core SignalR.

Verze softwaru použité v tomto tématu

Předchozí verze tohoto tématu

Informace o starších verzích služby SignalR najdete v tématu Starší verze služby SignalR.

Dotazy a komentáře

V komentářích v dolní části stránky nám napište, jak se vám tento kurz líbil a co bychom mohli zlepšit. Pokud máte dotazy, které nesouvisejí přímo s kurzem, můžete je publikovat na fóru ASP.NET SignalR nebo StackOverflow.com.

Obecně existují dva způsoby škálování webové aplikace: vertikální navýšení a horizontální navýšení kapacity.

  • Vertikální navýšení kapacity znamená použití většího serveru (nebo většího virtuálního počítače) s více paměti RAM, procesory atd.
  • Horizontální navýšení kapacity znamená přidání dalších serverů pro zvládnutí zatížení.

Problémem při vertikálním navýšení kapacity je, že jste rychle dosáhli limitu velikosti počítače. Kromě toho je potřeba škálovat na více instancí. Při horizontálním navýšení kapacity se ale klienti můžou směrovat na jiné servery. Klient připojený k jednomu serveru nebude přijímat zprávy odeslané z jiného serveru.

Diagram znázorňující šipky od klientů do Load Balancer na servery

Jedním z řešení je předávání zpráv mezi servery pomocí komponenty označované jako backplane. Když je povolené backplane, každá instance aplikace odesílá zprávy do backplane a backplane je předává jiným instancím aplikace. (V elektronikě je propojovací rovina skupina paralelních konektorů. Podobně propojovací rovina SignalR spojuje více serverů.)

Diagram znázorňující šipky od serveru aplikace Signal R do backplane na server aplikace Signal R k počítačům

SignalR v současné době poskytuje tři backplane:

  • Azure Service Bus. Service Bus je infrastruktura zasílání zpráv, která umožňuje komponentám posílat zprávy volně provázaným způsobem.
  • Redis. Redis je úložiště klíč-hodnota v paměti. Redis podporuje model publikování/odběru (pub/sub) pro odesílání zpráv.
  • SQL Server. Backplane SQL Server zapisuje zprávy do tabulek SQL. Backplane používá service broker pro efektivní zasílání zpráv. Funguje ale také v případě, že není povolená služba Service Broker.

Pokud nasadíte aplikaci v Azure, zvažte použití backplane Redis pomocí Azure Redis Cache. Pokud nasazujete do vlastní serverové farmy, zvažte SQL Server nebo backplanes Redis.

Následující témata obsahují podrobné kurzy pro každé backplane:

Implementace

Ve službě SignalR se každá zpráva odesílá prostřednictvím sběrnice zpráv. Sběrnice zpráv implementuje rozhraní IMessageBus , které poskytuje abstrakci publikování/odběru. Backplanes fungují tak, že výchozí IMessageBus nahradí sběrnici určenou pro toto rozhraní. Například sběrnice zpráv pro Redis je RedisMessageBus a k odesílání a přijímání zpráv používá mechanismus pub/sub Redis.

Každá instance serveru se připojuje k backplane prostřednictvím sběrnice. Když je zpráva odeslána, přejde do backplane a backplane ji odešle na každý server. Když server obdrží zprávu z backplane, umístí zprávu do místní mezipaměti. Server pak doručuje zprávy klientům ze své místní mezipaměti.

U každého připojení klienta se průběh klienta při čtení streamu zpráv sleduje pomocí kurzoru. (Kurzor představuje pozici v datovém proudu zpráv.) Pokud se klient odpojí a pak se znovu připojí, požádá sběrnici o všechny zprávy, které přišly po hodnotě kurzoru klienta. Totéž se stane, když připojení používá dlouhé dotazování. Po dokončení dlouhého dotazu klient otevře nové připojení a požádá o zprávy, které přišly za kurzorem.

Mechanismus kurzoru funguje i v případě, že je klient při opětovném připojení směrován na jiný server. Backplane ví o všech serverech a nezáleží na tom, ke kterému serveru se klient připojuje.

Omezení

Při použití rozhraní backplane je maximální propustnost zpráv nižší, než když klienti komunikují přímo s jedním serverovým uzlem. Je to proto, že backplane předává každou zprávu do každého uzlu, takže se backplane může stát kritickým bodem. To, jestli je toto omezení problémem, závisí na aplikaci. Tady jsou například některé typické scénáře služby SignalR:

  • Všesměrové vysílání serveru (např. burzovní ticker): Pro tento scénář dobře fungují backplanes, protože server řídí rychlost, s jakou se zprávy odesílají.
  • Klient-klient (např. chat): V tomto scénáři může být backplane kritickým bodem, pokud se počet zpráv škáluje s počtem klientů; to znamená, pokud rychlost zpráv roste úměrně s tím, jak se připojuje více klientů.
  • Vysokofrekvenční realtime (např. hry v reálném čase): Pro tento scénář se nedoporučují backplane.

Povolení trasování pro škálování služby SignalR

Pokud chcete povolit trasování pro backplanes, přidejte do souboru web.config v kořenovém elementu konfigurace následující části:

<configuration>
  <system.diagnostics>
    <sources>
      <source name="SignalR.SqlMessageBus">
        <listeners>
          <add name="SignalR-Bus" />
        </listeners>
      </source>
      <source name="SignalR.ServiceBusMessageBus">
        <listeners>
          <add name="SignalR-Bus" />
        </listeners>
      </source>
      <source name="SignalR.ScaleoutMessageBus">
        <listeners>
          <add name="SignalR-Bus" />
        </listeners>
      </source>
    </sources>
    <switches>
      <add name="SignalRSwitch" value="Verbose" />
      <!-- Off, Critical, Error, Warning, Information, Verbose -->
    </switches>
    <sharedListeners>
      <add name="SignalR-Bus" 
          type="System.Diagnostics.TextWriterTraceListener" 
          initializeData="bus.log.txt" />
    </sharedListeners>
    <trace autoflush="true" />
  </system.diagnostics>
  . . .
</configuration>