亚洲内射片,影音先锋色资源站,亚洲熟女性爱视频,国产亲子伦一级A片,男人天堂网2024,性爱视频网站免费,www.夜夜嗨,国产操逼在线看

石墨文檔點(diǎn)擊藍(lán)字

關(guān)注我們

#178#

引言

“空間分離帶來的協(xié)作問題”＆“時(shí)間延續(xù)帶來的升級(jí)維護(hù)負(fù)擔(dān)”，是在一個(gè)規(guī)?？捎^的或年齡超過 3 年的B端系統(tǒng)都會(huì)存在的問題。

01 場(chǎng)景思考和大廠方案
02 SPA、MPA、MicroFrontend
03 微前端架構(gòu)解決了什么？
04 微前端的應(yīng)用主戰(zhàn)場(chǎng)
05 產(chǎn)品視角

場(chǎng)景思考和大廠方案

1、場(chǎng)景思考

思考兩個(gè)場(chǎng)景：

1、你新入職一家公司，老板扔給你一個(gè) 5 年陳的系統(tǒng)，需要你在這個(gè)項(xiàng)目上持續(xù)迭代加功能。

2、你們起了一個(gè)新系統(tǒng)，只給了一個(gè)要求："如何確保這套系統(tǒng)在 3~5 年內(nèi)還葆有生命力，不會(huì)在 3、5 年后變成又一個(gè)遺產(chǎn)項(xiàng)目？"

在產(chǎn)品圈混過的都知道，別說 3、5年了，有幾個(gè)人敢保證自己的系統(tǒng)在一年后把所有依賴包升級(jí)到最新，還能跑起來？

2、大廠方案

傳統(tǒng)的云控制臺(tái)應(yīng)用，幾乎都會(huì)面臨業(yè)務(wù)快速發(fā)展之后，單體應(yīng)用進(jìn)化成巨石應(yīng)用的問題。

為了解決產(chǎn)品研發(fā)之間各種耦合的問題，大部分企業(yè)也都會(huì)有自己的解決方案。國(guó)內(nèi)外幾個(gè)著名的云產(chǎn)品控制臺(tái)，是這樣解決的：

關(guān)于MPA、SAP等可見下文介紹

MPA 方案的優(yōu)點(diǎn)在于部署簡(jiǎn)單、各應(yīng)用之間硬隔離，天生具備技術(shù)棧無關(guān)、獨(dú)立開發(fā)、獨(dú)立部署的特性。

缺點(diǎn)則也很明顯，應(yīng)用之間切換會(huì)造成瀏覽器重刷，由于產(chǎn)品域名之間相互跳轉(zhuǎn)，流程體驗(yàn)上會(huì)存在斷點(diǎn)。

SPA 則天生具備體驗(yàn)上的優(yōu)勢(shì)，應(yīng)用直接無刷新切換，能極大的保證多產(chǎn)品之間流程操作串聯(lián)時(shí)的流程性。

缺點(diǎn)則在于各應(yīng)用技術(shù)棧之間是強(qiáng)耦合的。

那我們有沒有可能將 MPA 和 SPA 兩者的優(yōu)勢(shì)結(jié)合起來，構(gòu)建出一個(gè)相對(duì)完善的微前端架構(gòu)方案呢？

SPA、MPA、MicroFrontend

1、SPA，單頁面應(yīng)用

SPA是前單頁Web應(yīng)用的意思，（single page web application，SPA），就是只有一張Web頁面的應(yīng)用，是加載單個(gè)HTML 頁面并在用戶與應(yīng)用程序交互時(shí)動(dòng)態(tài)更新該頁面的Web應(yīng)用程序。

SPA做為各種解決方案的基礎(chǔ)，天生具備體驗(yàn)上的優(yōu)勢(shì)，應(yīng)用直接無刷新切換，能極大的保證多產(chǎn)品之間流程操作串聯(lián)時(shí)的流程性。

缺點(diǎn)則在于各應(yīng)用技術(shù)棧之間是強(qiáng)耦合的。

隨著一個(gè)項(xiàng)目需求變得越來越多，項(xiàng)目體積變得越來越大得時(shí)候，單頁面應(yīng)用得弊端也漸漸得暴漏出來，最大直觀問題就是文件加載過大導(dǎo)致頁面性能下降。

