動靜分離和先後端分離相關

動靜分離，動態資源 jps servlet spring mvc 與靜態資源 js html img css  不會部署到同一個服務器

先後端分離   網站架構模式 微服務開發基於SOA，面向於服務器開發，後臺和前段採用接口方式。將一個項目拆分紅一個控制web （前端） 和接口（後端） 。最終使用rpc遠程調用技術。

  視圖層和業務邏輯層拆分，採用rpc遠程調用技術

 

靜態資源url後面加時間戳。

目的是爲了控制項目上線時候，靜態資源與老的瀏覽器緩存靜態資源避免衝突。

規範  項目上線時間

 

第一次請求 訪問成功後 緩存在瀏覽器  第一次加載時不走緩存的 

第一次加載圖片後  返回一個 最後修改時間

第一次下載資源時候 客戶端保存修改資源時間

第二次下載資源時候，服務器判斷當前資源文件與客戶端上次修改的時間是否須要返回200仍是304

若是服務器最後修改時間 大於 客戶端 足厚一次修改的時間 從新加載

服務器端 最後一次修改的時間 小於客戶端最後修改的時間 返回304 走本地緩存

 

默認瀏覽器緩存是 七天  

再次訪問時候  走緩存

304狀態碼  走本地緩存

 

 

 生產環境中 js css 最後一次的修改時間與客戶端緩存的最後一次修改的時間可能會產生衝突

 服務器端在 2018.11.6上線

  用戶           2018.12.4 訪問

 新的js文件上線 14.6    瀏覽器最後仍是保留上次上線功能

解決方案： 直接在js加時間戳

 給靜態的資源加時間戳 動態的不用加了

 

靜態資源緩存

實際項目中在發佈版本的時候，可能因爲瀏覽器緩存致使與服務器端代碼發生衝突。

這時候能夠在靜態資源請求後面加上時間戳，對應每次發佈版本的時間。

火狐瀏覽器 F5 刷新

火狐瀏覽器 CTRL 強制刷新

 

HTTP 304狀態碼

客戶端在請求一個文件的時候，發現本身緩存的文件有 Last Modified ，那麼在請求中會包含 If Modified Since ，這個時間就是緩存文件的 Last Modified 。所以，若是請求中包含 If Modified Since，就說明已經有緩存在客戶端。服務端只要判斷這個時間和當前請求的文件的修改時間就能夠肯定是返回 304 仍是 200 。 對於靜態文件，例如：CSS、圖片，服務器會自動完成 Last Modified 和 If Modified Since 的比較，完成緩存或者更新。可是對於動態頁面，就是動態產生的頁面，每每沒有包含 Last Modified 信息，這樣瀏覽器、網關等都不會作緩存，也就是在每次請求的時候都完成一個 200 的請求。 所以，對於動態頁面作緩存加速，首先要在 Response 的 HTTP Header 中增長 Last Modified 定義，其次根據 Request 中的 If Modified Since 和被請求內容的更新時間來返回 200 或者 304 。雖然在返回 304 的時候已經作了一次數據庫查詢，可是能夠避免接下來更多的數據庫查詢，而且沒有返回頁面內容而只是一個 HTTP Header，從而大大的下降帶寬的消耗，對於用戶的感受也是提升