Web開發問題域

HTML clipboard

 1. HTTP本身無串連無狀態, 如何在不同請求間識別使用者以支援需要多個請求才能完成的業務?

其它所有問題都是這個問題的某種解決方案引入的. 這個論斷有一個推論,
就是不需要識別使用者的Web應用是最簡單的Web應用.

一種方案是所有的業務都設計成一次請求就可以完成, 比如讓使用者每次都輸入使用者名稱密碼, 填寫所有的表單,
然後一次性提交. 從使用者體驗的角度顯然不可行...

 

狀態儲存

需要儲存狀態的原因是要在不需連線的協議上類比有串連的使用者體驗

狀態儲存的地點無非是用戶端或者服務端, 以及URL本身

用戶端一般是cookie, 類似Hash的索引值對. 存放小塊資料, 通常是真正狀態的某種標識,
可加密, 可設定有效期間及適用的域, 由瀏覽器每次請求時發送給服務端. cookie的問題在於, 有些使用者在瀏覽器中禁止了對cookie的支援,
然而實際上有什麼類型的網站需要考慮/考慮了這類使用者? 以及安全性(可被拷貝偷走放在自己機器上以假冒其他使用者用).
可對cookie加密或摘要來保證資料的機密性和完整性

服務端儲存有記憶體和外部儲存. 一般把跨越多次請求維護特定用戶端的狀態資料的場所叫做Session.
Session並不是HTTP本身的概念, 而是各開發包實現者提供的概念和實現, 通過唯一的session
id(通常通過cookie儲存)在不同的請求間關聯資料.

Session放在記憶體中的問題是無法適應Server Load Balancer和可靠性的需求, 優點是效能; 外部儲存恰好相反;
各種不同的開發包對Session的實現一般都支援儲存可配置, 對應用"透明"(實際上無法完全透明, 比如如果需要持久化Session到外部儲存,
則需要記憶體對象支援某種形式的可序列化, 而如果只是放在記憶體裡則無此需求)

URL本身可攜帶資料, 問題是應用程式開發人員需要仔細維護URL的產生和解析. 開發包提供了支援,
可定義URL到對應處理常式的映射, 解碼URL中攜帶的資料並作為參數傳遞給處理常式.

• URL和cookie都適合存放小片資料. 那麼什麼類型的資料適合放進URL,
  什麼資料適合放進cookie呢? 從URL的語義上來說, 編碼進URL的資料應該是所請求資源的某種屬性, 而cookie一般存放使用者的某種標識資料.
  也就是URL應該是業務相關資料, cookie應該是應用相關資料. 當瀏覽器禁用cookie時, 開發包支援把session
  id之類的資料編碼進URL.

• Session存放需要頻繁用到的資料, 使用者相關而業務無關的.
  關鍵的業務資料要及時持久化到外部儲存. 業務相關資料一般按需存取...

 

狀態清除

狀態清除是由狀態儲存引入的問題, 確切的說是對儲存狀態的資源的回收和重利用.
另外是減少安全性方面的隱患.

用戶端cookie有到期時間, 也可在使用者登出的時候主動設定其到期來刪除

服務端Session可在使用者登出的時候主動刪除, 開發包也會檢測同樣的Session ID訪問間隔,
如果超過某個設定的時間沒有包含某個Session ID的cookie被送到服務端, 則自動清除對應Session資料. 這時候表現為如果使用者長時間不操作,
下次操作時將被開發包重新導向到登入頁面.

 

業務資料的傳遞

資料的輸入和處理髮生在不同的主機上, 是Web應用的天然特質. HTML的Form和隱藏欄位,
HTTP Post專為此設計. 另外URL本身也可以承載一些業務資料(HTTP Get)

跨頁面的業務資料傳遞, 一般通過持久化到外部儲存的方式來共用. 應用資料則可以通過Session,
一些細分的概念如臨時資料,
只用一次的資料
等,
開發包都有支援, 一般也是背後通過Session實現

 

2. 用戶端狀態更新

HTTP的無串連帶來的第二個問題是服務端無法主動把資訊推給用戶端,
另一個原因是用戶端通常沒有public的IP. 用戶端只能使用按需請求或輪詢模型. 此題無解. 如果是企業內部系統整合, 考慮使用訊息佇列等方式.

 

3. 並發