關(guān)于網(wǎng)頁加載速度，可以閱讀文章App和Web分別的加載原理＆加載方案設(shè)計(jì)（4千字）

或參考書籍《后端產(chǎn)品經(jīng)理寶典》第二章內(nèi)容：

那么如何可以更好得解決這個(gè)問題，是不是可以從業(yè)務(wù)上進(jìn)行拆分呢，各個(gè)模塊單獨(dú)使用各自得html呢，于是有了MPA（多頁面應(yīng)用）。

2、MPA，多頁面應(yīng)用

多頁面應(yīng)用（MPA，MultiPage Application），即每一次頁面跳轉(zhuǎn)的時(shí)候,后臺(tái)的服務(wù)器都會(huì)給我們返回一個(gè)新的HTML文檔,這種類型的網(wǎng)站就是多頁面網(wǎng)站,或者稱之為多頁面應(yīng)用。

通過webpack控制入口文件，打包出來多個(gè)最終文件同時(shí)提供多個(gè)html，可以實(shí)現(xiàn)模塊之間項(xiàng)目獨(dú)立從而達(dá)到解耦得目的，達(dá)到了我們得目的。

但是也隨之帶來了一些弊端，MPA路由基于文檔跳轉(zhuǎn)，每一次跳轉(zhuǎn)帶來得負(fù)擔(dān)就是需要重新加載。

公共資源文件，性能上對(duì)比SPA大大降低，切合到實(shí)際開發(fā)中當(dāng)項(xiàng)目太大多個(gè)部門共同開發(fā)時(shí)，所有人共同開發(fā)一個(gè)獨(dú)立工程，一旦一個(gè)模塊代碼出現(xiàn)問題會(huì)影響到整個(gè)前端工程，線上發(fā)布同樣會(huì)遇到同樣得問題，一個(gè)模塊會(huì)影響整個(gè)工程。

如何避免呢，答案就是微前端解決方案。

3、MicroFrontend，微前端

先來看看微服務(wù)。微服務(wù)將單體服務(wù)拆分成多個(gè)服務(wù)如圖：

多個(gè)服務(wù)相互獨(dú)立，通過聚合層對(duì)外暴露公共端口，每個(gè)服務(wù)實(shí)現(xiàn)獨(dú)立部署，那么前端是不是也可以這么做呢，于是微前端就誕生了。

微前端（Micro-Frontends）是一種類似于微服務(wù)的架構(gòu)，它將微服務(wù)的理念應(yīng)用于瀏覽器端，即將 Web 應(yīng)用由單一的單體應(yīng)用轉(zhuǎn)變?yōu)槎鄠€(gè)小型前端應(yīng)用聚合為一的應(yīng)用。

各個(gè)前端應(yīng)用還可以獨(dú)立運(yùn)行、獨(dú)立開發(fā)、獨(dú)立部署。

微前端不是單純的前端框架或者工具，而是一套架構(gòu)體系，這個(gè)概念最早在2016年底被提出。

微前端架構(gòu)解決了什么？

1、SPA與MPA解決不了的問題

微前端架構(gòu)解決了哪些SPA與MPA解決不了的問題呢？

1）對(duì)前端拆分解決了MPA的資源重新加載的問題；

2）解決了SPA體積過大的問題；

3）解決開發(fā)過程中各個(gè)模塊相互影響的問題，達(dá)到了模塊獨(dú)立開發(fā)。

整體結(jié)構(gòu)如圖：

2、上帝的歸上帝：輕量的基座

IT的很多解決思路是：Give back to Ceasar what is Ceasar's and to God what is God's（——《圣經(jīng)·新約》）

我們只需要在主系統(tǒng)構(gòu)造一個(gè)足夠輕量的基座，然后讓各子應(yīng)用按照共同的協(xié)議去實(shí)現(xiàn)即可。

這個(gè)協(xié)議可以包括，主應(yīng)用應(yīng)該如何加載子應(yīng)用，以及子應(yīng)用如何被主應(yīng)用感知、調(diào)度，應(yīng)用之間如何通信等。

