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

Question

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

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

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

1. 点对点（具有异构对等体）
2. 具有pub-sub消息传递模式和中介的客户端服务器（如果后者对于体系结构很重要）
3. 你用一些完全不同的东西让我感到惊讶;-)

不确定它是否具有重要性，但我在后端使用Rails （带有基于JMS的消息传递服务，提供WebSocket -support），在前端使用AngularJS 。

Answer 1

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

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

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

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

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

Answer 2

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

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

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

在我看来，你的问题很好地描述了应用程序的体系结构，无论你是想将它称为Peer-to-Peer还是Client-Server或其他东西，这都是无关紧要的。

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