並發是要處理的第三個本質問題. 對並發(背後是狀態一致性與完整性)的解決會帶來事務,
事務會帶來效能問題, 對效能的解決會帶來Cache等方案, Cache則會引入狀態一致性與完整性問題...回到起點.

最終是狀態的一致性與完整性和效能之間的某種折衷.

Cache的一種實現是將動態網頁面轉化為一段時間內的靜態頁面, 交給Web伺服器直接處理,
減輕應用伺服器的負擔.

應用伺服器內的Cache一般是key value pair. key一般是url, 查詢語句,
對象ID等.

Cache的實現要考慮的問題主要是Cache的生命週期, 是請求內, 會話內, 還是應用程式範圍.
以及同步問題, 何時重新整理, 如何重新整理.

• HTTP Request範圍內的Cache, 和通常的事務策略配合良好.
  事務通常不會超出一次請求, 隔離等級是可讀到其它事務提交後的內容, 不會讀到其它事務提交前的改動(?). 這類Cache邊界清晰,
  幾乎不會有失效重新整理的需求, 基本不需要考慮多線程的問題(每個請求一般獨佔一個處理線程). 缺點是對效能提高有限,
  如果一次請求範圍內對同一資源的訪問很少超過一次的話.

• Session範圍內的Cache...什麼類型的資料適合放到Session層級的Cache呢?
  Session通常包含多個事務, 如果放業務資料到Cache, 毫無疑問要經常重新整理, 失去Cache的意義. 重新整理時有多線程的問題,
  尤其對AJAX應用. 如果是不經常變化的應用資料, 通常放到應用程式層級的Cache. Session內的資料基本可看作已經是某種緩衝...

• Application範圍內的資料, 一般存放不經常變化的配置資料, 資料字典等.
  重新整理可以是定時輪詢, 及各種基於事件的手段: HTTP Get/Post, 訊息佇列等

 

4. 驗證

這裡說的驗證是Validation, 不是Authentication.
Authentication/Authorization並非Web特定問題, 其它類型的應用面臨同樣的問題, 有相似的解決方案

Validation則是Web相關, 蓋因輸入與處理髮生在不同的主機上,
驗證邏輯發生的位置和時機都是需要考慮的因素

• 一條底線是在資料被正式接受之前, 比如存到資料庫之前, 用來進行業務計算之前, 進行驗證,
  以確保資料的合法性. 這在大多數情況下都是必要的. 然而從使用者體驗的角度講, 時間有點晚, 並且驗證產生的錯誤資訊可能更偏向於實現,
  而不是使用者能理解的業務含義, 並不必要的向使用者暴露實現細節. 所以需要其它的驗證手段作為補充

• 一種方式是在用戶端用JavaScript進行驗證, 不必讓資料到伺服器走一個來回,
  帶來的問題是部分驗證邏輯在用戶端和服務端用不同的語言寫兩遍.

• 一個改進是利用AJAX即時驗證, 既改善了使用者體驗,
  又避免了用JavaScript重寫驗證邏輯

即時的驗證一般關注於基礎合法性的驗證, 比如格式, 必要欄位等.
資料的業務合法性則一般在提交後由服務端進行全面驗證

 

5. 開發效率

開發包對Web問題的各種解決方案進行了封裝, 分離關注點, 使開發人員更關注商務邏輯,
開發包處理了所有與Web相關的應用邏輯

為使這一切對開發人員透明, 結合Web應用的Request/Response模型,
開發包一般採用管道和過濾器模式來動態,可配置的將各種服務插入到資料的處理流程中.

比如Session的管理, 包括通過cookie識別特定用戶端和清除到期資料等邏輯,
都透明的發生在請求經過的路徑上. Session資料本身的儲存位置, 也都是可配置的. 其它的例子包括頁面緩衝和使用者驗證等.

• 封裝HTTP協議位元組流到特定開發平台的對象, 通常是能以key-value
  pair的形式訪問的介面. 更有細粒度的對象如Cookie等概念的封裝

• 封裝URL到對應處理常式的映射, 包括組裝URL, 將URL參數解析成具有業務含義的資料.
  開發人員可定製映射規則

• 封裝Form/Request資料到業務對象的轉換, 通常稱之為Binder

• 通過MVC分離視圖邏輯和商務邏輯, 並且通過模板視圖支援人員UI開發人員和業務開發人員的分工協作

• 提供了過濾器介面, 可以自訂驗證, 授權, 錯誤處理等邏輯