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