4

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

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

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

  1. 点对点（具有异构对等点）
  2. 具有发布-订阅消息模式和调解器的客户端-服务器（如果后者对架构很重要）
  3. 你用完全不同的东西给我惊喜;-)

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

4

2 回答 2

3

“实时”动作或应用程序或系统具有及时性和可预测性约束。

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

发布/订阅机制有一个实时指标，该指标基于从可发布事件发生到该事件在所有操作订阅者中显现的延迟——简化、实时 = 真正快速（想想自动化金融交易）。但实时与及时性可预测性同样重要。在 P/S 情况下，感兴趣的可预测性是延迟——无论是幅度还是可变性（“抖动”是一种特殊情况）。研究和从业者社区都有很多文献——在你的情况下，我建议阅读 RTI 网站上的一些优秀文档（尽管恕我直言，RTI 没有尽可能彻底地处理可预测性，但它们做得很好产品）。

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

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

于 2013-09-30T20:41:26.477 回答
1

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

a) Peer-to-Peer、Client-Server 或其他术语中哪个最能描述应用程序？

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

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

也就是说，由于您提到的原因，设计的实时方面并没有使其成为点对点。

于 2013-09-29T17:56:41.720 回答