淺析從基礎層和應用層設計前端架構如何做

　　本篇文章不會更多側重於具體技術實現，而是嘗試從更高角度出發，分析為什么要這么做，這些設計能解決什么問題，成本和收益如何。

一、綜合考量

1、核心思想

　　解決問題：前端架構的設計，應是用於解決已存在或者未來可能發生的技術問題，增加項目的可管理性、穩定性、可擴展性。

　　人效比：對於需要額外開發工作量的事務，我們在決定是否去做的時候，應該考慮到兩個要素：第一個是花費的人力成本，第二個是未來可能節約的時間和金錢、避免的項目風險與資損、提高對業務的支撐能力以帶來在業務上可衡量的更高的價值、以及其他價值。

　　定性和定量：架構里設計的內容，一定要有是可衡量的意義的，最好是可以定量的——即可以衡量帶來的收益或減少的成本，至少是可以定性的——即雖然無法用數字闡述收益，但我們可以明確這個是有意義的，例如增加安全性降低風險。

　　數據敏感：專門寫這一條強調數據作為依據的重要性。當我們需要說服其他部門/上級管理者，以推動我們設計的內容時，只有數據——特別是跟錢有關的數據，才是最有說服力的證明。

　　由於篇幅所限，本文很難直接給出定量的值，因此建議架構設計者，先確保項目中設計使用2.7里的埋點系統，根據埋點系統獲取的數據，對項目效果進行定量分析，並以此寫成PPT和其他部門/上級管理者進行協調。

2、切入角度：分為基礎層和應用層。

　　基礎層偏基礎設施建設，與業務相關性較低。

　　應用層更貼近用戶，用於解決某一個問題。

　　部分兩個都沾邊的，根據經驗划分到其中一個。

3、由於已經談到架構層級，因此很多內容，並不僅僅只屬於前端領域，有很多內容是復合領域（前端、后端、運維、測試），因此需要負責架構的人，技術棧足夠全面，對未來發展有足夠的前瞻性。

　　文章的內容結構為：【項目】—>【解決的問題和帶來的好處】—>【項目的實際意義】

二、基礎層設計

1、自建Gitlab

　　這個是基礎的基礎了。本不應該提的，不過考慮到有的公司（人數並不少）並沒有使用Gitlab，因此專門提一下，並且使用這個的難度非常低。

　　強烈建議使用 Gitlab 進行版本管理，自建Gitlab難度並不大，方便管理，包括代碼管理、權限管理、提交日志查詢，以及聯動一些第三方插件。

　　意義：公司代碼是公司的重要資產，使用自建Gitlab可以有效保護公司資產。

2、版本管理

　　版本管理的幾個關鍵點：

• 發布后分支鎖死，不可再更改：指當例如0.0.1版本成功發布后，不可再更改0.0.1分支上的代碼，否則可能會導致版本管理混亂。

• 全自動流程發布；指應避免開發者提交后，手動編譯打包等操作，換句話說，開發人員發布后，將自動發布到預發布/生產環境。開發人員不和相關環境直接接觸。實現這個需要參考下面的2.3。

• 多版本並存；指當例如發布0.0.2版本后，0.0.1版本的代碼應仍保存在線上（例如CDN），這樣當出現線上bug時，方便快速回滾到上一個版本。

　　意義：提高項目的可控性。

3、自動編譯發布 Jenkins + docker

　　這個工具用於在代碼發布后，執行一系列流程，例如自動編譯打包合並，然后再從Gitlab發布到CDN或者靜態資源服務器。使用這個工具，可以讓一般研發人員不關心代碼傳到Gitlab后會發生什么事情，只需要專心於開發就可以了。

　　意義：讓研發人員專心於研發，和環境、運維等事情脫鈎。

4、統一腳手架

　　適用場景：有比較多獨立中小項目。好處：

• 可以減少開發人員配置腳手架帶來的時間損耗（特殊功能可以fork腳手架后再自行定制）；

• 統一項目結構，方便管理，也降低項目交接時帶來的需要熟悉項目的時間；

• 方便統一技術棧，可以預先引入固定的組件庫；

　　意義：提高開發人員在多個項目之間的快速切換能力，提高項目可維護性，統一公司技術棧，避免因為環境不同導致奇怪的問題。

5、埋點系統

　　強烈推薦前端做自己的埋點系統。這個不同於后端的日志系統。前端埋點系統的好處：

• 記錄每個頁面的訪問量（日周月年的UV、PV）；

• 記錄每個功能的使用量；

• 捕捉報錯情況；

• 圖表化顯示，方便給其他部門展示；

　　埋點系統是前端高度介入業務，把握業務發展情況的一把利劍，通過這個系統，我們可以比后端更深刻的把握用戶的習慣，以及給產品經理、運營等人員提供准確的數據依據。當有了數據后，前端人員就可以針對性的優化功能、布局、頁面交互邏輯、用戶使用流程。

　　埋點系統應和業務解耦，開發人員使用時注冊，然后在項目中引入。然后在埋點系統里查看相關數據（例如以小時、日、周、月、年為周期查看）

　　意義：數據是money，數據是公司的生命線，數據是最好的武器。

