Úvod do škálování aplikace SignalR 1.x

Patrick Fletcher

Obecně platí, že existují dva způsoby, jak škálovat webovou aplikaci: vertikálně navýšit kapacitu a vertikálně navýšit kapacitu.

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

Problémem vertikálního navýšení kapacity je, že jste rychle dosáhli limitu velikosti počítače. Kromě toho potřebujete horizontální navýšení kapacity. 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.

Jedním z řešení je přeposílá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á ostatním instancím aplikace. (V elektronice je backplane skupina paralelních konektorů. Analogicky, backplane SignalR spojuje více serverů.)

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

• Azure Service Bus. Service Bus je infrastruktura zasílání zpráv, která umožňuje komponentám posílat zprávy volně propojený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í Azure Service Bus backplane. Pokud nasazujete do vlastní serverové farmy, zvažte backplanes SQL Server nebo Redis.

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

• Škálování aplikace SignalR službou Azure Service Bus
• Šklálování aplikace SignalR službou Redis
• Šklálování aplikace SignalR SQL Serverem

Implementace

V 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 nahradí výchozí IMessageBus sběrnici určenou pro toto backplane. 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 Redis pub/sub .

Každá instance serveru se připojí 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, vloží zprávu do místní mezipaměti. Server pak doručuje zprávy klientům z 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 za hodnotou kurzoru klienta. Totéž se stane, když připojení používá dlouhé dotazování. Po dokončení dlouhé žádosti o dotazování 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í backplane je maximální propustnost zpráv nižší, než když klienti komunikují přímo k jednomu uzlu serveru. Je to proto, že backplane předá každou zprávu do každého uzlu, takže backplane se 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:

• Vysílání serveru (například 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á, že pokud rychlost zpráv roste proporcionálně 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čuje 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 konfiguračním elementu následující oddíly:

<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>