微前端大賞
序
什么是微前端？微前端解決了什么問題？
要回答這個問題，我們首先要解決的是：什么是“微”。大家可能已經聽說過微服務的概念， 微服務是后端服務的一種架構模式，它想解決的問題是可用性問題、擴展性問題、耦合度問題，進而演變出“服務治理”，"服務發現"等等技術。例如：
- 通過熔斷、限流等機制保證高可用；
- 微服務之間調用的負載均衡；
- 分布式事務（2PC、3PC、TCC、LCN等）；
- 服務調用鏈跟蹤
- 配置中心
- 服務自動發現等等。
1、微服務的“微”字在於 單一職責
一個微服務應該都是單一職責的，這才是“微”的體現，一個微服務解決一個業務問題（注意是一個業務問題而不是一個接口）。
2、還有一個面向服務
將自己的業務能力封裝並對外提供服務，這是繼承SOA的核心思想，一個微服務本身也可能使用到其它微服務的能力
這兩個基礎的能力構成了微服務整個的架構體系，是圍繞服務、圍繞一個個單一的職責體系的，它將一個、多個不同業務體系內的服務連接起來合並成一個大的業務模塊，再分而治之，對每個服務做相應的技術、業務處理，合並成了一整個面向服務的業務。當服務發生故障，熔斷機制產生作用，兜底服務馬上啟用，然后調用告警服務，將信息通知給通知服務，接着通知服務負責提醒對應的人員查看並解決問題。
這一系列的操作就是微服務的“微”字所要解決的問題，它把傳統的大型項目拆分成各個不同的業務模塊，再由各種一致性組件、可用性組件把它們組合起來使用。
“微”是分治的意思，那微前端是什么呢？
歷史
后端jsp時代
JSP時代沒有太多的懸念，我依稀還記得那個年代，當我clone下后端爸爸的代碼，笨拙的在windows電腦上按照csdn的步驟安裝java的jdk，打開百度搜索“JRE和JDK的區別是什么，我有沒有裝錯”...一言難盡。總之那個年代，我們前端的代碼大多數必須經過后端同學在jsp里面的標簽處理才可以在線上使用這個時候拆分、分治的工作都集中在js，會分為很多套不同的js代碼，在script中依次引入操作的。
這個階段前端其實並不“微”，只是作為一個界面腳本標記存在的而已。
iframe時代
漸漸的ajax、jquery、require.js的出現打破了前端生態的模式，ajax使前后端分離，jquery使前端變得更加容易編寫，而AMD的模塊規范以及require.js的出現讓前端從此變得不一樣了，前端進入了模塊化的時代。
require.js是遵循AMD協議的一個前端模塊化庫
最早的時候，所有Javascript代碼都寫在一個文件里面，只要加載這一個文件就夠了。后來，代碼越來越多，一個文件不夠了，必須分成多個文件，依次加載。下面的網頁代碼，相信很多人都見過。
<script src="1.js"></script>
<script src="2.js"></script>
<script src="3.js"></script>
requireJS的寫法：
模塊代碼：
// main.js
require(['moduleA', 'moduleB', 'moduleC',function (moduleA, moduleB, moduleC){
// some code here
});
requireJS可以通過我們現在熟悉的request()，類似的寫法去引入一個模塊，在這個時候，它的理念跟iframe相結合，就有了第一個“微前端”的架構模式，當然這個時候的微前端並不很“微”。
通過一張阿里雲的控制台的圖來解釋這套架構的模式：
主應用負責框架、通信、路由、資源分配。
子應用負責實現業務。
兩者之間通過一套特定的sdk進行交互。
已經非常接近微服務的整體概念了。 通過主框架解決共性問題，拆分各個不同的微模塊、微應用解決各個單一職責的問題，這個時候每個應用是面向應用的,即應用本身只對應用本身負責，它有很多特性：
1、技術棧無關，遵循同一套通信機制即可
2、應用解偶，團隊之間通過主框架基座進行交互
3、熱更新插拔，不需要全部更新主框架，只需要更新對應的應用即可
4、可動態降級熔斷
等等特性，可以說這一時期的前端已經進入了微前端時代。當然不是所有的應用都適用於這一個龐大的開發模式，畢竟阿里雲幾十上百個不同的應用模塊是需要龐大的業務支撐的。
打包技術與SSR(服務端渲染)
然后gulp出現了，webpack出現了，angular、vue、react單頁應用都出現了。
但問題來了，我們知道我們一個單頁應用里資源是很重的。首頁的加載速度需要很大的代價去優化它。這個時候iframe會帶來比較嚴重的體驗問題。
Single-spa出現了。
一個用於前端微服務化的JavaScript前端解決方案
同樣的技術棧無關，在同一個頁面中使用多種技術框架(React, Vue, AngularJS, Angular, Ember等任意技術框架),並且不需要刷新頁面.
也同樣無需重構現有代碼，使用新的技術框架編寫代碼,現有項目中的代碼無需重構.
更好的資源控制，每個獨立模塊的代碼可做到按需加載,不浪費額外資源.
每個獨立模塊可獨立運行. 大致是這樣的：
讓我們再去盜幾張別人的圖：（圖片來自網絡，侵權通刪）
Loader:
Loader是核心模塊的加載器，可以通過loader來進行子應用的加載，目前的微前端方案設計里面一般有兩種模式。
第一種是非侵入式(iframe模式)，通過加載對應子應用的 index.html 文件，再通過對首頁html文件進行解析，獲取到子應用的js文件和css文件，進行加載。
另一種是子應用打包成一個js文件，按照規范的導出格式,主應用只加載 index.js 文件。獲取到對應的render和destroy方法。
External:
在SPA微前端中有一個需要解決的問題就是，子應用間的公共依賴，我們如何抽離項目間的公共依賴呢，由於我們將一個應用拆分成了多個子應用，那子應用之間的依賴如何復用。如果了解commonJS的同學應該知道，commonJS具備加載模塊緩存能力，加載過的模塊會將其緩存起來，那么是不是我們可以將子模塊以commonJS的規范進行打包。在加載子模塊時，提供全局的exports和require方法，將子應用導出的exports進行收集,在require時加載我們配置的external資源。
核心問題
通信，首先要解決的問題
消息總線概念
消息總線。簡單理解就是一個消息收發中心，眾多應用可以連接到總線上，應用可以往消息中心發送或接收信息（通過訂閱監聽或主動推拉）。比如：應用A發送一條消息到總線上，總線判斷應該送給應用B,應用B可以接收到信息（應用B訂閱或拉取到了應用A的消息），這樣的話，消息總線就充當一個中間者的角色，使得應用A和應用B解偶了，很方便。
在前端可使用的技術大致有：
1、通過window交互
需要注意的是domain域名的設置，比較復雜，維護成本高，不可控性高。
2、通過socket，主應用和子應用連接socket，通過服務端實現通信，一般沒有人這么用，比較復雜, 成本高。
3、通過url進行簡單的交互，大多應用采用的是由路由參數進行交互的，實現簡單且體驗較好。
4、localstorage等存儲媒介。
鑒權問題
微前端怎么樣在各個模塊之間統一權限體系？這個問題前端解決的難度不低，玩的不好容易崩潰。
一般情況下由后台爸爸，通過cookie識別，從后台接口帶出對應的權限數據在前端進行二次判斷。
污染問題
1、全局環境污染
2、事件污染
3、style污染
4、定時器污染
5、localstorage污染
解決全局環境污染和style污染
通常采用，快照模式和代理劫持,
在新的api中還可以采用shadowbox
Sandbox
有一個核心的模塊是沙盒，由於多個子應用會反復的展示在同一個容器內，子應用中會造成對當前環境的副作用，例如：全局樣式、全局變量、監聽事件、定時器等。沙盒在這里主要是為運行中的程序提供隔離環境，避免應用之間相互影響。
在應用的運行環境中做資源隔離，監聽應用的生命周期進行清理、加載操作。
小結
什么是微前端：
微前端（Micro-Frontends）是一種類似於微服務的架構，它將微服務的理念應用於瀏覽器端，即將 Web 應用由單一的單體應用轉變為多個小型前端應用聚合為一的應用。各個前端應用還可以獨立運行、獨立開發、獨立部署。微前端不是單純的前端框架或者工具，而是一套架構體系，這個概念最早在2016年底被提出，可以參考在Google上搜索Micro-Frontends, 排名靠前的https://micro-frontends.org的博客文章，提出了早期的微前端模型。
它能做什么：
1、拆分和細化
2、整合歷史系統
3、獨立構建發布
4、治理、熔斷、降級
等
相關資源
https://www.jianshu.com/p/c0f4b837dbea
https://zhuanlan.zhihu.com/p/162726399
https://zhuanlan.zhihu.com/p/141530392
下期我們可以具體實踐實踐，自己動手搭建一個基於singleSpa的微前端框架，敬請期待