實施模塊化體系結構的RFC

Question

尋找關於Web應用程序模塊化的意見。大多數應用程序不管語言如何，都有一個後端數據庫並支持與他們各自的Web應用程序服務器（Apache，IIS，Lighttp等）的綁定，但是我處理的很多開發人員在使用Memcached或任何其他方面遇到問題在Web應用程序的即時進程空間之外。

Web應用程序的模塊化是一件好事，因爲我相信或者有些東西我錯過了，導致從高級開發人員到CTO的每個人都猶豫不決，無法將業務邏輯的特定部分移出網絡前端和專門的後端服務？

例如，幾年前，我在一個高流量網站的項目設計會議上被擊落，當時我建議我們將流程密集型ACL邏輯從前端框架中剝離出來，並將其變爲半可聚集服務應用程序在後端。對我來說，好處是代碼的清晰分離以及通過使用REST/JSON作爲PHP之間的橋樑在多個地方重用ACL邏輯的能力。

那些不同意我的想法的開發者認爲它「太複雜」，但我只是不知道如何？我的觀點是，正如可以爲表示層添加標籤湯一樣，可以並經常是代碼的邏輯湯，它們如此聯網，以至於如果出現問題，可能幾乎不可能執行「手術」修復。

因此縮短下來，有什麼反對的&或親的斷裂大型應用程序分解成獨立的，但合作進程（線程沒有或子請求）。 MySQL，Memcache，類似的服務過程是偉大的...但爲什麼不是其他？如何走這條路「太複雜」？

Answer 1

嗯，有時「太複雜」的意思是「我不想在我的舒適區以外思考」。

基本概念聽起來不錯 - 你在這裏談論的是非常合理的面向服務的體系結構。

現在，就利弊而言，第一件反對的事情是，你確實必須讓人們在他們的舒適區之外思考。更技術性的問題是，你需要保留實際上會話狀態。假設您從auth服務中獲取身份驗證令牌;該令牌如何與正確的用戶會話保持關聯。

另一個問題是，它可能更難調試，因爲它更動態地發生。

然而，在專業方面，如果您可以滿足會話狀態問題，則會得到高度可伸縮的體系結構;如果您需要更多服務，則可以放大服務器或只添加其他服務器。

Answer 2

我是從Web應用程序代碼中分離核心服務器/業務邏輯功能的粉絲。這是由於幾個不同的原因：

1. 您可以更好地控制業務邏輯。將無法將其與GUI代碼混合並造成混亂。您希望將所有業務邏輯分開，以便稍後可以使用API​​調用代碼功能，而不希望業務邏輯進入GUI代碼。
2. 從一開始你就必須設計一個好的API，你必須使用自己來從客戶端與服務器通信。客戶端可以是Web界面，也可以是遠程用戶。
3. 穩定性。 GUI網頁代碼很容易寫錯，消耗太多內存，從而導致整個應用程序崩潰。
4. 地磅秤可以將這些獨立的組件移動到不同的服務器。如果您使用的緩存系統已經允許集羣擴展，只需添加更多緩存服務器即可。
5. 我發現，應用程序更新是由最常見的GUI代碼，以便核心服務沒有被取下來的大部分時間。
6. 安全。可以肯定的是，安全代碼在服務器代碼實現的，所以如果有人使用您的API，他們將無法繞過了它的方式進入GUI代碼的安全代碼。

我們的系統有一個Java應用程序實現的核心「引擎」服務。 Web應用程序也是用Java編寫的，並且（當前）通過RMI進行通信。我們的網站/應用程序正在增長，我們還沒有開始使用像memcached或JCS這樣的緩存服務。