這個結構也是咱們項目目前正在使用的,應對兩三百個頁面的web項目是沒有任何問題的,在擴展性,多人合做方面是很是優秀的。廢話很少說,先上結構,再說爲何要這麼作。前端
├── service # 後端接口管理
│ ├── index.js # 接口管理出入口
│ └── ... # 具體的不一樣業務/服務接口文件【S-1】
├── assets # 項目依賴資源管理
│ └── imgs # 圖片資源
│ ├── style # 樣式資源
│ └── js # 依賴的第三方sdk之類的js資源
├── components # 項目組件目錄
│ ├── public # 公共組件/基礎組件(好比基礎的按鈕/輸入框等)
│ │ ├── index.js # 基礎組件的註冊文件【可選】
│ │ ├── README.md # 組件使用說明文檔【可選】
│ │ └── ... # 組件
│ └── .... # 基礎性的業務組件(有詳細說明)【C-1】
├── pages
│ ├── modules # 具體業務所歸屬的文件夾(能夠用業務名稱做爲文件夾名字)
│ │ ├── components # 業務所用到的組件
│ │ ├── views # 業務的全部頁面
│ │ ├── utils # 業務的工具集
│ │ ├── static # 業務所用到的靜態資源
│ │ ├── service # 業務的後端接口管理
│ │ ├── store # 業務所用到的狀態庫(本結構基於Vue,這裏是業務的Vuex)
│ │ └── index.js # 業務的惟一出口(包含路由與狀態庫)
│ └── .... # 其餘業務【P-1】
├── config # 項目的基礎配置
│ ├── index.js # 配置文件的出入口
│ └── ... # 具體的配置文件【C-2】
├── router # 項目的路由管理
│ ├── index.js # 路由出口
│ └── ... # 與路由有關的其餘文件【R-1】
├── store # 項目狀態庫的管理
│ ├── index.js # 項目狀態庫的出入口
│ └── ... # 具體的基礎模塊【S-2】
├── utils # 項目所用的工具集(封裝的請求,表單的驗證函數,時間格式化.....的工具)
│ ├── index.js # 工具的入口
│ └── ... # 具體的各個工具(請求封裝、正則、驗證......)【U-1】
├── main.js
├── App.vue
複製代碼
首先,這個結構是基於Vue來設計的,設計思路來源於小程序分包加載機制。示例的結構主要爲src
目錄下。vue
雖然給出的結構是基於Vue,可是其餘像小程序,React等也是可使用的,核心思想都是將具體的一個一個的業務做爲一個獨立模塊的,而後將一個一個的模塊組成一整個項目。nginx
接下來對標註的序號作下說明web
S-1:小程序
s-1部分的接口管理,主要用來存放項目的基礎接口,例如數據埋點等,不影響具體業務功能使用的接口後端
若是這類的接口數量很是大,能夠根據不一樣的類型劃分或者根據所屬的服務劃分(咱們的項目後端是微服務架構,前端接口根據服務劃分的)爲多個文件,而後將其導出;再在index.js
中將不一樣類型的接口文件導入後作總體導出。瀏覽器
若是這類接口數量並不大,則能夠直接在index.js
中進行管理導出。bash
若是說再可預見的範圍內這類接口不會變多,甚至能夠徹底不要service
文件夾,將index.js
命名爲service.js
放在根目錄(src
)下架構
C-1:框架
components
中僅存放公共/基礎組件,那能夠直接將public
中的文件放在components
下,去掉pubilc
文件夾P-1:
modules
爲每個具體的業務,擁有獨立的路由,獨立的狀態庫,獨立的工具庫... modules
的目的就是將一個業務做爲一個總體封閉起來,只留一個對外的出口index.js
,如此,當公司有一個同類型的項目出現一樣的業務,能夠很是方便的進行遷移。
static
存放靜態資源,utils
存放工具集,若是你的業務靜態資源只有很少的一些圖片,工具集只有一兩個文件,徹底能夠將兩個文件夾保留一個便可。
store
是業務的狀態庫,基於 Vuex
的 module
設計,內部能夠根據須要再自行劃分,但終都須要進行導出。
index.js
是業務惟一的對外出口,凡是須要供外部使用的(業務頁面的路由,業務的狀態庫)文件,到須要導入至index.js
後再來作總體導出。
C-2:
config
是一個可選的配置,主要用來存放項目相關的配置。R-1:
src
下,刪除router
文件夾S-2:
store
中放的是基礎的、不影響業務使用的、無耦合數據,以及store
對外提供的出口文件index.js
及將各業務對外暴露的store導入進來,處理以後再作總體導出。U-1:
utils
下也就是基礎性的工具集,例如封裝的請求等結構的功能說明也就這些。
爲何要這麼設計呢,最大的緣由仍是解耦和提升複用性,於我所在公司而言,咱們有多個類似的管理系統,可能有部分業務在這個系統上有,其餘系統上產品說也要上這個功能,那根據這個結構,我就能夠直接將對應的功能模塊複製到另外一個系統中去,而後將業務暴露的出口接入到另外一個系統中,直接就能夠完成功能的遷移。
上面的結構是咱們項目正在使用的,hold住兩三百各頁面的項目仍是比較輕鬆的,但項目在可預期的範圍內正在往更大型進化,難保上面的結構還能繼續支撐。因此咱們須要探尋更合理的架構來支撐咱們的項目,計劃引入微前端的概念。
微前端的概念來源於後端微服務架構,對於一個超大型的項目,直接管理是確定不方便的。因此咱們能夠將一個超大型項目根據業務來拆分紅多個小項目,將每個小項目交給不一樣團隊去開發,不依賴具體的技術棧,最終將這些小項目組成一個完整系統。這就是微前端。
項目管理方便,這是確定的,將一個大型項目層層拆分,不一樣團隊開發不一樣業務,各團隊自行管理,相對直接去管理一整個大型項目更方便。
不依賴特有的技術棧, 微服務化的前端,每個項目均可以根據開發團隊的習慣來使用他們更熟悉的技術棧。
解耦, 微前端後,各個項目的耦合性更低,業務間的影響會更小。
增量升級, 不管是改bug,仍是升級迭代,咱們只須要在對應的業務中去改,改完以後獨立發版,哪怕出現重大事故,只須要屏蔽對應業務便可,不會形成整個項目崩塌。
獨立部署
相對於拆分而言,如何將完成後的各個小項目組合成一個總體,這部分就不太容易了,但這部分更加劇要。
iframe, 第一種集成思路是使用iframe
來集成,在iframe
中加載不一樣的項目包。
nginx, 第二種思路是經過nginx 配置代理,將不一樣的路由經過nginx 轉發到不一樣的項目。
前兩種是最容易想到的集成方案,各有優缺點,也各有不一樣的適用場景。
雲上打包編譯, 這個思路來源於Jenkins ,每一個項目向外暴露一個配置文件,告訴打包系統須要如何打包加載。
本地打包雲上集成, 集本地打包完成後,將配置文件和打包後的文件上傳雲上,打包系統根據根據配置文件來決定須要捨棄那些文件,如何加載文件。
上面這兩種集成方式,目前只是一個實現思路,可能還須要主系統或者各業務項目提供一些對外變量,告訴瀏覽器各業務須要渲染在什麼位置。
微前端以後確定是大型項目架構的首選,遺憾的是目前並無開源的微前端解決框架/方案,因此若是你的項目須要使用微前端來解決問題,在目前階段。可能須要你們一塊兒來踩坑了,諸君共踩!!