大型項目前端架構詳談（1）純前端發佈

目錄列表：

• 0、前言
• 一、項目簡述
• 二、場景描述
• 三、數據結構簡述
• 四、項目核心點
• 五、後臺服務
• 六、項目架構圖
• 七、數據庫設計
• 八、後期功能擴展
• 九、示例效果
• 十、總結

0、前言

在上一篇文章《大型項目前端架構淺談》裏，我簡單的闡述了一下在大型項目裏，前端架構如何設計。

有不少同窗反映，說談的比較淺。但因爲篇幅所限，儘管已經寫了8000字，但想每一個都深刻下去，實在是不太可能。

所以便有了這個續篇。

我考慮了一下，續篇的第一文，將優先深刻闡述【2.四、純前端版本發佈】這一小結。

原內容以下：

2.四、純前端版本發佈
純前端版本發佈分爲兩步：

* 前端發佈到生產環境——此時能夠經過外網連接加正確的版本號訪問到新版本的代碼，但頁面上的資源仍是舊版本；

* 前端經過配置工具（或者是直接更新html文件），將html中引入的資源，改成新版本。   

解決的問題是：當前端須要發佈新版本時，能夠不依賴於後端（根據實際狀況，也能夠不依賴於運維）。畢竟有不少需求並不須要後端介入，單純改個前端版本後就要後端發佈一次，顯然是一件很是麻煩的事情。

這個須要專門的工具，用於配置版本發佈，我最近就在寫這個。

意義：

提升發佈效率，下降發佈帶來的人員時間損耗（這些都是錢），也能夠在前端版本回滾的時候，速度更快。
複製代碼

一、項目簡述

當前常見場景爲：前端的版本，寫死在後端渲染的頁面中（或者寫死在html靜態頁面中）。

這帶來一個問題，當前端須要發佈版本時，要麼從新發布靜態頁面（依賴使用靜態頁面），要麼須要後端來發布。

• 前者不利於後端使用頁面渲染相關的中間件，好比 csrf 處理中，有一種方法就須要將 csrf-token 寫入到頁面中，又或者是國際化，將國際化內容直接寫入到頁面裏；
• 後者顯而易見，後端發佈是一件很麻煩的事情；

所以，咱們指望實際場景中是這樣一個形式（以下圖）：

經過實現這樣的流程，後端開發者能夠在頁面裏訂閱資源的版本號，並將其值寫入頁面進行渲染。

而前端開發者能夠實現：

• 獨立發佈（經過管理頁面提交最新的版本號，一次配置後無需依賴後端）；
• 提升先後端分離程度和可配置化能力；
• 碰見前端bug時，經過在線快速發佈新版本或回滾到舊版原本修復bug的能力；

二、場景描述

在前端領域中，常見的前端資源命名，有三種方式：

1. 名字不變：如/js/app.js
2. hash名，每次發佈是新的hash：如/js/app.r324wf1.js
3. 帶版本號的名字：如/0.1.0/js/app.js

前端發佈資源時，也有兩種方式：

1. html徹底由前端管理，前端發佈的時候會有html文件，webpack打包時自動在html裏寫文件名；
2. html由後端管理（服務器渲染），前端只負責發佈js、css等資源文件。在前端發佈以後，後端修改版本號再發布；

目前比較好的解決方案是 第三種命名方式 和 第二種發佈方式，優勢：

1. 版本管理清楚明確；
2. 版本發佈後，當前分支自動鎖死（不可修改），避免覆蓋發佈致使的bug；
3. 後端控制視圖（html）能實現的功能更強（好比經過中間件在全部view裏插入一些內容）；

實際場景對比：

【常規方式】

1. 假如html後端管理，html上有一個js資源加載，連接爲：
2. 發佈後，發現1.1.10版本的前端頁面存在一個bug，因而快速修復，發佈1.1.11版本；
3. 若是須要修復這個bug，那麼須要後端開發將html裏的 1.1.10 修改成 1.1.11，而後再發布一次版本。缺點是後端發佈毫無疑問是很麻煩的一件事情。

【應用本項目後的解決方案】

1. 配置key-value系統，key爲version，value默認配置爲1.1.10，html的資源加載寫爲：
2. 第二步不變，前端發佈修復了bug的1.1.11版本；
3. 在系統裏更新配置，將key=version的value，更新爲1.1.11；
4. 後端開發不須要作任何工做，Server在請求時，檢測到version這個key的value過時（默認每一個key都有過時時間，例如5秒），所以從新讀取MySQL或Redis裏key=version的value值。並將version的值更新爲1.1.11；
5. 所以線上資源加載的真實資源從1.1.10變爲1.1.11；

其餘應用場景：

1. 頁面中的通知信息：好比說，頁面內嵌一個消息框是系統通知，這個通知可能會變，每次手動改通知的話就比較麻煩。寫運營配置工具又浪費時間，能夠經過這種配置來實現。
2. 其餘須要返回數據是可配置的場景；

三、數據結構簡述

