淺談前後分離在項目中的應用

一、創新的主要內容

在蘇州股權融資平臺(www.szgq.suzhou.gov.cn)項目中，引入了前後端分離策略。

項目一般採用 Structs、Spring MVC 等後端 MVC 架構，出發點在後端。後端 MVC 是個好的協作模式，從架構層面讓開發者懂得什麼代碼應該寫在什麼地方。前端通過 JSP，JS，HTML 以及 AJAX 等技術來展示數據，主要由服務器端負責渲染（不全是）。這種模式有很多弊端：

1. 後臺 Service 越來越多，調用關係變複雜，前端搭建本地環境不再是一件簡單的事。基本上都是前後端在一個工程目錄裏面，開發人員負責前後臺代碼編寫。這對研發效率的影響其實大。
2. 如果是基於 JSP 來實現前臺頁面，JSP 等代碼的可維護性會越來越差。JSP  非常強大， 可以內嵌 Java  代碼。這種強大使得前後端的職責不清晰，JSP  變成了一個灰色地帶。經常爲了趕項目，爲了各種緊急需求，會在 JSP 裏揉雜大量業務代碼。積攢到一定階段時， 往往會帶來大量維護成本。
3. 前後端職責糾纏不清。由於前後端都是一個人編寫代碼，這就導致前端混雜很多業務代碼，前端缺乏對用戶交互的關注度。
4. 前後端在一起編譯，部署。不利於系統的拆分、前後端的負載均衡、前端調優、後端調優等。

爲了避免上面的弊端，在平臺開發過程中，引入了基於前端 MVVM 架構的 Vue.js 框

架，採用 REST 架構風格，來實現前後端分離。

Vue.js 是一個漸進式的 JavaScript 框架，用來構建用戶交互界面，採用自底向上的增量開發的設計。官網：https://cn.vuejs.org/

REST 架構風格： 2000 年，博士學位論文 Architectural Styles and the Design of Network-based  Software  Architectures（中文《架構風格與基於網絡的軟件架構設計》），Fielding 博士系統地、嚴謹地闡述了這套理論框架，並且使用這套理論框架推導出了一種新的架構風格， 並且爲這種架構風格取了一個名字“REST”——Representational State

Transfer（表述性狀態轉移）的縮寫。REST 架構風格最重要的架構約束：

1. 客戶-服務器（Client-Server）：通信只能由客戶端單方面發起，表現爲請求-響應的形式。
2. 無狀態（Stateless）：通信的會話狀態（Session State）應該全部由客戶端負責維護。
3. 緩存（Cache）：響應內容可以在通信鏈的某處被緩存，以改善網絡效率。
4. 統一接口（Uniform  Interface）：通信鏈的組件之間通過統一的接口相互通信，以提高交互的可見性。
5. 分層系統（Layered  System）：通過限制組件的行爲（即，每個組件只能“看到”與其交互的緊鄰層），將架構分解爲若干等級的層。
6. 按需代碼（Code-On-Demand，可選）：支持通過下載並執行一些代碼（例如 Java Applet、

Flash 或 JavaScript），對客戶端的功能進行擴展。

         平臺開發過程中的 RESTful API 設計規則：

1. 將 API 的版本號放入 URL（/v1/system/users/ids）
2. 每個網址代表一種資源（resource），所以網址中不能有動詞，只能有名詞，而且所用的名詞往往與數據庫中的表格名或實體對應。（/v1/activity/activity/id）
3. 對於資源的具體操作類型，由 HTTP 動詞表示。

• GET（SELECT）：從服務器取出資源（一項或多項）。
• POST（CREATE）：在服務器新建一個資源。
• PUT（UPDATE）：在服務器更新資源（客戶端提供改變後的完整資源）。
• PATCH（UPDATE）：在服務器更新資源（客戶端提供改變的屬性）。
• DELETE（DELETE）：從服務器刪除資源。

      4.服務器向用戶返回的狀態碼和提示信息，常見的有以下一些（方括號中是該狀態碼對應的 HTTP 動詞）。

• 200 OK - [GET]：服務器成功返回用戶請求的數據，該操作是冪等的（Idempotent）。
• 201 CREATED - [POST/PUT/PATCH]：用戶新建或修改數據成功。
• 202 Accepted - [*]：表示一個請求已經進入後臺排隊（異步任務）
• 204 NO CONTENT - [DELETE]：用戶刪除數據成功。
• 400 INVALID REQUEST -  [POST/PUT/PATCH]：用戶發出的請求有錯誤，服務器沒有進行新建或修改數據的操作，該操作是冪等的。
• 401 Unauthorized - [*]：表示用戶沒有權限（令牌、用戶名、密碼錯誤）
• 403 Forbidden - [*]  表示用戶得到授權（與 401 錯誤相對），但是訪問是被禁止的。
• 404 NOT FOUND - [*]：用戶發出的請求針對的是不存在的記錄，服務器沒有進行操作， 該操作是冪等的。
• 406 Not Acceptable - [GET]：用戶請求的格式不可得（比如用戶請求 JSON 格式，但是隻有 XML 格式）。
• 410 Gone -[GET]：用戶請求的資源被永久刪除，且不會再得到的。
• 422 Unprocesable entity - [POST/PUT/PATCH] 當創建一個對象時，發生一個驗證錯誤。
• 500 INTERNAL SERVER ERROR - [*]：服務器發生錯誤，用戶將無法判斷髮出的請求是否成功。

     5.針對不同操作，服務器向用戶返回的結果應該符合以下規範。

• GET /collection：返回資源對象的列表（數組）
• GET /collection/resource：返回單個資源對象
• POST /collection：返回新生成的資源對象
• PUT /collection/resource：返回完整的資源對象
• PATCH /collection/resource：返回完整的資源對象
• DELETE /collection/resource：返回一個空文檔 

     6.前後臺交互的數據格式，全部使用 JSON。

     7.URI 統一使用小寫字母

     8.URI 儘量使用“-”代替下劃線“_”

後臺使用 Spring Boot 作爲開發框架。爲了方便後臺脫離前臺獨立調試後臺 API，在後臺引入了可視化 API 調試工具 swagger。具體如下：

1. 在項目 POM 文件中加入依賴    

       

 

     2.在 Spring Boot 中配置 swagger，並開啓 swagger 支持。

 

       3.在代碼中使用 swagger 註解。

 

     4.訪問 swagger 管理界面（http://localhost:8080/swagger-ui.html#/）。

         

         

測試過程中，前臺部署在 172.17.2.97 上，後臺部署在 172.17.2.98 上。前臺通過 nginx 反向代理找到後臺 API 服務器。

二、創新的目的

        在項目中引入前後分離，實現後臺的開發人員專注寫後臺接口，前臺開發人員專注頁面上的事。前後開發同時進行，前後通過 API 實現連接。至少在開發模式上是一種新的模式，效率確實得到了提高。

三、成效如何

1. 開發效率得到很大提高。

2. 前後分離的具體實踐。

3. 項目成員熟悉掌握了前臺框架Vue.js。