建站
咨詢
售后
建站咨詢
新聞中心
微前端架構(gòu)是一種類似于微服務(wù)的架構(gòu)，它將微服務(wù)的理念應(yīng)用于瀏覽器端，即將 Web 應(yīng)用由單一的單體應(yīng)用轉(zhuǎn)變?yōu)槎鄠€(gè)小型前端應(yīng)用聚合為一的應(yīng)用。
10多年的都勻網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。營銷型網(wǎng)站建設(shè)的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整都勻建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。成都創(chuàng)新互聯(lián)從事“都勻網(wǎng)站設(shè)計(jì)”,“都勻網(wǎng)站推廣”以來，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。
由此帶來的變化是，這些前端應(yīng)用可以獨(dú)立運(yùn)行、獨(dú)立開發(fā)、獨(dú)立部署。以及，它們應(yīng)該可以在共享組件的同時(shí)進(jìn)行并行開發(fā)——這些組件可以通過 NPM 或者 Git Tag、Git Submodule 來管理。
注意：這里的前端應(yīng)用指的是前后端分離的單應(yīng)用頁面，在這基礎(chǔ)才談?wù)撐⑶岸瞬庞幸饬x。
結(jié)合我最近半年在微前端方面的實(shí)踐和研究來看，微前端架構(gòu)一般可以由以下幾種方式進(jìn)行：
- 使用 HTTP 服務(wù)器的路由來重定向多個(gè)應(yīng)用
- 在不同的框架之上設(shè)計(jì)通訊、加載機(jī)制，諸如 Mooa 和 Single-SPA
- 通過組合多個(gè)獨(dú)立應(yīng)用、組件來構(gòu)建一個(gè)單體應(yīng)用
- iFrame。使用 iFrame 及自定義消息傳遞機(jī)制
- 使用純 Web Components 構(gòu)建應(yīng)用
- 結(jié)合 Web Components 構(gòu)建
不同的方式適用于不同的使用場景，當(dāng)然也可以組合一起使用。那么，就讓我們來一一了解一下，為以后的架構(gòu)演進(jìn)做一些技術(shù)鋪墊。
基礎(chǔ)鋪墊：應(yīng)用分發(fā)路由 -> 路由分發(fā)應(yīng)用
在一個(gè)單體前端、單體后端應(yīng)用中，有一個(gè)典型的特征，即路由是由框架來分發(fā)的，框架將路由指定到對應(yīng)的組件或者內(nèi)部服務(wù)中。微服務(wù)在這個(gè)過程中做的事情是，將調(diào)用由函數(shù)調(diào)用變成了遠(yuǎn)程調(diào)用，諸如遠(yuǎn)程 HTTP 調(diào)用。而微前端呢，也是類似的，它是將應(yīng)用內(nèi)的組件調(diào)用變成了更細(xì)粒度的應(yīng)用間組件調(diào)用，即原先我們只是將路由分發(fā)到應(yīng)用的組件執(zhí)行，現(xiàn)在則需要根據(jù)路由來找到對應(yīng)的應(yīng)用，再由應(yīng)用分發(fā)到對應(yīng)的組件上。
后端：函數(shù)調(diào)用 -> 遠(yuǎn)程調(diào)用
在大多數(shù)的 CRUD 類型的 Web 應(yīng)用中，也都存在一些極為相似的模式，即：首頁 -> 列表 -> 詳情：
- 首頁，用于面向用戶展示特定的數(shù)據(jù)或頁面。這些數(shù)據(jù)通常是有限個(gè)數(shù)的，并且是多種模型的。
- 列表，即數(shù)據(jù)模型的聚合，其典型特點(diǎn)是某一類數(shù)據(jù)的集合，可以看到盡可能多的數(shù)據(jù)概要（如 Google 只返回 100 頁），典型見 Google、淘寶、京東的搜索結(jié)果頁。
- 詳情，展示一個(gè)數(shù)據(jù)的盡可能多的內(nèi)容。
如下是一個(gè) Spring 框架，用于返回首頁的示例：
- @RequestMapping(value="/")
- public ModelAndView homePage(){
- return new ModelAndView("/WEB-INF/jsp/index.jsp");
- }
對于某個(gè)詳情頁面來說，它可能是這樣的：
- @RequestMapping(value="/detail/{detailId}")
- public ModelAndView detail(HttpServletRequest request, ModelMap model){
- ....
- return new ModelAndView("/WEB-INF/jsp/detail.jsp", "detail", detail);
- }
那么，在微服務(wù)的情況下，它則會(huì)變成這樣子：
- @RequestMapping("/name")
- public String name(){
- String name = restTemplate.getForObject("http://account/name", String.class);
- return Name" + name;
- }
而后端在這個(gè)過程中，多了一個(gè)服務(wù)發(fā)現(xiàn)的服務(wù)，來管理不同微服務(wù)的關(guān)系。
前端：組件調(diào)用 -> 應(yīng)用調(diào)用
在形式上來說，單體前端框架的路由和單體后端應(yīng)用，并沒有太大的區(qū)別：依據(jù)不同的路由，來返回不同頁面的模板。
- const appRoutes: Routes = [
- { path: 'index', component: IndexComponent },
- { path: 'detail/:id', component: DetailComponent },
- ];
而當(dāng)我們將之微服務(wù)化后，則可能變成應(yīng)用 A 的路由：
- const appRoutes: Routes = [
- { path: 'index', component: IndexComponent },
- ];
外加之應(yīng)用 B 的路由：
- const appRoutes: Routes = [
- { path: 'detail/:id', component: DetailComponent },
- ];
而問題的關(guān)鍵就在于：怎么將路由分發(fā)到這些不同的應(yīng)用中去。與此同時(shí)，還要負(fù)責(zé)管理不同的前端應(yīng)用。
路由分發(fā)式微前端
路由分發(fā)式微前端，即通過路由將不同的業(yè)務(wù)分發(fā)到不同的、獨(dú)立前端應(yīng)用上。其通常可以通過 HTTP 服務(wù)器的反向代理來實(shí)現(xiàn)，又或者是應(yīng)用框架自帶的路由來解決。
就當(dāng)前而言，通過路由分發(fā)式的微前端架構(gòu)應(yīng)該是采用最多、最易采用的 “微前端” 方案。但是這種方式看上去更像是多個(gè)前端應(yīng)用的聚合，即我們只是將這些不同的前端應(yīng)用拼湊到一起，使他們看起來像是一個(gè)完整的整體。但是它們并不是，每次用戶從 A 應(yīng)用到 B 應(yīng)用的時(shí)候，往往需要刷新一下頁面。
在幾年前的一個(gè)項(xiàng)目里，我們當(dāng)時(shí)正在進(jìn)行遺留系統(tǒng)重寫。我們制定了一個(gè)遷移計(jì)劃：
- 首先，使用靜態(tài)網(wǎng)站生成動(dòng)態(tài)生成首頁
- 其次，使用 React 計(jì)劃棧重構(gòu)詳情頁
- ***，替換搜索結(jié)果頁
整個(gè)系統(tǒng)并不是一次性遷移過去，而是一步步往下進(jìn)行。因此在完成不同的步驟時(shí)，我們就需要上線這個(gè)功能，于是就需要使用 Nginx 來進(jìn)行路由分發(fā)。
如下是一個(gè)基于路由分發(fā)的 Nginx 配置示例：
- http {
- server {
- listen 80;
- server_name www.phodal.com;
- location /api/ {
- proxy_pass http://http://172.31.25.15:8000/api;
- }
- location /web/admin {
- proxy_pass http://172.31.25.29/web/admin;
- }
- location /web/notifications {
- proxy_pass http://172.31.25.27/web/notifications;
- }
- location / {
- proxy_pass /;
- }
- }
- }
在這個(gè)示例里，不同的頁面的請求被分發(fā)到不同的服務(wù)器上。
隨后，我們在別的項(xiàng)目上也使用了類似的方式，其主要原因是：跨團(tuán)隊(duì)的協(xié)作。當(dāng)團(tuán)隊(duì)達(dá)到一定規(guī)模的時(shí)候，我們不得不面對這個(gè)問題。除此，還有 Angluar 跳崖式升級的問題。于是，在這種情況下，用戶前臺使用 Angular 重寫，后臺繼續(xù)使用 Angular.js 等保持再有的技術(shù)棧。在不同的場景下，都有一些相似的技術(shù)決策。
因此在這種情況下，它適用于以下場景：
- 不同技術(shù)棧之間差異比較大，難以兼容、遷移、改造
- 項(xiàng)目不想花費(fèi)大量的時(shí)間在這個(gè)系統(tǒng)的改造上
- 現(xiàn)有的系統(tǒng)在未來將會(huì)被取代
- 系統(tǒng)功能已經(jīng)很完善，基本不會(huì)有新需求
而在滿足上面場景的情況下，如果為了更好的用戶體驗(yàn)，還可以采用 iframe 的方式來解決。
使用 iFrame 創(chuàng)建容器
iFrame 作為一個(gè)非常古老的，人人都覺得普通的技術(shù)，卻一直很管用。
HTML 內(nèi)聯(lián)框架元素