這個(gè)協(xié)議不應(yīng)該包括，子應(yīng)用要如何確保隔離性、安全性，也就是子應(yīng)用除了實(shí)現(xiàn)一些較為簡(jiǎn)單的協(xié)議之外，跟開發(fā)一個(gè)正常的 spa 應(yīng)用應(yīng)該沒有任何差別，包括不應(yīng)該有開發(fā)、構(gòu)建、發(fā)布等流程上的侵入。

只要子應(yīng)用實(shí)現(xiàn)了這幾個(gè)協(xié)議，其他的東西怎么玩，我們都不需要關(guān)心或干預(yù)。

這樣的話，其實(shí)整個(gè)系統(tǒng)就變成了一個(gè)真正的、基于運(yùn)行時(shí)的插件平臺(tái)了。

微前端架構(gòu)旨在解決單體應(yīng)用在一個(gè)相對(duì)長(zhǎng)的時(shí)間跨度下，由于參與的人員、團(tuán)隊(duì)的增多、變遷，從一個(gè)普通應(yīng)用演變成一個(gè)巨石應(yīng)用(Frontend Monolith)后，隨之而來的應(yīng)用不可維護(hù)的問題。這類問題在企業(yè)級(jí) Web 應(yīng)用中尤其常見。

微前端的應(yīng)用主戰(zhàn)場(chǎng)

1、ToB 軟件服務(wù)

統(tǒng)計(jì)一下業(yè)界關(guān)于”微前端“發(fā)過聲的公司，會(huì)發(fā)現(xiàn)使用微前端的公司，基本上都是做 ToB 軟件服務(wù)的，沒有哪家 ToC 公司會(huì)有微前端的訴求（有也是內(nèi)部的中后臺(tái)系統(tǒng)），為什么會(huì)這樣？

很簡(jiǎn)單，因?yàn)楹苌儆?ToC 軟件活得過 3 年以上的。

而對(duì)于 ToB 應(yīng)用而言，3~5 年太常見了！

對(duì)很多做 ToB 領(lǐng)域的中小企業(yè)而言，這樣的系統(tǒng)可能是他們安身立命之本，不是能說扔就扔的，他們承擔(dān)不了那么高的試錯(cuò)成本。

阿里云最早的那些產(chǎn)品的控制臺(tái)，去看看那些電信軟件、銀行軟件，哪個(gè)不是 10 年+ 的壽命？

大部分企業(yè)應(yīng)用都會(huì)有一個(gè)核心的訴求，就是如何確保我的遺產(chǎn)代碼能平滑的遷移，以及如何確保我在若干年后還能用上時(shí)下熱門的技術(shù)棧？

1）溝通效率衡量；

2）原型改動(dòng)范圍衡量；

3）部門工作流程衡量。

衡量權(quán)重占比：從解決問題看，1）和2）最高。從長(zhǎng)期看，3）很重要。

2、云產(chǎn)品

云產(chǎn)品對(duì)于微前端的訴求是基本相同的，包括背后的管控、編碼能力等。

我們需要清楚一件事，并不是只有云產(chǎn)品才需要微前端，也并不是所有采用微前端方案的公司都是做云產(chǎn)品的。

微前端的初衷應(yīng)該還是來解決工程問題的，帶來的產(chǎn)品價(jià)值在不同的領(lǐng)域可大可小。

比如在阿里云這種典型的云產(chǎn)品控制臺(tái)的場(chǎng)景下，它帶來的產(chǎn)品價(jià)值就會(huì)很可觀。

因?yàn)榘⒗镌谱鳛樘峁?IAAS 服務(wù)的云平臺(tái)，它需要的就是平臺(tái)、產(chǎn)品的被集成能力，在這種場(chǎng)景下，微前端能力能非常好的契合這個(gè)訴求。

但需要強(qiáng)調(diào)的是，并不是所有采用微前端的客戶，都是阿里云這種 IAAS 平臺(tái)產(chǎn)品。

很多中小型控制臺(tái)大多沒有產(chǎn)品自由組合能力的訴求。產(chǎn)品能力只能算是微前端的能力的一種延伸。

產(chǎn)品視角

1、什么情況下使用微前端

當(dāng)我們的系統(tǒng)中有多個(gè)不同的子模塊,并且子模塊之間有相對(duì)獨(dú)立且完整的功能體系時(shí), 一旦子模塊變得越來越多, 那么整個(gè)應(yīng)用將變得非常龐大且臃腫,開發(fā)和維護(hù)成本大大提高。

