实时Web应用程序的体系结构

Question

这将是一个相当理论化的问题。我目前正在研究我的学士论文，其中包括创建web-based real-time对象同步框架，类似于Firebase，但是本地（即不是基于云）。
我需要从实时中区分“常规”Web应用程序（有更好的术语吗？），尤其是在体系结构方面。到目前为止我的想法：

• 常规Web应用程序基于客户端 - 服务器模型，即“客户端和服务器以请求 - 响应消息传递模式交换消息：客户端发送请求，服务器返回响应。”
• 实时Web应用程序维护客户端和服务器之间的持久连接。两者都可以通过该连接同时并相互独立地发送和接收消息（全双工）。
• 我的顾问（来自应用软件工程主席）表示上述观点已经使Peer-to-Peer架构的申请合格，尽管他不太确定。我还不确信，因为a）同行不是同质的，b）服务器仍然是一个集中系统，c）我们仍然使用术语“服务器”和“客户端”。
• 服务器不直接向特定客户端发送消息，而是使用publish-subscribe消息传递模式，即客户端连接到消息通道，并在服务器在相应通道中发布消息时接收消息。因此，服务器实际上并不知道它的客户端，尽管他可以知道。
• 主要用例如下：客户端向服务器发送消息（例如，当创建新的待办事项时），服务器处理它（例如将新的待办事项项写入数据库）并最终发送消息所有其他订阅的客户。 mediator pattern出现在我的脑海中，虽然它是一种行为模式，而不是建筑模式。
• 但还有另一个用例：服务器自动发送一条消息（例如，它识别超出todo项目的到期日期并将其删除）给订阅的客户端。因此，沟通并不总是从客户端开始。

抱歉，它比预期的要长。简而言之，我看到了基于Web的实时应用程序架构的三种可能性：

1. Peer-to-Peer（与异类同行）
2. 具有pub-sub消息传递模式和中介的客户端服务器（如果后者对于体系结构很重要）
3. 你用完全不同的东西给我一个惊喜; - ）

根本不确定它是否具有重要性，但我在后端使用Rails（基于JMS的消息传递服务提供WebSocket - 支持）{{3}在前端。

Answer 1

“实时”操作或应用程序或系统具有及时性和可预测性限制。

原则上，这与系统架构无关 - 实际上，架构必须适合您需要的实时属性。

发布/订阅机制具有基于从可发布事件发生到事件在所有运营订户中显示的延迟的实时度量 - 简化，实时=真实快速（想想自动化金融交易）。但实时性与时效性可预测性同样重要。在P / S案例中，感兴趣的可预测性是延迟 - 在幅度和可变性方面（“抖动”是一种特殊情况）。在研究和从业者社区中有很多文献 - 在你的情况下，我建议阅读RTI网站上的一些优秀文件（尽管IMHO RTI并没有尽可能彻底地处理可预测性，但它们做得很好产品）。

非P / S系统，包括但不限于客户端/服务器系统，具有不同的实时风格。有许多争用共享资源的时间约束（比方说）任务（例如处理器，同步器，网络等）。必须通过以满足及时性和可预测性最优性标准的顺序调度或调度来解决竞争访问请求。每个人都熟悉一个非常简单的特殊情况，即请求有截止日期，最优标准是满足所有截止日期。请注意，“符合期限”及时性标准已与可预测性标准“始终满足所有”一起表达。

在绝大多数现实世界的实时案例（不仅限于计算机）中，标准要复杂得多 - 例如，实时系统通常要求均值（或者， ，最大）延迟要么最小化要么不超过某个值。依赖性添加了额外的复杂性，例如优先约束。这种实时方式对架构及其系统软件的某些属性有重大影响。为简洁起见，上述所有内容都已大大简化。

Answer 2

我可以通过以下方式之一阅读您的问题：

a）哪个Peer-to-Peer，Client-Server或其他术语最能描述该应用程序？

b）应用程序应该使用哪种架构作为其设计的基础？

在我看来，您的问题很好地描述了应用程序的体系结构，并且无论您是要将其称为点对点还是客户端 - 服务器还是其他内容都无关紧要。

也就是说，设计的实时方面并没有因为你提到的原因而成为Peer-to-Peer。