Bagikan melalui

Pengantar Scaleout di SignalR 1.x

  • Artikel

oleh Patrick Fletcher

Peringatan

Dokumentasi ini bukan untuk versi terbaru SignalR. Lihat ASP.NET Core SignalR.

Secara umum, ada dua cara untuk menskalakan aplikasi web: meningkatkan dan meluaskan skala.

  • Meningkatkan skala berarti menggunakan server yang lebih besar (atau VM yang lebih besar) dengan lebih banyak RAM, CPU, dll.
  • Peluasan skala berarti menambahkan lebih banyak server untuk menangani beban.

Masalah dengan peningkatan skala adalah Anda dengan cepat mencapai batas ukuran komputer. Di luar itu, Anda perlu menskalakan. Namun, ketika Anda memperluas skala, klien dapat dirutekan ke server yang berbeda. Klien yang tersambung ke satu server tidak akan menerima pesan yang dikirim dari server lain.

Cuplikan layar masalah yang dihadapi klien ketika server diskalakan adalah bahwa karena terhubung ke satu server, klien tidak akan menerima pesan yang dikirim dari server lain.

Salah satu solusinya adalah meneruskan pesan antar server, menggunakan komponen yang disebut backplane. Dengan backplane diaktifkan, setiap instans aplikasi mengirim pesan ke backplane, dan backplane meneruskannya ke instans aplikasi lainnya. (Dalam elektronik, backplane adalah sekelompok konektor paralel. Dengan analogi, backplane SignalR menghubungkan beberapa server.)

Cuplikan layar solusi untuk meneruskan pesan antar server menggunakan komponen yang disebut backplane.

SignalR saat ini menyediakan tiga backplanes:

  • Azure Service Bus. Service Bus adalah infrastruktur olahpesan yang memungkinkan komponen mengirim pesan dengan cara yang digabungkan secara longgar.
  • Redis. Redis adalah penyimpanan kunci-nilai dalam memori. Redis mendukung pola terbitkan/berlangganan ("pub/sub") untuk mengirim pesan.
  • SQL Server. Backplane SQL Server menulis pesan ke tabel SQL. Backplane menggunakan Service Broker untuk olahpesan yang efisien. Namun, ini juga berfungsi jika Service Broker tidak diaktifkan.

Jika Anda menyebarkan aplikasi di Azure, pertimbangkan untuk menggunakan backplane Azure Service Bus. Jika Anda menyebarkan ke farm server Anda sendiri, pertimbangkan backplanes SQL Server atau Redis.

Topik berikut berisi tutorial langkah demi langkah untuk setiap backplane:

Implementasi

Di SignalR, setiap pesan dikirim melalui bus pesan. Bus pesan mengimplementasikan antarmuka IMessageBus , yang menyediakan abstraksi terbitkan/berlangganan. Backplanes berfungsi dengan mengganti IMessageBus default dengan bus yang dirancang untuk backplane tersebut. Misalnya, bus pesan untuk Redis adalah RedisMessageBus, dan menggunakan mekanisme pub/sub Redis untuk mengirim dan menerima pesan.

Setiap instans server terhubung ke backplane melalui bus. Ketika pesan dikirim, pesan masuk ke backplane, dan backplane mengirimkannya ke setiap server. Ketika server mendapatkan pesan dari backplane, server menempatkan pesan di cache lokalnya. Server kemudian mengirimkan pesan kepada klien dari cache lokalnya.

Untuk setiap koneksi klien, kemajuan klien dalam membaca aliran pesan dilacak menggunakan kursor. (Kursor mewakili posisi di aliran pesan.) Jika klien terputus lalu terhubung kembali, klien akan meminta pesan apa pun yang tiba setelah nilai kursor klien. Hal yang sama terjadi ketika koneksi menggunakan polling panjang. Setelah permintaan polling panjang selesai, klien membuka koneksi baru dan meminta pesan yang tiba setelah kursor.

Mekanisme kursor berfungsi bahkan jika klien dirutekan ke server yang berbeda saat menyambungkan kembali. Backplane mengetahui semua server, dan tidak masalah server mana yang terhubung dengan klien.

Batasan

Menggunakan backplane, throughput pesan maksimum lebih rendah daripada ketika klien berbicara langsung dengan satu simpul server. Itu karena backplane meneruskan setiap pesan ke setiap simpul, sehingga backplane dapat menjadi penyempitan. Apakah batasan ini adalah masalah tergantung pada aplikasi. Misalnya, berikut adalah beberapa skenario SignalR yang khas:

  • Siaran server (misalnya, ticker stok): Backplanes bekerja dengan baik untuk skenario ini, karena server mengontrol laju pengiriman pesan.
  • Klien-ke-klien (misalnya, obrolan): Dalam skenario ini, backplane mungkin menjadi hambatan jika jumlah pesan diskalakan dengan jumlah klien; artinya, jika tingkat pesan tumbuh secara proporsional saat lebih banyak klien bergabung.
  • Realtime frekuensi tinggi (misalnya, game real-time): Backplane tidak disarankan untuk skenario ini.

Mengaktifkan pelacakan untuk penskalaan SignalR

Untuk mengaktifkan pelacakan untuk backplanes, tambahkan bagian berikut ke file web.config, di bawah elemen konfigurasi akar:

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