6、監控和報警系統

　　監控和報警系統應基於埋點系統而建立，在如以下場景時：

• 當訪問量有比較大的變化（比如日PV/UV只有之前20%以下）時，自動觸發報警，發送郵件到相關人員郵箱；

• 比如報錯量大幅度上升（比如200%或更高），則觸發報警；

• 當一段時間內沒有任何訪問量（不符合之前的情況），則觸發報警；

• 每過一段時間，自動匯總訪問者/報錯觸發者的相關信息（例如系統、瀏覽器版本等）；

　　建設這個系統的好處在於，提前發現一些不容易發現的bug（需要埋點做的比較扎實）。有一些線上bug，因為用戶環境特殊，導致無法被開發人員和測試人員發現。但其中一部分bug又因為不涉及資金，並不會導致資損（因此也不會被后端的監控系統所發現），這樣的bug非常容易影響項目里某個鏈路的正常使用。

　　意義：提高項目的穩定性，提高對業務的把控能力。降低bug數，降低資損的可能性，提前發現某些功能的bug（在工單到來之前）。

7、安全管理

　　安全管理的很難從架構設計上完全避免，但還是有一定解決方案的，常見安全問題如下：

• XSS注入：對用戶輸入的內容，需要轉碼（大部分時候要server端來處理，偶爾也需要前端處理），禁止使用eval函數；

• https：這個顯然是必須的，好處非常多；

• CSRF：要求server端加入CSRF的處理方法（至少在關鍵頁面加入）；

　　意義：減少安全漏洞，避免用戶受到損失，避免遭遇惡意攻擊，增加系統的穩定性和安全性。

8、Eslint

　　Eslint的好處很多，強烈推薦使用：

• 降低低級bug（例如拼寫問題）出現的概率；

• 增加代碼的可維護性，可閱讀性；

• 硬性統一代碼風格，團隊協作起來時更輕松；

　　總的來說，eslint推薦直接配置到腳手架之中，對我們提高代碼的可維護性的幫助會很大。可以考慮在上傳到gitlab時，硬性要求eslint校驗，通過的才允許上傳。

　　意義：提高代碼的可維護性，降低團隊協作的成本。

9、灰度發布

　　灰度發布是大型項目在發布時的常見方法，指在發布版本時，初始情況下，只允許小比例（比如1~5%比例的用戶使用），若出現問題時，可以快速回滾使用老版本，適用於主鏈路和訪問量極大的頁面。好處有以下幾點：

• 生產環境比開發環境復雜，灰度發布時可以在生產環境小范圍嘗試觀察新版本是否可以正常運行，即使出問題，也可以控制損失。

• 對於大版本更新，可以先灰度一部分，觀察埋點效果和用戶反饋（即所謂的搶先試用版）。假如效果並不好，那么回滾到老版本也可以及時止損；

• 當我們需要驗證某些想法或問題的時候，可以先灰度一部分，快速驗證效果如何，然后查漏補缺或者針對性優化；

　　意義：降低風險，提高發布靈活度。

10、Mock 平台

　　Mock也是常見前端系統之一，用於解決在后端接口未好時，生成返回的數據。有很多 mock 平台，這個就不多說了。

　　意義：在前后端並行開發時，降低溝通交流成本，方便開發完畢后直接對接。

11、定期備份

　　備份是常被忽略的一件事情，但當我們遇見毀滅性場景時，缺少備份帶來的損失是非常大的，常見場景：

• 服務器損壞，導致存在該服務器上的內容全部完蛋；

• 觸發某致命bug或者錯誤操作（例如rm -f），導致文件和數據全部消失；

• 數據庫出現錯誤操作或出現問題，導致用戶數據、公司資產遭受嚴重損失；

　　總的來說，沒人想遇見這樣的場景，但我們必須考慮這種極端情況的發生，因此需要從架構層面解決這個問題。常見方法是定期備份、多機備份、容災系統建設等。

　　意義：避免在遭遇極端場景時，給公司帶來不可估量的損失。

三、應用層設計

 1、以應用為單位划分前端項目

　　在項目比較大的時候，將所有頁面的前端文件放入到同一個代碼倉庫里，根據使用經驗來看存在很多問題：

• 會極大的增加代碼的維護難度；

• 項目會變得很丑陋；

• 不方便權限管理，容易造成頁面誤更改或代碼泄密；

• 任何人都有權利改任何他能看到的頁面（在合並代碼的時候，管理人員並不能確定他本次修改的頁面是否是需求里他應該改的頁面）；

• 發布成本高，即使改一個頁面，也需要發布所有資源；

　　因此，我們應該避免這種現象的發生，個人推薦以應用為單位進行開發、發布。所謂應用即指一個業務涉及到的前后端代碼，好處很多：

• 方便進行管理，當某個業務有需求變更時，可以只給研發人員該業務前端應用的developer權限；

• 在需要發布某業務時，只需要發布該業務的所屬應用即可；

　　意義：規范項目，增加代碼的安全性，降低項目維護成本。

 2、基礎組件庫的建設

