分佈式架構 前後端交互優化 上篇

用戶流量增加後存在以下問題

• 頁面和業務邏輯同工程，分解壓力變小
• 同服務器部署，服務器性能有瓶頸
• jsp頁面獲取數據後需要編譯，性能差
• 無法橫向擴展，不支持高可用
• 頁面渲染速度緩慢，用戶體驗差

由於傳統交互結構不能滿足用戶體驗，需要重新定義前後端交互方式
採用前後端分離方式 (h5+http json) 交互可提高用戶體驗

結構視圖如下：

如圖所示，前後端分離優勢如下：

• 前後端解耦，分開部署編譯打包
• h5靜態頁面存放cdn加速渲染
• h5可部署多份，負載均衡
• h5和後端可並行開發，mock數據 提高開發效率
• h5可打包、拆包、壓縮容量，提供輕量級
• 服務端專注於數據處理返回

很多互聯網公司爲了提高頁面渲染速度，從傳統前後端交互脫離 變爲 前後端分離交互方式，可見這是一種趨勢。

前後端分離交互步驟如下

• 目前主流前端框架（vue、react、angular）和後端約定數據傳輸格式 如（json、xml）
• 約定請求類型（POST、GET）、請求入參、請求出參
• 可提前書寫接口文檔或 引入Swagger自動生成接口文檔
• 針對特殊業務場景，如掃碼登錄，需要使用特殊請求方式，如 長鏈接、輪詢、重試

交互性能優化思路

• 簡單查詢使用Get請求、複雜查詢、增刪改使用Post請求
• 頁面作用於CDN上，加速請求
• 全局請求攔截，增加head頭部，簽名認證
• 大數據量獲取請求分批次，分多次請求
• 服務端熱點數據讀取緩存
• 服務端文件寫入、導出功能單獨轉發
• 服務端返回body字節壓縮
• 服務端異步處理請求返回

優化說明如下

• 由於GET、POST請求方式傳輸不同，GET容易受攻擊、POST請求會預檢請求，是否支持跨域通過後才提交數據
• 作用於CDN上，靜態資源不需要每次下載，讀本地緩存，如304 cache
• 前後端簽名認證（jwt）
• 服務器返回大數據量會影響 網絡帶寬和 解析讀取能力，分批次獲取可緩解壓力
• 服務端走緩存提高查詢效率（redis、ehcache）
• 導入、導出功能由數據量大 IO、內存開銷大，需單獨指向某臺服務器處理不影響主應用流程（F5/NGINX指定url分流）
• 服務端返回數據可經過壓縮返回
• 服務端非實時場地業務可用mq消息異步處理，提高吞吐量（rocketmq）

以下針對服務端數據返回壓縮優化進行實例講解

以上視圖是未優化場景下，獲取省市區數據，儘管頁面第一次獲取成功後緩存本地cache，但由於數據量大，請求時效長達 1.3s，大小 327KB，通過分析可發現此請求接口存在性能問題，正常接口均在50-300ms之內，大小在50KB以內，需要進行優化

優化思路

• 省市區數據量大，可否拆開成3份數據，分別獲取省、市、區數據，提高數據傳輸、加快渲染速度
• 可否針對省市區數據壓縮後進行返回客戶端

優化步驟

• 打開tomcat-server.xml，找到運行端口 如 <Connector port=“9021”

• 新增屬性 compressableMimeType=“application/json,application/x-javascript,application/javascript,
  text/html,text/plain,text/javascript,image/gif,image/x-icon,image/png,
  image/gif,text/css,image/jpeg,audio/mpeg,video/mp4,application/x-font-ttf,application/x-font-otf,
  image/svg+xml” (需要壓縮的response類型)
  新增屬性 compressionMinSize=“6144” 默認2048/2k （超過這個大小進行壓縮）
  新增屬性 compression=“on” 啓動壓縮功能，會影響部分服務器CPU資源
  
  從上面的截圖中優化後結果可以得出如下關鍵信息點：

• 省市區耗時縮短，從1.3s —> 231ms

• 省市區大小減少 從327kb —> 50.6kb

結果分析

• 分別請求省、市、區數據是能提高數據傳輸、加快渲染速度，但可能會頻繁請求接口導致服務端壓力，本地緩存後數據需更新時繁瑣
• 數據壓縮後，網絡傳輸加快，本地緩存數據

Web緩存優化、HTTP請求加速、多請求優化、頁面渲染優化等見下篇文章