实时系统是一种计算系统，旨在实时响应事件和处理数据。它们能确保对外部事件做出及时准确的响应，有效处理金融、物流、游戏、医疗保健等各个领域的任务。实时系统在现代软件开发中至关重要，可实现客户端和服务器之间无缝的网络和移动应用通信。
开发人员可利用各种技术和协议来实现实时应用功能。其中一些协议包括WebSockets、SignalR、Server-Sent Events（SSE）和 Long Polling，它们提供了不同的性能级别、延迟时间和易实施性。为实时通信选择正确的技术会极大地影响应用程序的效率和响应能力。在本文中，我们将探讨两种流行的实时系统架构解决方案：WebSockets 和 SignalR。我们将深入探讨它们的工作原理、优势、用例，以及如何为您的应用程序选择合适的解决方案。
了解 WebSockets
WebSocket 是一种通信协议，可在客户端和服务器之间通过单个持久连接实现真正的实时双向通信。与传统的请求-响应模式不同，WebSocket 保持低延迟、全双工连接，允许客户端和服务器之间持续传输数据。WebSocket 协议与 HTTP 和 HTTPS 采用相同的端口（分别为 80 端口和 443 端口），因此与现有的网络基础设施兼容。
WebSocket 使用 HTTP 初始握手建立连接，然后使用 WebSocket 框架传输数据。连接建立后，数据可以同时双向流动，减少了延迟，非常适合在线聊天、通知和实时更新等实时应用。使用 WebSockets 的一些好处包括
- 低延迟：WebSockets 提供持久连接，减少了创建和关闭连接的开销，从而降低了延迟。
- 全双工通信：双向数据流允许服务器和客户端同时发送和接收数据，提高了实时应用程序的响应速度。
- 兼容性：WebSocket 通过 HTTP 和 HTTPS 端口工作，与现有的网络基础设施兼容。
- 可扩展性：基于 WebSocket 的应用程序可以使用各种技术进行扩展，如负载平衡和水平扩展。
不过，WebSockets 也有潜在的缺点，可能并不适合所有应用场景。使用 WebSockets 的一些缺点包括
- 复杂性：实施基于 WebSocket 的系统可能比使用 SignalR 等更高级的库更困难，因为它需要手动管理连接设置、错误处理和消息框架。
- 支持有限：虽然大多数现代浏览器都支持 WebSocket 协议，但一些较旧的浏览器和平台可能不支持该协议，从而限制了其使用范围。
SignalR 入门
SignalR 是微软的一个开源库，可简化实时网络应用程序的构建。它使开发人员能够在客户端和服务器之间添加双向通信，为 WebSockets、服务器发送事件和长轮询等各种传输协议提供抽象。SignalR 可根据客户端和服务器的能力自动选择最佳通信方法，确保最佳性能和兼容性。
图片来源：Microsoft Learn微软学习
SignalR 利用.NET 中异步编程的强大功能，提供了一个易于使用的 API 来构建实时应用程序。开发人员可以创建服务器端集线器来处理客户端连接、管理客户端表示并向连接的客户端广播消息。SignalR 的客户端库适用于各种平台，包括 JavaScript、.NET 和Java。使用 SignalR 的一些优势包括
- 简单：SignalR 提供高级抽象和应用程序接口，与直接使用 WebSockets 相比，更容易构建实时应用程序。
- 自动选择协议：SignalR 可根据客户端和服务器的能力自动选择最佳通信协议，无论底层技术如何，都能确保流畅的用户体验。
- 广泛的平台支持：SignalR 包含适用于各种平台的客户端库，包括 JavaScript、.NET 和 Java，因此通用性强，适用于各种应用。
- 可扩展性：SignalR 的设计支持在多台服务器上进行扩展，并提供内置机制来处理，例如使用 Redis、Azure 服务总线或自定义背板。
不过，SignalR 也有一些潜在的缺点，开发人员应加以考虑：
- 依赖 .NET：SignalR 依赖于 .NET 技术，这对于不熟悉该平台或偏好其他语言和框架的开发人员来说可能并不理想。
- 性能：虽然 SignalR 提供了直观的 API 和功能丰富的库，但与直接使用 WebSockets 相比，它可能会带来一些额外的开销，从而可能影响性能和延迟。
何时选择 WebSockets 而不是 SignalR
尽管 WebSockets 和 SignalR 都是在网络应用程序中实现实时通信的强大技术，但在某些情况下，其中一种可能比另一种更适合。在本节中，我们将讨论什么情况下 WebSockets 比 SignalR 更适合。
对连接的低级控制
与 SignalR 相比，WebSockets 提供了对连接更直接的控制。虽然 SignalR 提供了高级抽象来简化实时通信，但它可能无法提供某些用例所需的粒度。如果需要对连接进行较低级别的控制，包括管理连接状态、处理错误和自定义数据框架，WebSockets 可能会更好。
更低的延迟
WebSocket 连接比 SignalR 的延迟更低，因为它们在客户端和服务器之间提供了直接、持久和双向的通信通道。SignalR 虽然提供了自己的便利，但由于其使用的底层传输机制（如长时间轮询和服务器发送事件），可能会带来轻微的额外延迟。
平台兼容性
对于基于 .NET 的应用程序来说，SignalR 是一种优秀的解决方案，但对于无法使用或完全支持 SignalR 的平台（如非 Windows 环境），SignalR 可能并不适用。在这种情况下，WebSockets 可以提供一种更通用的解决方案，适用于各种平台和环境。
避免额外依赖
如果想尽量减少项目中的外部依赖性，选择 WebSockets 可能是更好的选择。WebSockets 是 HTML5 标准的组成部分，大多数现代浏览器和服务器端技术都支持 WebSockets。相比之下，使用 SignalR 需要在项目中集成一个外部库。
SignalR 与 WebSockets：性能评估
为了更好地理解 WebSockets 和 SignalR 在性能方面的差异，我们必须考虑以下几个因素。
延迟
与 SignalR 相比，WebSockets 的延迟通常较低。如前所述，这是由于 WebSocket 在客户端和服务器之间提供了直接、双向和持久的连接。SignalR 虽然提供了一系列传输机制，但在某些情况下会带来轻微的额外延迟。
信息吞吐量
与 SignalR 相比，WebSocket 连接通常每秒可处理更多信息，因为每条信息产生的开销更少。但这一优势在大多数实际应用场景中可能并不明显，因为在这些场景中，信息吞吐量的微小差异并不重要。
资源消耗
资源消耗是比较 WebSockets 和 SignalR 性能时需要考虑的另一个重要因素。WebSocket 连接由于采用轻量级协议，往往消耗较少的资源，而 SignalR 由于依赖多种传输和功能，可能消耗较多的资源。不过，资源消耗的实际差异可能因具体实现和使用情况而异。
可扩展性
WebSockets 和 SignalR 都支持扩展，以适应客户端数量的增长，但它们的处理方式不同。WebSockets 要求你实施负载平衡、水平扩展和其他技术，以确保适当的可扩展性。另一方面，SignalR 内置支持使用消息总线和背板等各种方法在多个服务器之间进行扩展。
将 WebSocket 和 SignalR 集成到AppMaster
AppMaster 是一个功能强大的无代码平台，用于创建 Web 和移动应用程序，可与 WebSocket 和 SignalR 技术无缝集成。这样，您就可以在应用程序中构建实时通信功能，而无需大量的编程专业知识。利用AppMaster 的可视化拖放界面，您可以创建数据模型、设计业务流程、实施REST API和 WSSendpoints ，根据您的要求，这些功能可以由 WebSocket 或 SignalR 支持。
此外，AppMaster 平台会生成应用程序的源代码并将其部署到云中，确保您的解决方案具有可扩展性并优化性能。通过将 WebSocket 和 SignalR 与AppMaster 集成，您可以快速开发功能强大且可扩展的实时网络和移动应用程序。这样，您的团队就可以专注于为用户提供价值，而不是把时间花在编写模板代码和管理服务器基础设施等无差别的任务上。
"软件与方法论、语言甚至操作系统无关。美国软件开发人员和工程经理克里斯托弗-鲍斯（Christopher Baus）说过这样一句话："软件与方法论、语言甚至操作系统无关，而与可运行的应用程序有关"。无论您决定在应用程序中使用 WebSockets 还是 SignalR，AppMaster 都能提供灵活的no-code 解决方案，使您能够设计、构建和大规模启动实时应用程序。要开始使用，请创建一个免费账户，探索AppMaster 提供的各种功能和集成。
