Azure SignalR 服务中的服务模式
服务模式是 Azure SignalR 服务中的一个重要概念。 SignalR 服务目前支持三种服务模式：默认、无服务器和经典。 SignalR 服务资源在每种模式下的行为不同。 本文将介绍如何根据方案选择合适的服务模式。
设置服务模式
在 Azure 门户中创建新的 SignalR 资源时，系统会要求你指定服务模式。
也可以稍后在设置菜单中更改服务模式。
通过 Azure SignalR CLI 使用 az signalr create 和 az signalr update 来设置或更改服务模式。
默认模式
顾名思义，默认模式是 SignalR 服务的默认服务模式。 在默认模式下，应用程序作为典型的 ASP.NET Core SignalR 或 ASP.NET SignalR（已弃用）应用程序工作。 有一个托管中心的 Web 服务器应用程序，称为中心服务器，客户端与中心服务器进行全双工通信。 ASP.NET Core SignalR 和 Azure SignalR Service 之间的差别在于，客户端和服务器不是直接连接客户端和中心服务器，而是连接到 SignalR 服务并将该服务用作代理。 下图显示了默认模式下的典型应用程序结构。
如果你要将某个 SignalR 应用程序用于 SignalR 服务，默认模式通常是正确的选择。
默认模式下的连接路由
在默认模式下，中心服务器和 SignalR 服务之间存在 WebSocket 连接（称为服务器连接）。 这些连接用于在服务器和客户端之间传输消息。 当连接了一个新的客户端时，SignalR 服务会通过现有服务器连接将客户端路由到一台中心服务器（假设你拥有多台服务器）。 客户端连接将在其生存期内保留在同一中心服务器上。 此属性称为连接粘性。 当客户端发送消息时，消息始终转到同一中心服务器。 通过这种粘性行为，可以安全地保持中心服务器上各个连接的某些状态。 例如，如果你要在服务器和客户端之间流式传输某些内容，则无需考虑数据包转到不同服务器这一情况。
重要
在默认模式下，如果未事先将中心服务器连接到服务，客户端将无法连接。 如果由于网络中断或服务器重启而断开了所有集线器服务器的连接，则客户端连接将收到一条错误消息，告知你未连接任何服务器。 你需要责任确保始终至少有一台中心服务器连接到 SignalR 服务。 例如，可以设计使用多个中心服务器的应用程序，然后确保这些服务器不会同时全部脱机。
默认路由模型还意味着当中心服务器脱机时，路由到该服务器的连接将会断开。 当中心服务器由于维护而脱机时，你应该预料到连接会断开，并且应该处理重新连接以尽量减少对应用程序的影响。
注意
在默认模式下，如果你不想通过中心服务器发送消息，也可以使用 REST API、管理 SDK 和函数绑定将消息直接发送到客户端。 在默认模式下，客户端连接仍由中心服务器处理，上游终结点在该模式下无法正常工作。
无服务器模式
与默认模式不同，无服务器模式不需要运行中心服务器，这就是此模式称作“无服务器”的原因。SignalR 服务负责保持客户端连接。 无法保证连接粘性，并且 HTTP 请求的效率可能低于 WebSocket 连接。
无服务器模式与 Azure Functions 配合工作以提供实时消息传递功能。 客户端使用 Azure Functions 的 SignalR 服务绑定（称为函数绑定）将消息作为输出绑定发送。
由于没有服务器连接，如果你尝试使用服务器 SDK 建立服务器连接，将会收到错误。 SignalR 服务将拒绝在无服务器模式下进行的服务器连接尝试。
无服务器模式没有连接粘性，但你仍可以让服务器端应用程序将消息推送到客户端。 在无服务器模式下，可通过两种方式将消息推送到客户端：
- 将 REST API 用于一次性发送事件，或
- 使用 WebSocket 连接，以便更有效地发送多条消息。 此 WebSocket 连接不同于服务器连接。
服务器应用程序还可以从客户端接收消息和连接事件。 SignalR 服务使用 webhook 将消息和连接事件传送到预配置的终结点（称为上游终结点）。 只能在无服务器模式下配置上游终结点。 有关详细信息，请参阅上游终结点。
下图显示了无服务器模式的工作原理。
经典模式
注意
经典模式主要是为了使那些在默认模式和无服务器模式引入之前创建的应用程序能够后向兼容。 除非万不得已，否则请不要使用经典模式。 根据你的方案，为新应用程序使用默认或无服务器模式。 应考虑重新设计现有应用程序以消除对经典模式的需要。
经典模式是默认模式和无服务器模式的混合模式。 在经典模式下，连接类型取决于建立客户端连接时是否连接了中心服务器。 如果有中心服务器，客户端连接将路由到一台中心服务器。 如果中心服务器不可用，客户端连接将在受限无服务器模式下建立，在这种模式下，客户端到服务器的消息无法传送到中心服务器。 经典模式无服务器连接不支持上游终结点等某些功能。
如果所有中心服务器由于某种原因而脱机，则会在无服务器模式下建立连接。 你需要负责确保至少有一台中心服务器始终可用。
选择正确的服务模式
现在，你应了解了服务模式之间的差异，并知道了如何在它们之间进行选择。 如前所述，不建议将经典模式用于新的或现有的应用程序。 下面提供了一些附加提示，可帮助你选择正确的服务模式，并停用现有应用程序的经典模式。
如果你熟悉 SignalR 库的工作方式，并希望从自托管 SignalR 转为使用 Azure SignalR 服务，请选择默认模式。 默认模式的工作方式与自托管 SignalR 完全相同，你可以在 SignalR 库中使用相同的编程模型。 SignalR 服务充当客户端与中心服务器之间的代理。
如果你要创建新的应用程序，且不想保持中心服务器和服务器连接，请选择无服务器模式。 无服务器模式与 Azure Functions 配合工作，这样你就根本无需维护任何服务器。 你仍可以使用 REST API、管理 SDK 或函数绑定 + 上游终结点进行双工通信，但编程模型将不同于 SignalR 库。
如果你有两个中心服务器为客户端连接提供服务，并且有一个后端应用程序直接将消息推送到客户端，请选择默认模式。 默认模式与无服务器模式之间的主要差别在于，你是否具有中心服务器以及客户端连接如何路由。 两种模式下均可使用 REST API/管理 SDK/函数绑定。
如果你确实使用了某种混合方案，应考虑将用例分成多个 SignalR Service 实例，并根据用例设置服务模式。 需要经典模式的混合方案的一个示例是在同一 SignalR 资源上使用两个不同的中心。 一个中心用作传统的 SignalR 中心，另一个中心与 Azure Functions 配合使用。 此示例应拆分为两个资源，其中一个实例处于默认模式，另一个实例处于无服务器模式。
后续步骤
请参阅以下文章详细了解如何使用默认模式和无服务器模式。