是一个相当理论化的问题。我目前正在写我的学士学位论文，其中包括创建一个基于 Web 的实时对象同步框架，与 Firebase 非常相似，但在本地(即不是基于云的(。
我需要区分"常规"Web应用程序(有更好的术语吗？(和实时，特别是在架构方面。到目前为止我的想法：
- 常规 Web 应用程序基于客户端-服务器模型，即"客户端和服务器以请求-响应消息传递模式交换消息：客户端发送请求，服务器返回响应。
- 实时 Web 应用程序在客户端和服务器之间保持持久连接。两者都可以通过该连接(全双工(同时独立地发送和接收消息。
- 我的顾问(来自应用软件工程主席(指出，上述观点已经使应用程序符合点对点架构的条件，尽管他不太确定。我还不相信，因为 a( 对等体不是同构的，b( 服务器仍然是一个集中式系统，c( 我们仍然使用术语"服务器"和"客户端"。 服务器
- 不直接向特定客户端发送消息，而是使用发布-订阅消息传递模式，即客户端连接到消息通道，并在服务器在相应通道中发布消息时接收消息。因此，服务器实际上并不知道它的客户端，尽管他可以知道。
- 主要用例如下：客户端向服务器发送消息(例如，当创建新的待办事项时(，服务器处理它(例如，将新的待办事项写入数据库(，最后将消息分派给所有其他订阅的客户端。中介模式浮现在我的脑海中，尽管它是一种行为模式，而不是架构模式。
- 但还有另一种用例：服务器自行向订阅的客户端发送消息(例如，它识别超出的待办事项的到期日期并将其删除(。因此，通信并不总是必须从客户端开始。
对不起，它比预期的要长。简而言之，我认为基于 Web 的实时应用程序架构有三种可能性：
- 点对
- 点(具有异构对等体(
- 具有发布-订阅消息传递模式和中介器的客户端-服务器(如果后者对体系结构很重要(
- 你用完全不同的东西让我感到惊讶;-(
不确定它是否重要，但我在后端使用 Rails(带有提供 WebSocket 支持的基于 JMS 的消息传递服务(，在前端使用 AngularJS。
实时"操作或应用程序或系统具有及时性和可预测性约束。
原则上，这与系统架构无关 - 在实践中，架构必须适合您需要的实时属性。
发布/订阅机制有一个实时指标，基于从可发布事件发生到事件在所有操作订阅者中显示的延迟 - 简化，实时=真正快速(想想自动金融交易(。但实时性与及时性可预测性同样重要。在 P/S 案例中，感兴趣的可预测性是延迟 - 无论是在幅度还是可变性("抖动"是一个特例(。在研究和从业者社区中都有很多文献 - 在你的情况下，我建议阅读RTI网站上的一些优秀文档(尽管恕我直言，RTI没有尽可能彻底地处理可预测性，但它们是很好的产品(。
非P/S系统，包括但不限于客户端/服务器系统，具有不同的实时风格。有多个时间受限(例如(任务争用共享资源(例如处理器、同步器、网络等(。竞争访问请求必须通过按满足及时性和可预测性最优标准的顺序调度或调度来解决。每个人都熟悉一个非常简单的特殊情况，即请求有截止日期，而最优标准是满足所有截止日期。请注意，"满足最后期限"及时性标准与可预测性标准"始终满足所有要求"一起表示。
在绝大多数现实世界的实时案例(不限于计算机(中，标准要复杂得多 - 例如，实时系统通常要求平均(或最大(延迟最小化或不超过某个值。依赖关系(如优先约束(增加了额外的复杂性。这种实时风格对架构及其系统软件的某些属性具有重大影响。为简洁起见，上述所有内容都已大大简化。
我可以通过以下方式之一阅读您的问题：
a( 点对点、客户端-服务器或其他术语中的哪一个最能描述应用程序？
b( 应用程序应使用哪种架构作为其设计的基础？
在我看来，您的问题很好地描述了应用程序的体系结构，无论您是要将其称为点对点还是客户端服务器或其他名称，这都无关紧要。
也就是说，由于您提到的原因，设计的实时方面并没有使其成为点对点的。