動靜分離，動態資源 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，從而大大的降低帶寬的消耗，對於用戶的感覺也是提高