如果在這種場(chǎng)景下我們采用SPA模式開發(fā),那么項(xiàng)目后期將變得不可想象,頁面首次加載將變得非常慢（可能會(huì)遇到這種情況，開發(fā)一個(gè)復(fù)雜系統(tǒng)，頁面首次加載花了20多秒,所以不得不采用MPA來處理）。

我們采用MPA(多頁應(yīng)用)模式,雖然解決了應(yīng)用臃腫的問題, 但仍然存在很多有待處理問題,比如模塊切換需要重新刷新頁面, 公共組件無法共享,子模塊直接,父子模塊之間的通信問題,開發(fā)部署繁瑣等.這寫都是傳統(tǒng)開發(fā)模式會(huì)遇到的問題.

這時(shí)候可以考慮使用微前端架構(gòu)：可以讓我們?cè)谥鲬?yīng)用中共享公共組件和狀態(tài)(但是要保證子應(yīng)用運(yùn)行時(shí)內(nèi)部的狀態(tài)隔離), 并且不同子模塊之間可以單獨(dú)開發(fā)部署, 模塊間切換不刷新頁面, 并且模塊之間,父子應(yīng)用之間可以通過某種簡(jiǎn)單的方式實(shí)現(xiàn)通信。

2、微前端架構(gòu)下的用戶體驗(yàn)

對(duì)于用戶來講，和之前訪問網(wǎng)站時(shí)的體驗(yàn)一致，沒有響應(yīng)速度（資源加載、應(yīng)用響應(yīng)等）上面的區(qū)別。

各應(yīng)用之間的通信方便，可互相調(diào)用各應(yīng)用所提供的數(shù)據(jù)接口以及組件接口等。但同時(shí)也不會(huì)帶來項(xiàng)目之間的相互影響。

如下圖，統(tǒng)一入口和鑒權(quán)，統(tǒng)一基座。用戶各自登錄自己權(quán)限下的子系統(tǒng)。

3、系統(tǒng)本身

微前端帶來各種業(yè)務(wù)提升、產(chǎn)品提升的價(jià)值。

比如產(chǎn)品的自由組合能力，比如以 widget 這種可視化方式直接輸出產(chǎn)品的能力等等。

效率問題。微前端首先解決的，是如何解構(gòu)巨石應(yīng)用，從而解決巨石應(yīng)用隨著技術(shù)更迭、產(chǎn)品升級(jí)、人員流動(dòng)帶來的工程上的問題。

解構(gòu)之后還需要再重組，重組的過程中我們就會(huì)碰到各種隔離性、依賴去重、通信、應(yīng)用編排等問題。在解決了這些問題之后，才是產(chǎn)品的自由組合、輸出等能力。

同時(shí)由于有了前者能力的鋪墊和加持，這些產(chǎn)品上的價(jià)值提升也就變得很自然和容易。

4、團(tuán)隊(duì)和技術(shù)棧

做到代碼的時(shí)代和次元隔離并且擁有良好的用戶體驗(yàn)，是微前端的核心：隨著時(shí)間的推移，團(tuán)隊(duì)人員的流動(dòng)，會(huì)慢慢發(fā)現(xiàn)一些事情：比如原維護(hù)團(tuán)隊(duì)看舊系統(tǒng)代碼，就像在看原始人用原始的姿勢(shì)拉著原始的屎。微前端的理想狀態(tài)也許就是用最爽的姿勢(shì)寫最新的業(yè)務(wù)模塊。

微前端的意義就是將這些龐大應(yīng)用進(jìn)行拆分，并隨之解耦，每個(gè)部分可以單獨(dú)進(jìn)行維護(hù)和部署，提升效率。

（完）

參考文章:

https://martinfowler.com/articles/micro-frontends.html

https://micro-frontends.org/

往期回顧

"SaaS+中臺(tái)"的思想：企業(yè)服務(wù)是永恒的?。ǜ劫Y料）
十大領(lǐng)域 159個(gè)“思維工具” （全文9.7K字收
精選：收藏118篇干貨文章，分類合集！

B端產(chǎn)品視角的 【微前端】 架構(gòu)

B端產(chǎn)品視角的【微前端】架構(gòu)