稿件來(lái)源：https://juejin.im/post/5cea1f705188250640005472
目錄：
- 1、綜合
- 1.1、使用場(chǎng)景
- 1.2、核心思想
- 1.3、切入角度
- 1.4、其他
- 2、基礎(chǔ)層設(shè)計(jì)
- 2.1、自建Gitlab
- 2.2、版本管理
- 2.3、自動(dòng)編譯發(fā)布Jenkins
- 2.4、純前端版本發(fā)布
- 2.5、統(tǒng)一腳手架
- 2.6、Node中間層
- 2.7、埋點(diǎn)系統(tǒng)
- 2.8、監(jiān)控和報(bào)警系統(tǒng)
- 2.9、安全管理
- 2.10、Eslint
- 2.11、灰度發(fā)布
- 2.12、前后端分離
- 2.13、Mock
- 2.14、定期備份
- 3、應(yīng)用層設(shè)計(jì)
- 3.1、多頁(yè)和單頁(yè)
- 3.2、以應(yīng)用為單位劃分前端項(xiàng)目
- 3.3、基礎(chǔ)組件庫(kù)的建設(shè)
- 3.4、技術(shù)棧統(tǒng)一
- 3.5、瀏覽器兼容
- 3.6、內(nèi)容平_臺(tái)建設(shè)
- 3.7、權(quán)限管理平_臺(tái)
- 3.8、登錄系統(tǒng)設(shè)計(jì)（單點(diǎn)登錄）
- 3.9、CDN
- 3.10、負(fù)載均衡
- 3.11、多端共用一套接口
- 4、總結(jié)
1、綜合
我在2年之前，寫(xiě)過(guò)一篇中小型項(xiàng)目的前端架構(gòu)淺談。隨著能力的上升，以及在阿里巴巴工作的經(jīng)驗(yàn)，是時(shí)候?qū)懸黄笮晚?xiàng)目的前端架構(gòu)分析了。
本篇文章不會(huì)更多側(cè)重于具體技術(shù)實(shí)現(xiàn)，而是嘗試從更高角度出發(fā)，分析為什么要這么做，這些設(shè)計(jì)能解決什么問(wèn)題，成本和收益如何。
由于作者能力有限，可能會(huì)有所缺漏或者部分錯(cuò)誤，歡迎讀者指出。
1.1、適用場(chǎng)景：
本篇文章，適用于單個(gè)/多個(gè)大型項(xiàng)目、擁有超過(guò)10個(gè)以上的前端開(kāi)發(fā)的場(chǎng)景。
前端項(xiàng)目的規(guī)模不同，成本收益比也會(huì)有所差別。通常來(lái)說(shuō)，人員越多、項(xiàng)目復(fù)雜度越高，那么收益/成本的比值越大。
對(duì)于人數(shù)較少、項(xiàng)目簡(jiǎn)單的開(kāi)發(fā)團(tuán)隊(duì)，可能有部分措施不適用，因此應(yīng)該根據(jù)具體情況來(lái)選用。
1.2、核心思想：
【1】解決問(wèn)題：前端架構(gòu)的設(shè)計(jì)，應(yīng)是用于解決已存在或者未來(lái)可能發(fā)生的技術(shù)問(wèn)題，增加項(xiàng)目的可管理性、穩(wěn)定性、可擴(kuò)展性。
【2】人效比：對(duì)于需要額外開(kāi)發(fā)工作量的事務(wù)（本文中存在一些需要一定開(kāi)發(fā)量的內(nèi)容），我們?cè)跊Q定是否去做的時(shí)候，應(yīng)該考慮到兩個(gè)要素：第一個(gè)是花費(fèi)的人力成本，第二個(gè)是未來(lái)可能節(jié)約的時(shí)間和金錢(qián)、避免的項(xiàng)目風(fēng)險(xiǎn)與資損、提高對(duì)業(yè)務(wù)的支撐能力以帶來(lái)在業(yè)務(wù)上可衡量的更高的價(jià)值、以及其他價(jià)值。
【3】定性和定量：架構(gòu)里設(shè)計(jì)的內(nèi)容，一定要有是可衡量的意義的，最好是可以定量的——即可以衡量帶來(lái)的收益或減少的成本，至少是可以定性的——即雖然無(wú)法用數(shù)字闡述收益，但我們可以明確這個(gè)是有意義的，例如增加安全性降低風(fēng)險(xiǎn)。
【4】數(shù)據(jù)敏感：專(zhuān)門(mén)寫(xiě)這一條強(qiáng)調(diào)數(shù)據(jù)作為依據(jù)的重要性。當(dāng)我們需要說(shuō)服其他部門(mén)/上級(jí)管理者，以推動(dòng)我們?cè)O(shè)計(jì)的內(nèi)容時(shí)，只有數(shù)據(jù)——特別是跟錢(qián)有關(guān)的數(shù)據(jù)，才是最有說(shuō)服力的證明。
由于篇幅所限，本文很難直接給出定量的值，因此建議架構(gòu)設(shè)計(jì)者，先確保項(xiàng)目中設(shè)計(jì)使用2.7里的埋點(diǎn)系統(tǒng)，根據(jù)埋點(diǎn)系統(tǒng)獲取的數(shù)據(jù)，對(duì)項(xiàng)目效果進(jìn)行定量分析，并以此寫(xiě)成PPT和其他部門(mén)/上級(jí)管理者進(jìn)行協(xié)調(diào)。
1.3、切入角度：
分為基礎(chǔ)層和應(yīng)用層。
基礎(chǔ)層偏基礎(chǔ)設(shè)施建設(shè)，與業(yè)務(wù)相關(guān)性較低。
應(yīng)用層更貼近用戶(hù)，用于解決某一個(gè)問(wèn)題。
部分兩個(gè)都沾邊的，根據(jù)經(jīng)驗(yàn)劃分到其中一個(gè)。
1.4、其他
由于已經(jīng)談到架構(gòu)層級(jí)，因此很多內(nèi)容，并不僅僅只屬于前端領(lǐng)域，有很多內(nèi)容是復(fù)合領(lǐng)域（前端、后端、運(yùn)維、測(cè)試），因此需要負(fù)責(zé)架構(gòu)的人，技術(shù)棧足夠全面，對(duì)未來(lái)發(fā)展有足夠的前瞻性。
文章的內(nèi)容結(jié)構(gòu)為：【項(xiàng)目】—>【解決的問(wèn)題和帶來(lái)的好處】—>【項(xiàng)目的實(shí)際意義】
2、基礎(chǔ)層設(shè)計(jì)
2.1、自建Gitlab
這個(gè)是基礎(chǔ)的基礎(chǔ)了。本不應(yīng)該提的，不過(guò)考慮到我最近面試的幾家公司，有的公司（人數(shù)并不少）并沒(méi)有使用Gitlab，因此專(zhuān)門(mén)提一下，并且使用這個(gè)的難度非常低。
強(qiáng)烈建議使用Gitlab進(jìn)行版本管理，自建Gitlab難度并不大，方便管理，包括代碼管理、權(quán)限管理、提交日志查詢(xún)，以及聯(lián)動(dòng)一些第三方插件。
意義：
公司代碼是公司的重要資產(chǎn)，使用自建Gitlab可以有效保護(hù)公司資產(chǎn)。
2.2、版本管理
版本管理的幾個(gè)關(guān)鍵點(diǎn)：
- 發(fā)布后分支鎖死，不可再更改：指當(dāng)例如0.0.1版本成功發(fā)布后，不可再更改0.0.1分支上的代碼，否則可能會(huì)導(dǎo)致版本管理混亂。
- 全自動(dòng)流程發(fā)布；指應(yīng)避免開(kāi)發(fā)者提交后，手動(dòng)編譯打包等操作，換句話(huà)說(shuō)，開(kāi)發(fā)人員發(fā)布后，將自動(dòng)發(fā)布到預(yù)發(fā)布/生產(chǎn)環(huán)境。開(kāi)發(fā)人員不和相關(guān)環(huán)境直接接觸。實(shí)現(xiàn)這個(gè)需要參考下面的2.3。
- 多版本并存；指當(dāng)例如發(fā)布0.0.2版本后，0.0.1版本的代碼應(yīng)仍保存在線(xiàn)上（例如CDN），這樣當(dāng)出現(xiàn)線(xiàn)上bug時(shí)，方便快速回滾到上一個(gè)版本。
意義：
提高項(xiàng)目的可控性。
2.3、自動(dòng)編譯發(fā)布Jenkins
這個(gè)工具用于在代碼發(fā)布后，執(zhí)行一系列流程，例如自動(dòng)編譯打包合并，然后再?gòu)腉itlab發(fā)布到CDN或者靜態(tài)資源服務(wù)器。
使用這個(gè)工具，可以讓一般研發(fā)人員不關(guān)心代碼傳到Gitlab后會(huì)發(fā)生什么事情，只需要專(zhuān)心于開(kāi)發(fā)就可以了。
意義：
讓研發(fā)人員專(zhuān)心于研發(fā)，和環(huán)境、運(yùn)維等事情脫鉤。
2.4、純前端版本發(fā)布
純前端版本發(fā)布分為兩步：
- 前端發(fā)布到生產(chǎn)環(huán)境——此時(shí)可以通過(guò)外網(wǎng)鏈接加正確的版本號(hào)訪(fǎng)問(wèn)到新版本的代碼，但頁(yè)面上的資源還是舊版本；
- 前端通過(guò)配置工具（或者是直接更新html文件），將html中引入的資源，改為新版本。
解決的問(wèn)題是：當(dāng)前端需要發(fā)布新版本時(shí)，可以不依賴(lài)于后端（根據(jù)實(shí)際情況，也可以不依賴(lài)于運(yùn)維）。畢竟有很多需求并不需要后端介入，單純改個(gè)前端版本后就要后端發(fā)布一次，顯然是一件非常麻煩的事情。
這個(gè)需要專(zhuān)門(mén)的工具，用于配置版本發(fā)布，我最近就在寫(xiě)這個(gè)。
意義：
提高發(fā)布效率，降低發(fā)布帶來(lái)的人員時(shí)間損耗（這些都是錢(qián)），也可以在前端版本回滾的時(shí)候，速度更快。
2.5、統(tǒng)一腳手架
適用場(chǎng)景：有比較多獨(dú)立中小項(xiàng)目。好處：
- 可以減少開(kāi)發(fā)人員配置腳手架帶來(lái)的時(shí)間損耗（特殊功能可以fork腳手架后再自行定制）；
- 統(tǒng)一項(xiàng)目結(jié)構(gòu)，方便管理，也降低項(xiàng)目交接時(shí)帶來(lái)的需要熟悉項(xiàng)目的時(shí)間；
- 方便統(tǒng)一技術(shù)棧，可以預(yù)先引入固定的組件庫(kù)；
意義：
提高開(kāi)發(fā)人員在多個(gè)項(xiàng)目之間的快速切換能力，提高項(xiàng)目可維護(hù)性，統(tǒng)一公司技術(shù)棧，避免因?yàn)榄h(huán)境不同導(dǎo)致奇怪的問(wèn)題。
2.6、Node中間層
適用場(chǎng)景：需要seo且前端使用React、vue，或前端介入后端邏輯，直接讀取后端服務(wù)或者數(shù)據(jù)庫(kù)的情況。
- SEO：仁者見(jiàn)仁智者見(jiàn)智，雖然很多公司已經(jīng)不做了，但通常認(rèn)為，還是有一定意義的（特別是需要搜索引擎引流的時(shí)候），因此React或者Vue的同構(gòu)是必須的。并且同構(gòu)還可以降低首頁(yè)白屏?xí)r間；
- 前端讀取后端服務(wù)/數(shù)據(jù)庫(kù)：好處是提高前端的開(kāi)發(fā)效率和對(duì)業(yè)務(wù)的支持能力，缺點(diǎn)是可能導(dǎo)致P0級(jí)故障。
意義：
讓前端可以侵入后端領(lǐng)域，質(zhì)的提升對(duì)業(yè)務(wù)的支持能力。
2.7、埋點(diǎn)系統(tǒng)
強(qiáng)烈推薦前端做自己的埋點(diǎn)系統(tǒng)。這個(gè)不同于后端的日志系統(tǒng)。
前端埋點(diǎn)系統(tǒng)的好處：
- 記錄每個(gè)頁(yè)面的訪(fǎng)問(wèn)量（日周月年的UV、PV）；
- 記錄每個(gè)功能的使用量；
- 捕捉報(bào)錯(cuò)情況；
- 圖表化顯示，方便給其他部門(mén)展示；
埋點(diǎn)系統(tǒng)是前端高度介入業(yè)務(wù)，把握業(yè)務(wù)發(fā)展情況的一把利劍，通過(guò)這個(gè)系統(tǒng)，我們可以比后端更深刻的把握用戶(hù)的習(xí)慣，以及給產(chǎn)品經(jīng)理、運(yùn)營(yíng)等人員提供準(zhǔn)確的數(shù)據(jù)依據(jù)。當(dāng)有了數(shù)據(jù)后，前端人員就可以針對(duì)性的優(yōu)化功能、布局、頁(yè)面交互邏輯、用戶(hù)使用流程。
埋點(diǎn)系統(tǒng)應(yīng)和業(yè)務(wù)解耦，開(kāi)發(fā)人員使用時(shí)注冊(cè)，然后在項(xiàng)目中引入。然后在埋點(diǎn)系統(tǒng)里查看相關(guān)數(shù)據(jù)（例如以小時(shí)、日、周、月、年為周期查看）[原創(chuàng)水印-作者：零零水(王冬)，微信：qq20004604]。
意義：
數(shù)據(jù)是money，數(shù)據(jù)是公司的生命線(xiàn)，數(shù)據(jù)是最好的武器。
2.8、監(jiān)控和報(bào)警系統(tǒng)
監(jiān)控和報(bào)警系統(tǒng)應(yīng)基于埋點(diǎn)系統(tǒng)而建立，在如以下場(chǎng)景時(shí)[原創(chuàng)水印-作者：零零水(王冬)，微信：qq20004604]觸發(fā)：
- 當(dāng)訪(fǎng)問(wèn)量有比較大的變化（比如日PV/UV只有之前20%以下）時(shí)，自動(dòng)觸發(fā)報(bào)警，發(fā)送郵件到相關(guān)人員郵箱；
- 比如報(bào)錯(cuò)量大幅度上升（比如200%或更高），則觸發(fā)報(bào)警；
- 當(dāng)一段時(shí)間內(nèi)沒(méi)有任何訪(fǎng)問(wèn)量（不符合之前的情況），則觸發(fā)報(bào)警；
- 每過(guò)一段時(shí)間，自動(dòng)匯總訪(fǎng)問(wèn)者/報(bào)錯(cuò)觸發(fā)者的相關(guān)信息（例如系統(tǒng)、瀏覽器版本等）；
建設(shè)這個(gè)系統(tǒng)的好處在于，提前發(fā)現(xiàn)一些不容易發(fā)現(xiàn)的bug（需要埋點(diǎn)做的比較扎實(shí)）。有一些線(xiàn)上bug，因?yàn)橛脩?hù)環(huán)境特殊，導(dǎo)致無(wú)法被開(kāi)發(fā)人員和測(cè)試人員發(fā)現(xiàn)。但其中一部分bug又因?yàn)椴簧婕百Y金，并不會(huì)導(dǎo)致資損（因此也不會(huì)被后端的監(jiān)控系統(tǒng)所發(fā)現(xiàn)），這樣的bug非常容易影響項(xiàng)目里某個(gè)鏈路的正常使用。
意義：
提高項(xiàng)目的穩(wěn)定性，提高對(duì)業(yè)務(wù)的把控能力。降低bug數(shù)，降低資損的可能性，提前發(fā)現(xiàn)某些功能的bug（在工單到來(lái)之前）。
2.9、安全管理
前端的安全管理，通常要依賴(lài)于后端，至于只跟單純有關(guān)系的例如dom.innerHTML= 'xxx '這種太基礎(chǔ)，就不提了。
安全管理的很難從架構(gòu)設(shè)計(jì)上完全避免，但還是有一定解決方案的，常見(jiàn)安全問(wèn)題如下：
- XSS注入：對(duì)用戶(hù)輸入的內(nèi)容，需要轉(zhuǎn)碼（大部分時(shí)候要server端來(lái)處理，偶爾也需要前端處理），禁止使用eval函數(shù)；
- https：這個(gè)顯然是必須的，好處非常多；
- CSRF：要求server端加入CSRF的處理方法（至少在關(guān)鍵頁(yè)面加入）；
意義：
減少安全漏洞，避免用戶(hù)受到損失，避免遭遇惡意攻擊，增加系統(tǒng)的穩(wěn)定性和安全性。
2.10、Eslint
Eslint的好處很多，強(qiáng)烈推薦使用：
- 降低低級(jí)bug（例如拼寫(xiě)問(wèn)題）出現(xiàn)的概率；
- 增加代碼的可維護(hù)性，可閱讀性；
- 硬性統(tǒng)一代碼風(fēng)格，團(tuán)隊(duì)協(xié)作起來(lái)時(shí)更輕松；
總的來(lái)說(shuō)，eslint推薦直接配置到腳手架之中，對(duì)我們提高代碼的可維護(hù)性的幫助會(huì)很大。可以考慮在上傳到gitlab時(shí)，硬性要求eslint校驗(yàn)，通過(guò)的才允許上傳。
意義：
提高代碼的可維護(hù)性，降低團(tuán)隊(duì)協(xié)作的成本。
2.11、灰度發(fā)布
灰度發(fā)布是大型項(xiàng)目在發(fā)布時(shí)的常見(jiàn)方法，指在發(fā)布版本時(shí)，初始情況下，只允許小比例（比如1~5%比例的用戶(hù)使用），若出現(xiàn)問(wèn)題時(shí)，可以快速回滾使用老版本，適用于主鏈路和訪(fǎng)問(wèn)量極大的頁(yè)面。
好處有以下幾點(diǎn)：
- 生產(chǎn)環(huán)境比開(kāi)發(fā)環(huán)境復(fù)雜，灰度發(fā)布時(shí)可以在生產(chǎn)環(huán)境小范圍嘗試觀(guān)察新版本是否可以正常運(yùn)行，即使出問(wèn)題，也可以控制損失。
- 對(duì)于大版本更新，可以先灰度一部分，觀(guān)察埋點(diǎn)效果和用戶(hù)反饋（即所謂的搶先試用版）。假如效果并不好，那么回滾到老版本也可以及時(shí)止損；
- 當(dāng)我們需要驗(yàn)證某些想法或問(wèn)題的時(shí)候，可以先灰度一部分，快速驗(yàn)證效果如何，然后查漏補(bǔ)缺或者針對(duì)性?xún)?yōu)化；
灰度發(fā)布通常分為多個(gè)階段：【1】1%；【2】5~10%；【3】30~50%；【4】全量推送（100%）。灰度發(fā)布一定要允許配置某些IP/賬號(hào)訪(fǎng)問(wèn)時(shí)，可以直接訪(fǎng)問(wèn)到灰度版本。
意義：
降低風(fēng)險(xiǎn)，提高發(fā)布靈活度。
2.12、前后端分離
這個(gè)并不是指常見(jiàn)的前后端分離，而是指在分配前后端管控的領(lǐng)域。
中小項(xiàng)目常見(jiàn)的情況是后端只提供接口和讓某個(gè)url指向某個(gè)html，前端負(fù)責(zé)html、css、js等靜態(tài)資源。
但大型項(xiàng)目并不建議這么做，建議前端負(fù)責(zé)除html以外的靜態(tài)資源，而html交給后端處理，理由有很多：
- 后端進(jìn)行渲染，方便統(tǒng)一插入一些代碼和資源，例如埋點(diǎn)js，監(jiān)控js，國(guó)際化文本資源，頁(yè)面標(biāo)識(shí)符等。這些通常是后端通過(guò)調(diào)用某些服務(wù)直接寫(xiě)入的；
- 當(dāng)頁(yè)面需要統(tǒng)一的頭尾時(shí)（參考淘寶里我的淘寶頁(yè)面），前端不應(yīng)該關(guān)注這些跟當(dāng)前頁(yè)面無(wú)關(guān)的東西；
- 某些東西，如果通過(guò)html來(lái)管理，那么耦合度太高了，違背了解耦和分離的原則；
- 前端版本發(fā)布在后端引入某種功能模塊后，可以從單獨(dú)的頁(yè)面控制前端發(fā)布內(nèi)容，比更新html更方便，也利于灰度發(fā)布；
意義：
更規(guī)范的進(jìn)行頁(yè)面管理，降低頁(yè)面和功能的耦合度，減少?gòu)?fù)雜頁(yè)面的環(huán)境配置時(shí)間。
2.13、Mock
Mock也是常見(jiàn)前端系統(tǒng)之一，用于解決在后端接口未好時(shí)，生成返回的數(shù)據(jù)。
我個(gè)人不太建議開(kāi)發(fā)一個(gè)專(zhuān)門(mén)的系統(tǒng)來(lái)Mock，更好的Mock手法是直接嵌入到腳手架之中。思路如下：
- 當(dāng)在開(kāi)發(fā)環(huán)境下，訪(fǎng)問(wèn)鏈接通常是localhost:8000/index.html，此時(shí)加入后綴 ?debug=true；
- 封裝好的異步請(qǐng)求在發(fā)現(xiàn)當(dāng)前鏈接有以上標(biāo)志時(shí)，認(rèn)為是測(cè)試環(huán)境，訪(fǎng)問(wèn)/userinfo 時(shí)，不去讀取線(xiàn)上的數(shù)據(jù)（因?yàn)橐沧x取不到），去本地環(huán)境讀取 src/test_ajax/userinfo.json，并將內(nèi)容返回給用戶(hù)；
- 異步請(qǐng)求正常拿到數(shù)據(jù)，在頁(yè)面中顯示[原創(chuàng)水印-作者：零零水(王冬)，微信：qq20004604]；
- 當(dāng)線(xiàn)上接口可以獲取到數(shù)據(jù)后，從network里找到返回的數(shù)據(jù)，放入/ src/test_ajax/userinfo.json中，此時(shí)再次本地調(diào)試的話(huà)，相當(dāng)于使用的是線(xiàn)上的真實(shí)數(shù)據(jù)。
</li> 復(fù)制代碼
這種處理，可以降低mock的復(fù)雜度，隨時(shí)更改mock時(shí)返回的數(shù)據(jù)，比單獨(dú)開(kāi)發(fā)一個(gè)mock系統(tǒng)性?xún)r(jià)比更高。
意義：
在前后端并行開(kāi)發(fā)時(shí)，降低溝通交流成本，方便開(kāi)發(fā)完畢后直接對(duì)接。
2.14、定期備份
備份是常被忽略的一件事情，但當(dāng)我們遇見(jiàn)毀滅性場(chǎng)景時(shí)，缺少備份帶來(lái)的損失是非常大的，常見(jiàn)場(chǎng)景：
- 服務(wù)器損壞，導(dǎo)致存在該服務(wù)器上的內(nèi)容全部完蛋；
- 觸發(fā)某致命bug或者錯(cuò)誤操作（例如rm -f），導(dǎo)致文件和數(shù)據(jù)全部消失；
- 數(shù)據(jù)庫(kù)出現(xiàn)錯(cuò)誤操作或出現(xiàn)問(wèn)題，導(dǎo)致用戶(hù)數(shù)據(jù)、公司資產(chǎn)遭受?chē)?yán)重?fù)p失；
總的來(lái)說(shuō)，沒(méi)人想遇見(jiàn)這樣的場(chǎng)景，但我們必須考慮這種極端情況的發(fā)生，因此需要從架構(gòu)層面解決這個(gè)問(wèn)題。常見(jiàn)方法是定期備份、多機(jī)備份、容災(zāi)系統(tǒng)建設(shè)等。
意義：
避免在遭遇極端場(chǎng)景時(shí)，給公司帶來(lái)不可估量的損失。
3、應(yīng)用層設(shè)計(jì)
3.1、多頁(yè)和單頁(yè)
除了特殊場(chǎng)景，通常推薦使用多頁(yè)架構(gòu)。理由如下：
- 多頁(yè)項(xiàng)目，頁(yè)面和頁(yè)面之間是獨(dú)立的，不存在交互，因此當(dāng)一個(gè)頁(yè)面需要單獨(dú)重構(gòu)時(shí)，不會(huì)影響其他頁(yè)面，對(duì)于有長(zhǎng)期歷史的項(xiàng)目來(lái)說(shuō)，可維護(hù)性、可重構(gòu)性要高很多；
- 多頁(yè)項(xiàng)目的缺點(diǎn)是不同頁(yè)面切換時(shí)，會(huì)有一個(gè)白屏?xí)r間，但通常來(lái)說(shuō)，這個(gè)時(shí)間并不長(zhǎng)，大部分現(xiàn)有大公司的線(xiàn)上網(wǎng)頁(yè)，都是這樣的，因此認(rèn)為是可以接受的；
- 多頁(yè)項(xiàng)目可以單次只更新一個(gè)頁(yè)面的版本，而單頁(yè)項(xiàng)目如果其中一個(gè)功能模塊要更新（特別是公共組件更新），很容易讓所有頁(yè)面都需要更新版本；
- 多頁(yè)項(xiàng)目的版本控制更簡(jiǎn)單，如果需要頁(yè)面拆分，調(diào)整部分頁(yè)面的使用流程，難度也會(huì)更低；
- 灰度發(fā)布更友好；
之前面試的一家，采用了單頁(yè)的形式，之前因?yàn)榉N種原因，同時(shí)采用了ng和react。由于項(xiàng)目歷史也比較久（3年以上），結(jié)果導(dǎo)致目前繼續(xù)維護(hù)更新的難度很大，即使想部分重構(gòu)，也很麻煩。
意義：
降低長(zhǎng)期項(xiàng)目迭代維護(hù)的難度，
3.2、以應(yīng)用為單位劃分前端項(xiàng)目
在項(xiàng)目比較大的時(shí)候，將所有頁(yè)面的前端文件放入到同一個(gè)代碼倉(cāng)庫(kù)里，我之前參與過(guò)一家企業(yè)的前端項(xiàng)目開(kāi)發(fā)，發(fā)現(xiàn)其就是這么做的。根據(jù)使用經(jīng)驗(yàn)來(lái)看[原創(chuàng)水印-作者：零零水(王冬)，微信：qq20004604]，存在很多問(wèn)題：
- 會(huì)極大的增加代碼的維護(hù)難度；
- 項(xiàng)目會(huì)變得很丑陋；
- 不方便權(quán)限管理，容易造成頁(yè)面誤更改或代碼泄密；
- 任何人都有權(quán)利改任何他能看到的頁(yè)面（在合并代碼的時(shí)候，管理人員并不能確定他本次修改的頁(yè)面是否是需求里他應(yīng)該改的頁(yè)面）；
- 發(fā)布成本高，即使改一個(gè)頁(yè)面，也需要發(fā)布所有資源；
因此，我們應(yīng)該避免這種現(xiàn)象的發(fā)生，個(gè)人推薦以應(yīng)用為單位進(jìn)行開(kāi)發(fā)、發(fā)布。所謂應(yīng)用即指一個(gè)業(yè)務(wù)涉及到的前后端代碼，好處很多：
- 方便進(jìn)行管理，當(dāng)某個(gè)業(yè)務(wù)有需求變更時(shí)，可以只給研發(fā)人員該業(yè)務(wù)前端應(yīng)用的developer權(quán)限；
- 在需要發(fā)布某業(yè)務(wù)時(shí)，只需要發(fā)布該業(yè)務(wù)的所屬應(yīng)用即可；
意義：
規(guī)范項(xiàng)目，增加代碼的安全性，降低項(xiàng)目維護(hù)成本。
3.3、基礎(chǔ)組件庫(kù)的建設(shè)
這個(gè)蠻基礎(chǔ)的，對(duì)于組件庫(kù)的建設(shè)，不建議研發(fā)人員較少時(shí)去做這件事情，專(zhuān)職前端開(kāi)發(fā)人數(shù)少于10人時(shí)，建議使用比較靠譜的第三方UI庫(kù)，例如Antd，這樣性?xún)r(jià)比更高。
設(shè)計(jì)基礎(chǔ)組件庫(kù)的前提，是要求統(tǒng)一技術(shù)棧，這樣才能最大化基礎(chǔ)組件庫(kù)的效益。組件庫(kù)建議以使用以下參考標(biāo)準(zhǔn)：
- 使用ts；
- 可擴(kuò)展性強(qiáng)；
- 適用程度高；
- 文檔清楚詳細(xì)；
- 版本隔離，小版本優(yōu)化加功能，大改需要大版本更新；
- 和UI協(xié)調(diào)統(tǒng)一，要求UI交互參與進(jìn)來(lái)；
總的來(lái)說(shuō)，建設(shè)起來(lái)后，利大于弊，但是需要專(zhuān)人維護(hù)，因此還是有一定成本的。
意義：
統(tǒng)一不同/相同產(chǎn)品線(xiàn)之間的風(fēng)格，給用戶(hù)更好的體驗(yàn)，減少單次開(kāi)發(fā)中寫(xiě)UI組件時(shí)浪費(fèi)的時(shí)間和人力，提高開(kāi)發(fā)效率。
3.4、技術(shù)棧統(tǒng)一
前端有三大主流框架，還有兼容性最強(qiáng)jQuery，以及各種第三方庫(kù)，UI框架。因此項(xiàng)目需求如果復(fù)雜一些，很容易形成一個(gè)大雜燴。因此前端的技術(shù)棧必須統(tǒng)一，具體來(lái)說(shuō)，建議實(shí)現(xiàn)以下舉措：
- 三大框架選型其一，團(tuán)隊(duì)水平一般推薦Vue、水平較好推薦React，對(duì)外項(xiàng)目選React或者ng；
- 需要兼容IE8或更老版本時(shí)，建議使用jQuery；
- 組件庫(kù)自建或者統(tǒng)一選擇一個(gè)固定的第三方；
- 一些特殊第三方庫(kù)統(tǒng)一使用一個(gè)版本，例如需要使用地圖時(shí)，固定使用高德或百度或騰訊地圖；
- 基礎(chǔ)設(shè)施建設(shè)應(yīng)避免重復(fù)造輪子，所有團(tuán)隊(duì)盡量共用，并有專(zhuān)門(mén)的前端平_臺(tái)負(fù)責(zé)統(tǒng)一這些東西，對(duì)于特殊需求，可以新建，但應(yīng)當(dāng)有說(shuō)服力；
總的來(lái)說(shuō)，技術(shù)棧統(tǒng)一的好處很多，可以有效提高開(kāi)發(fā)效率，降低重復(fù)造輪子產(chǎn)生的成本。
意義：
方便招人，簡(jiǎn)化團(tuán)隊(duì)成員培養(yǎng)成本，以及提高項(xiàng)目的可持續(xù)性。
3.5、瀏覽器兼容
常見(jiàn)的問(wèn)題是IE6、7、8，以及部分小眾瀏覽器（PC和手機(jī)）產(chǎn)生的奇怪問(wèn)題。因此應(yīng)該考慮統(tǒng)一解決方案，避免bug的重復(fù)產(chǎn)生。常見(jiàn)解決方案有：
- 配置postcss，讓某些css增加兼容性前綴；
- 寫(xiě)一個(gè)wepback的loader，處理某些特殊場(chǎng)景；
- 規(guī)范團(tuán)隊(duì)代碼，使用更穩(wěn)定的寫(xiě)法（例如移動(dòng)端避免使用fixed進(jìn)行布局）；
- 對(duì)常見(jiàn)問(wèn)題、疑難問(wèn)題，總結(jié)解決方案并團(tuán)隊(duì)共享；
- 建議或引導(dǎo)用戶(hù)使用高版本瀏覽器（比如chrome）；
意義：
避免瀏覽器環(huán)境產(chǎn)生的bug，以及排查此類(lèi)bug所浪費(fèi)的大量時(shí)間。
3.6、內(nèi)容平_臺(tái)建設(shè)
為了提高公司內(nèi)部的溝通效率，總結(jié)經(jīng)驗(yàn)，以及保密原因。應(yīng)建設(shè)一個(gè)內(nèi)部論壇+博客站點(diǎn)。其具備的好處如下：
- 可以記錄公司的歷史；
- 研發(fā)同學(xué)之間分享經(jīng)驗(yàn)；
- 總結(jié)轉(zhuǎn)載一些外界比較精品的文章，提高大家的眼界；
- 增加公司內(nèi)部同學(xué)的交流，有利于公司的團(tuán)隊(duì)和文化建設(shè)；
- 對(duì)某些技術(shù)問(wèn)題可以進(jìn)行討論，減少因沒(méi)有達(dá)成共識(shí)帶來(lái)的溝通損耗；
眾所周知，大型互聯(lián)網(wǎng)公司通常都有這樣一個(gè)內(nèi)部論壇和博客站點(diǎn)。其降低了公司的溝通和交流成本，也增加了公司的技術(shù)積累。
意義：
博客增強(qiáng)技術(shù)積累，論壇增強(qiáng)公司內(nèi)部溝通能力。
3.7、權(quán)限管理平_臺(tái)
當(dāng)公司內(nèi)部人員較多時(shí)，應(yīng)有一個(gè)專(zhuān)門(mén)的平_臺(tái)，來(lái)管理、規(guī)范用戶(hù)的權(quán)限以及可訪(fǎng)問(wèn)內(nèi)容[原創(chuàng)水印-作者：零零水(王冬)，微信：qq20004604]。權(quán)限管理平_臺(tái)有幾個(gè)特點(diǎn)：
- 必然和Server端天然高耦合度，因此需要有專(zhuān)門(mén)的控制模塊負(fù)責(zé)處理權(quán)限問(wèn)題（負(fù)責(zé)Server端開(kāi)發(fā)處理，或者前端通過(guò)中間層例如Node層介入處理）；
- 自動(dòng)化流程控制，即用戶(hù)創(chuàng)建、申請(qǐng)、審批、離職自動(dòng)刪除，都應(yīng)該是由系統(tǒng)推進(jìn)并提醒相關(guān)人士，必要時(shí)應(yīng)能觸發(fā)報(bào)警；
- 權(quán)限應(yīng)有時(shí)效性，減少永久性權(quán)限的產(chǎn)生；
- 審批流程應(yīng)清晰可見(jiàn)，每一階段流程應(yīng)具體明確；
- 應(yīng)與公司流程緊密結(jié)合，并且提高可修改性，方便公司后期進(jìn)行流程優(yōu)化；
意義：
使得公司內(nèi)部流程正規(guī)化、信息化。
3.8、登錄系統(tǒng)設(shè)計(jì)（單點(diǎn)登錄）
當(dāng)公司內(nèi)部業(yè)務(wù)線(xiàn)比較復(fù)雜但相互之間的耦合度比較高時(shí)，我們應(yīng)該考慮設(shè)計(jì)添加單點(diǎn)登錄系統(tǒng)。具體來(lái)說(shuō)，用戶(hù)在一處登錄，即可以在任何頁(yè)面訪(fǎng)問(wèn)，登出時(shí)，也同樣在任何頁(yè)面都失去登錄狀態(tài)。SSO的好處很多：
- 增強(qiáng)用戶(hù)體驗(yàn)；
- 打通了不同業(yè)務(wù)系統(tǒng)之間的用戶(hù)數(shù)據(jù)；
- 方便統(tǒng)一管理用戶(hù)；
- 有利于引流；
- 降低開(kāi)發(fā)系統(tǒng)的成本（不需要每個(gè)業(yè)務(wù)都開(kāi)發(fā)一次登錄系統(tǒng)和用戶(hù)狀態(tài)控制）；
總的來(lái)說(shuō)，大中型web應(yīng)用，SSO可以帶來(lái)很多好處，缺點(diǎn)卻很少。
意義：
用戶(hù)體驗(yàn)增強(qiáng)，打通不同業(yè)務(wù)之間的間隔，降低開(kāi)發(fā)成本和用戶(hù)管理成本。
3.9、CDN
前端資源的加載速度是衡量用戶(hù)體驗(yàn)的重要指標(biāo)之一。而現(xiàn)實(shí)中，因?yàn)榉N種因素，用戶(hù)在加載頁(yè)面資源時(shí)，會(huì)受到很多限制。因此上CDN是非常有意義的，好處如下：
- 用戶(hù)來(lái)自不同地區(qū)，加入CDN可以使用戶(hù)訪(fǎng)問(wèn)資源時(shí)，訪(fǎng)問(wèn)離自己比較近的CDN服務(wù)器，降低訪(fǎng)問(wèn)延遲；
- 降低服務(wù)器帶寬使用成本；
- 支持視頻、靜態(tài)資源、大文件、小文件、直播等多種業(yè)務(wù)場(chǎng)景；
- 消除跨運(yùn)營(yíng)商造成的網(wǎng)絡(luò)速度較慢的問(wèn)題；
- 降低DDoS攻擊造成的對(duì)網(wǎng)站的影響；
CDN是一種比較成熟的技術(shù)，各大云平_臺(tái)都有提供CDN服務(wù)，價(jià)格也不貴，因此CDN的性?xún)r(jià)比很高。
意義：
增加用戶(hù)訪(fǎng)問(wèn)速度，降低網(wǎng)絡(luò)延遲，帶寬優(yōu)化，減少服務(wù)器負(fù)載，增強(qiáng)對(duì)攻擊的抵抗能力。
3.10、負(fù)載均衡
目前來(lái)看，負(fù)載均衡通常使用Nginx比較多，以前也有使用Apache。當(dāng)遇見(jiàn)大型項(xiàng)目的時(shí)候，負(fù)載均衡和分布式幾乎是必須的。負(fù)載均衡有以下好處：
- 降低單臺(tái)server的壓力，提高業(yè)務(wù)承載能力；
- 方便應(yīng)對(duì)峰值流量，擴(kuò)容方便（如舉辦某些活動(dòng)時(shí)）；
- 增強(qiáng)業(yè)務(wù)的可用性、擴(kuò)展性、穩(wěn)定性；
負(fù)載均衡已經(jīng)是蠻常見(jiàn)的技術(shù)了，好處不用多說(shuō)，很容易理解。
意義：
增強(qiáng)業(yè)務(wù)的可用性、擴(kuò)展性、穩(wěn)定性，可以支持更多用戶(hù)的訪(fǎng)問(wèn)。
3.11、多端共用一套接口
目前常見(jiàn)場(chǎng)景是一個(gè)業(yè)務(wù)，同時(shí)有PC頁(yè)面和H5頁(yè)面，由于業(yè)務(wù)是一樣的，因此應(yīng)避免同一個(gè)業(yè)務(wù)有多套接口分別適用于PC和H5端。[原創(chuàng)の水印-作者：零零水(王冬)，QQ：20004604]因此解決方案如下：
- 后端提供的接口，應(yīng)該同時(shí)包含PC和H5的數(shù)據(jù)（即單獨(dú)對(duì)一個(gè)存在亢余數(shù)據(jù)）；
- 接口應(yīng)當(dāng)穩(wěn)定，即當(dāng)業(yè)務(wù)變更時(shí)，應(yīng)盡量采取追加數(shù)據(jù)的形式；
- 只有在單獨(dú)一端需要特殊業(yè)務(wù)流程時(shí)，設(shè)計(jì)單端獨(dú)有接口；
多端共用接口，是減少開(kāi)發(fā)工作量，并且提高業(yè)務(wù)可維護(hù)性的重要解決方案。
意義：
降低開(kāi)發(fā)工作量，增強(qiáng)可維護(hù)性。
4、總結(jié)
由于各個(gè)公司具體情況不同，項(xiàng)目也具有特殊性，因此以上設(shè)計(jì)不可強(qiáng)行套入，應(yīng)根據(jù)自己公司規(guī)模、項(xiàng)目進(jìn)展、人員數(shù)量等，先添加比較重要的功能和設(shè)計(jì)。并需要考慮到長(zhǎng)期項(xiàng)目的可維護(hù)性和發(fā)展需要，對(duì)部分基礎(chǔ)設(shè)施進(jìn)行提前研發(fā)設(shè)計(jì)。
篇幅所限，因此無(wú)法面面俱到，只提了一些我認(rèn)為比較重要的架構(gòu)層面需要考慮的內(nèi)容，歡迎大家補(bǔ)充。大家如果有自己的看法，歡迎回復(fù)，或者添加我的微信 qq20004604（昵稱(chēng)：零零水）進(jìn)行討論。
最后問(wèn)一下，西安有沒(méi)有不加班，并且需要前端架構(gòu)師的公司，請(qǐng)聯(lián)系我