　　這個蠻基礎的，對於組件庫的建設，不建議研發人員較少時去做這件事情，專職前端開發人數少於10人時，建議使用比較靠譜的第三方UI庫，例如Antd，這樣性價比更高。設計基礎組件庫的前提，是要求統一技術棧，這樣才能最大化基礎組件庫的效益。組件庫建議以使用以下參考標准：

• 使用ts；

• 可擴展性強；

• 適用程度高；

• 文檔清楚詳細；

• 版本隔離，小版本優化加功能，大改需要大版本更新；

• 和UI協調統一，要求UI交互參與進來；

　　總的來說，建設起來后，利大於弊，但是需要專人維護，因此還是有一定成本的。

　　意義：統一不同/相同產品線之間的風格，給用戶更好的體驗，減少單次開發中寫UI組件時浪費的時間和人力，提高開發效率。

3、內容平台建設

　　為了提高公司內部的溝通效率，總結經驗，以及保密原因。應建設一個內部論壇+博客站點。其具備的好處如下：

• 可以記錄公司的歷史；

• 研發同學之間分享經驗；

• 總結轉載一些外界比較精品的文章，提高大家的眼界；

• 增加公司內部同學的交流，有利於公司的團隊和文化建設；

• 對某些技術問題可以進行討論，減少因沒有達成共識帶來的溝通損耗；

　　眾所周知，大型互聯網公司通常都有這樣一個內部論壇和博客站點。其降低了公司的溝通和交流成本，也增加了公司的技術積累。

　　意義：博客增強技術積累，論壇增強公司內部溝通能力。

4、登錄系統設計（單點登錄）

　　當公司內部業務線比較復雜但相互之間的耦合度比較高時，我們應該考慮設計添加單點登錄系統。具體來說，用戶在一處登錄，即可以在任何頁面訪問，登出時，也同樣在任何頁面都失去登錄狀態。SSO的好處很多：

• 增強用戶體驗；

• 打通了不同業務系統之間的用戶數據；

• 方便統一管理用戶；

• 有利於引流；

• 降低開發系統的成本（不需要每個業務都開發一次登錄系統和用戶狀態控制）；

　　總的來說，大中型web應用，SSO可以帶來很多好處，缺點卻很少。

　　意義：用戶體驗增強，打通不同業務之間的間隔，降低開發成本和用戶管理成本。

5、CDN

　　前端資源的加載速度是衡量用戶體驗的重要指標之一。而現實中，因為種種因素，用戶在加載頁面資源時，會受到很多限制。因此上CDN是非常有意義的，好處如下：

• 用戶來自不同地區，加入CDN可以使用戶訪問資源時，訪問離自己比較近的CDN服務器，降低訪問延遲；

• 降低服務器帶寬使用成本；

• 支持視頻、靜態資源、大文件、小文件、直播等多種業務場景；

• 消除跨運營商造成的網絡速度較慢的問題；

• 降低DDOS攻擊造成的對網站的影響；

　　CDN是一種比較成熟的技術，各大雲平_台都有提供CDN服務，價格也不貴，因此CDN的性價比很高。

　　意義：增加用戶訪問速度，降低網絡延遲，帶寬優化，減少服務器負載，增強對攻擊的抵抗能力。

6、負載均衡

　　目前來看，負載均衡通常使用Nginx比較多，以前也有使用Apache。當遇見大型項目的時候，負載均衡和分布式幾乎是必須的。負載均衡有以下好處：

• 降低單台server的壓力，提高業務承載能力；

• 方便應對峰值流量，擴容方便（如舉辦某些活動時）；

• 增強業務的可用性、擴展性、穩定性；

　　負載均衡已經是蠻常見的技術了，好處不用多說，很容易理解。

　　意義：增強業務的可用性、擴展性、穩定性，可以支持更多用戶的訪問。

7、多端共用一套接口

　　目前常見場景是一個業務，同時有PC頁面和H5頁面，由於業務是一樣的，因此應避免同一個業務有多套接口分別適用於PC和H5端。因此解決方案如下：

• 后端提供的接口，應該同時包含PC和H5的數據（即單獨對一個存在冗余數據）；

• 接口應當穩定，即當業務變更時，應盡量采取追加數據的形式；

• 只有在單獨一端需要特殊業務流程時，設計單端獨有接口；

　　多端共用接口，是減少開發工作量，並且提高業務可維護性的重要解決方案。

　　意義：降低開發工作量，增強可維護性。

 8、總結

　　由於各個公司具體情況不同，項目也具有特殊性，因此以上設計不可強行套入，應根據自己公司規模、項目進展、人員數量等，先添加比較重要的功能和設計。並需要考慮到長期項目的可維護性和發展需要，對部分基礎設施進行提前研發設計。

　　本文來源於文章：https://juejin.cn/post/6844903853859536903 的學習筆記，以上確實是常用而需要考慮的。做架構就是需要將平時項目中用到的技術和解決方案多總結多思考，從而形成自己的架構設計理念，后期我也需要多思考這方面帶來的意義。

　　還有這一篇有些具體實施內容：https://mp.weixin.qq.com/s/rCRzr2WY70eKOkFjfb4G-A，可以看一下