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