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