一場由React引起的先後端分離架構的思考

內容來源：2017年7月22日，浪潮國際金融產品技術架構師丁周芳在「【濟南】OSC源創會第65期」進行《一場由React引起的先後端分離架構的思考與實踐》演講分享。IT 大咖說（微信id：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：2715 | 7分鐘閱讀

嘉賓演講視頻及PPT回顧： suo.im/2A3F57

摘要

以React技術棧爲主分享咱們在大規模企業應用建設過程當中遇到的問題，對先後端分離架構的思考，先後端分離的技術方案，先後端分離過程當中的實踐經驗，先後端分離帶來的效果與價值，以及目前存在的問題與將來可能的嘗試。

應用的現狀

咱們的應用擁有接近100w的用戶、3K+的QPS、5億+的單表數據、萬億級別的資金流，可是一樣也面臨着諸多問題。

首先是顏值低，換膚受限、沒法集成更好的前端框架和組件。而後是先後端的高度耦合使得沒法快速的響應業務變化，維護成本也隨着應用規模不斷攀升，性能方面也受到限制，溝通成本提升。其次是沒法跨終端，渲染和跳轉強依賴於後端，業務邏輯分散。最後就是強狀態性，應用中不少的數據是與用戶的會話綁死的，由此形成沒有水平伸縮的能力，智能化、自動化、服務化一樣受限。

咱們通過思考認爲理想的狀態應該是這樣的，前端方面具有高顏值、個性化、多渠道、多終端的特質；而在後端上須要能作到微服務化、水平伸縮、高可用、自動化甚至智能化。

解決方案-先後端分離

定義

在以前的應用中後端是Java，前端是Browser（瀏覽器）。可是如今Node出現了，它被包含在大前端中用來替換原來的MVC部分，這樣後端就能夠脫離出來處理純服務化的部分，前端也能夠專一於純前臺的領域。

各自的職責

前端方面Browser負責數據的展示和收集、事件的響應和處理、DOM的操做、請求的發送和響應的處理。Node用來處理以前經過後端來實現的頁面渲染、跳轉和數據的傳遞等功能。然後端方面則專一於業務邏輯的封裝、服務接口的提供以及序列化。

整體的方案

從整體上來看前端和後端基於服務化的方式進行交互，經過Json進行數據傳遞。前端作到組件化、後端實現模塊化。

前端的選擇

在嘗試了不少方案後，咱們選擇了React+Redux，由於在React上有必定技術積累，同時國內也有不少的成功案例。可是因爲Redux太靈活了，在接觸了三週後咱們選擇了放棄，轉而使用螞蟻金服開源的基於React的一款展現框架AntD和基於Redux封裝的Dva框架。

前端的技術架構

當有一個請求過來後，會經過Component或Route來展現界面。同時也會接收用戶的點擊事件，每個點擊事件都會由dispath來觸發一個Action，這以後會產生兩種結果。

一種是直接經過reducers函數改變狀態state，使與前臺關聯的model發生變化，由此來改變前臺頁面。另外一種是調用後臺的服務，經過fetch進行後端服務的訪問，後臺服務返回的數據會由effects函數處理，處理後會交給reducers函數去改變狀態state，進而觸發前端的組件刷新和渲染。

最後還有一個subscriptions函數是進行前端攔截的，當攔截到一個URL請求以後仍然是觸發一個Action，而後又會致使上面的兩種變動。

後臺的技術架構

後臺的邏輯就相對複雜了，咱們採用了分層的技術架構。最底層是基礎設施，支持公有云、私有云固然還有本地服務器。而後技術平臺層就是通常常見的架構，囊括一些系統權限、工做流、開發框架之類的。基於之上的是通用的服務層，裏面有一些報表服務、打印服務，單據服務等。再向上就是業務模塊的部分，包含帳戶管理、任務管理、自助中心等。最後頂層的就是接口服務層了，它是基於Web Service和Restful Service的。

除了上面的主體框架外，咱們還有服務網關模塊，主要是用來作流量控制、安全監控、負載均衡、服務降級與熔斷等。另外就是安全運維模塊，用來處理身份認證、訪問控制、加密解密，審計日誌，運維工具等等。

實踐經驗

先後臺交互

目前絕大部分業務表單數據與後臺的交互都是使用Fetch方式。另外因爲一些遺留系統的問題仍然保留着AJAX方式，並對他進行了一些改進。而文件類的操做好比上傳、下載，這些目前使用的是Form提交的方式。

跨域

咱們原來是經過Jsonp來解決的，可是Jsonp的問題是隻能支持get請求，參數會被暴露出去。出於安全性的考慮咱們選擇了目前主流的CORS方式，只在服務端處理跨域不涉及到客戶端。

應有無狀態

應用的強狀態性是因爲過分依賴會話形成的。會話的原理其實就是在Session中存儲了一些數據，此時Session被當作緩存來使用；還有一個重要的職責是維護與客戶端的聯繫，讓後端能夠判斷是哪一個客戶端發送的請求。而如今咱們採用Token來識別客戶端，緩存的職責使用分佈式cache來代替。

頁面的跳轉和參數傳遞

原先被放在後端經過forward或redirect的跳轉、參數傳遞，如今被前端的Router代替，數據傳遞經過PayLoad進行。而若是須要依賴後端的一個狀態才能進行跳轉，那麼只須要從後臺獲取一個消息，前端會根據這個消息來判斷跳轉的走向便可。

錯誤處理

咱們的經驗是後端統一異常錯誤捕獲，而後進行分類，經過異常錯誤信息字典來統一貫前臺反饋錯誤信息。前臺從後臺獲得錯誤的信息後，以此進行前端界面的提示和跳轉到錯誤頁面。

安全

經過Token來進行身份的驗證，另外爲防止Token一直有效，當前臺主動登出時會註銷Token；同時後臺也會根據配置的回話過時時間來自動註銷不活動的回話。消息的加解密，系統的訪問控制，包括系統功能權限與數據權限也會有專門的服務。

質量的保證

原來的統一測試被分開了，先後端先分別獨立mock數據進行單元測試，而後是聯調測試，聯調測試完後再根據測試用例進行冒煙測試。冒煙測試完成後開發人員的測試算是完了，後續就交由專業的測試人員來進行集成測試，UAT測試。

先後端分離的價值

敏捷、快速響應、提高效率，專業化的分工和協做、提高專業度和研發效率，結構清晰，下降維護成本，先後端各自獨立擴展、自由水平伸縮。

將來可期

如今咱們須要考慮下以後還有那些須要增強的地方，好比說服務網關、安全與運維特性的加強，公共組件的進一步提煉與封裝，性能與體驗的提高，框架開源等等。

今天的分享就到這裏，謝謝你們！