實時Web應用程序的體系結構

Question

這將是一個相當理論化的問題。我目前正在研究我的學士論文，其中包括創建web-based real-time對象同步框架，很像Firebase，但是本地（即不是基於雲）。
我需要從實時的角度區分「常規」Web應用程序（有更好的術語？），尤其是在架構方面。我的想法至今：

• 一個普通的web應用程序是基於客戶 - 服務器模型，即「客戶端和服務器交換消息的請求 - 響應消息模式：客戶端發送一個請求，服務器返回響應。」
• 實時Web應用程序維護客戶端和服務器之間的持久連接。兩者都可以通過該連接同時發送和接收消息，並且彼此獨立（全雙工）。
• 我的導師（從應用軟件工程的主席）指出上述觀點已經有資格爲Peer-to-Peer架構的應用程序，雖然他不太清楚。我還沒有確信，因爲a）同行不同質，b）服務器仍然是一個集中式系統，c）我們仍然使用術語「服務器」和「客戶端」。
• 服務器不直接將消息發送到特定的客戶端，但使用publish-subscribe消息傳遞模式，即，客戶機連接到一個消息信道，並且當服務器在相應的信道發佈它接收到一個消息。因此服務器實際上並不知道它的客戶端，儘管他知道可能是。
• 主要使用情形如下：客戶端將消息發送到服務器（例如，創建新的待辦事項時），服務器處理它（例如，新的待辦事項寫入數據庫），最後分派消息到所有其他訂閱的客戶端。我想起了mediator pattern，雖然它是一種行爲模式，而不是建築模式。
• 但還有另一種使用情況：服務器發送它自己的協議（例如，它可識別的待辦事項到期日超過其刪除），以訂閱的客戶機的消息。所以溝通並不總是從客戶端開始。

對不起，它得到了超過預期。把它概括地說，我看到三種可能的基於網絡的實時應用程序的架構：

1. 對等網絡（異構同行）
2. 客戶端 - 服務器與發佈 - 訂閱消息傳遞模式和調解員（如果架構後事項）
3. 你有完全不同的東西;-)

不知道它的重要性在所有讓我感到吃驚，但我用Rails（用JMS基消息服務，提供WebSocket - 支持）在後端和AngularJS在前端。

Answer 1

「實時」操作或應用程序或系統具有及時性和可預測性約束。

原則上，這與系統架構無關 - 實際上，架構必須適合您所需的實時屬性。

發佈/訂閱機制具有基於從可發佈事件發生時到所有操作訂戶的事件清楚爲止的延遲的實時指標 - 簡化的，實時的=真實的快速（認爲自動化金融交易） 。但實時性與時效性的可預測性相當。在P/S情況下，感興趣的可預測性是等待時間 - 無論是數量級還是變化性（「抖動」是一種特殊情況）。在研究和實踐者社區中有很多文獻 - 對你而言，我建議閱讀RTI網站上的一些優秀文檔（儘管恕我直言，RTI並沒有儘可能全面地處理可預測性，但它們使產品）。

非P/S系統，包括但不限於客戶端/服務器系統，具有不同的實時風格。有多個時間限制（比如說）的任務爭奪共享資源（如處理器，同步器，網絡等）。爭用的訪問請求必須通過按照滿足及時性和可預測性最優性標準的順序進行調度或調度來解決。每個人都很熟悉這樣一個非常簡單的例子：請求具有最後期限，最優標準是滿足所有期限。請注意，「符合期限」的時效標準已經與可預測性標準「永遠滿足所有人」一起表達。

在絕大多數真實世界的實時情況下（不限於計算機），標準要複雜得多 - 例如，實時系統通常要求均值（或者，或者最大）遲緩或者被最小化或者不會超過某個值。額外的複雜性由依賴關係添加，例如優先約束。這種實時風格對架構及其系統軟件的某些特性有重大影響。爲簡潔起見，以上所有內容都已大大簡化。

Answer 2

我可以讀取的下列方式之一你的問題：

a）在對等網絡，客戶端 - 服務器，或者一些其他術語描述應用程序最好？

b）應用程序使用哪種架構作爲其設計的基礎？

在我看來，您的問題很好地描述了應用程序的體系結構，並且您是否稱其爲對等或客戶機 - 服務器或其他什麼都是無關緊要的。

也就是說，設計的實時性不會因爲你提到的原因而使它成爲點對點的。