使用Openfire，Smack和Play的聊天網站的體系結構！框架

Question

我正在開發一個使用Openfire XMPP服務器的聊天網站，客戶端使用Smack API。使用Smack API的Web項目是使用Play！使其成爲RESTful的框架。我選擇了Play！因爲它的異步編程產品（Comet Sockets/WebSockets）。

基本上，我的體系結構，迄今，是象下面這樣：

的Openfire < - >網絡服務器< - >用戶/瀏覽器。

爲了支持Android設備，並最大限度地提高代碼重用性，我是否應該將XMPP客戶端代碼實現爲Web站點和Android客戶端通用的RESTful Web服務？

Openfire < - > Webservice < - >網站< - >瀏覽器/用戶。

Openfire < - > Webservice < - > Android App。

由於引入了中間Web服務，我害怕可伸縮性問題？作爲必須經歷多個組件的結果，我是否會在通信中引入延遲？

對上述任何建議都會有所幫助。謝謝。

Answer 1

可伸縮性的關鍵是解耦。因此，在本質上，您可以根據「如果其中一個組件失敗，其他組件是否能夠繼續正常工作？」來考慮問題。除了避免世界末日的場景外，您還可以獨立地對每個組件進行水平縮放。

考慮到這一點，現在讓我們繼續討論您的具體使用案例。爲了層次的緣故，我仍然看到了一些Java EE架構的惡夢。它不僅會引入不必要的延遲，還會使查明問題變得更加困難。如果您的服務失敗，是由Web服務器，Android應用程序還是Web服務造成的失敗？

如果您想要重複使用代碼，請重複使用代碼而不是複製組件。這是圖書館的用途。把你的通用代碼作爲一個庫提取出來，並在Web服務器和Android應用程序中使用它。

Answer 2

我認爲最好的做法是製作一個輕量級的網頁，在瀏覽器加載後直接從瀏覽器中瀏覽網頁服務（如任何應用程序）。

因此，應用程序和網頁之間的唯一區別在於每次用戶訪問網頁時，瀏覽器都會加載該網頁。