1. 應用-Key兩級結構：爲了方便管理，每一個用戶均可以建立應用，並在應用下建立Key（即Key屬於應用）。
2. Key-value系統：key須要註冊，每一個key都有value存在。使用時，經過key能夠獲取key對應的value，方便管理。
3. Key的新增/編輯（前端）：經過專門的管理頁面，使用者能夠將key-value寫入MySQL，每一次編輯都應有歷史記錄；
4. 權限管理：普通用戶，只能建立有限數量個（如0~3個）應用，但能夠得到其餘應用的管理權限；管理員用戶能夠查看/編輯/刪除全部的應用和其所屬的key-value；
5. value的獲取（後端）：server註冊綁定key，綁定後會定時從Redis或MySQL同步value到本機緩存，以確保本機的緩存是最新的。在渲染頁面時，能夠實時獲取key對應的value（這一步是同步的）

四、項目核心點

一、Server-Redis-MySQL三層結構：

之因此設計三層結構：

• 一是由於Redis這麼fashion又好用的東西，能不上嘛；
• 二是加入Redis能夠做爲緩存，減小MySQL的讀寫壓力（Redis的併發量更大），以及確保一致性（數據優先從MySQL讀）；
• 三對分佈式應用更友好；

二、Server取value值：

功能說明：

1. 須要配置該key的默認值，默認值將按期從Redis或者MySQL讀取並更新；
2. 每次渲染的時候，默認從本機緩存取（確保不影響渲染速度），獲取的是默認值；
3. 若是本機緩存的默認值過時，則從Redis獲取，而後寫入本機緩存（減小MySQL壓力）；
4. 若是Redis也不存在（過時），則從MySQL讀取，而後寫入Redis和本機緩存；
5. 本機緩存存在過時時間（默認10秒），過時後，則從Redis讀取並更新本機緩存；
6. Redis的數據存在過時時間（默認600秒），過時後，下次獲取的時候，會被寫入最新的數據；
7. 能夠強制獲取MySQL的數據，用於更新Redis的緩存；

異常處理：

• 【1】當沒法從Redis取到值，則取默認值；
• 【2】當沒法鏈接Redis，將重試一次，若是重試失敗，則取默認值；
• 【3】當沒法鏈接MySQL，重試一次，重試失敗，則取默認值；

可能存在的問題：

【1】後進先出問題：

Server沒法從Redis讀取值時（值過時），讀取MySQL，此時值記爲（A）。

在寫入Redis以前，用戶提交版本號到MySQL（此時值記爲B）。

若用戶提交的B，先寫入Redis（B），而後Server從MySQL讀取的舊值再寫入Redis（A）。

此時，Redis的值是舊值（A），而不是新值（B）。

將在600秒後（在Redis中配置的默認過時時間），Redis緩存過時後，纔會讀取新值。

三、用戶新建、更新key-value

功能說明：

1. 用戶先登陸，登陸後能夠查看本身管理的全部應用和該應用下的key（讀取自MySQL）；
2. 用戶能夠新建key，填寫對應的value，保存後保存到MySQL，而後再更新到Redis；
3. 編輯Key時，從MySQL讀取，保存時，更新到MySQL和Redis；
4. 刪除Key時，從MySQL標記爲刪除（而不是真的刪除），並刪除Redis的緩存（慎重，危險操做，額外提示）；

五、後臺服務

1. Nginx服務：反向代理，將用戶訪問指向後臺服務器，爲後期負載均衡擴展作準備。
2. Server應用：正常的後臺應用，會渲染頁面。
3. Redis：MySQL的緩存
4. MySQL：版本管理數據將存在這裏。
5. 版本管理前臺：登陸、新增、編輯、刪除應用和key時在這裏。

六、項目架構圖

以下圖：

七、數據庫設計

一、database名：version_controller

二、用戶表：（表名developer_info）

表結構和源代碼略

三、應用表：（表名app）

略

四、key-value表：(表名key_value)

略

五、權限管理sql

略

八、後期功能擴展

1. 能夠經過好比QQ機器人等，經過key查看key-value，甚至編輯key-value；
2. key-value更新後，向有編輯權限的用戶和建立者，推送郵件告知；
3. 提交key值的更新後，增長審批流程；

九、示例效果

後端動態渲染頁面：

http://119.3.214.234:6644/

管理頁面（新增、編輯應用/key）：（帳號和密碼都是12345678）

http://119.3.214.234:7789/

python端使用該應用的package（缺乏鏈接mysql和redis的配置，但其餘是全的）：

github.com/qq20004604/…

十、總結

因爲時間和精力所限，我給了一個包含了主要功能的DEMO，具體的細節並不完善，請見諒。

文章內容可能有所缺漏或錯誤，歡迎指出。

關鍵的數據庫設計和後臺管理頁面的代碼，因爲有其餘用處，因此沒有開源，但功能描述已經在上面寫的很清楚了。

想要深刻討論的，能夠加個人微信：qq20004604，也能夠加個人技術交流QQ羣：387017550

順便問一下，西安有沒有能給15k每個月，年薪20w以上的國企？麻煩介紹一下給我~

end~