如何設計微前端架構
就當前而言，要設計出一個微前端應用不是一件容易的事——還沒有最佳實踐。在不同的落地案例裏，使用的都是不同的方案。出現這種情況的主要原因是，每個項目所面臨的情況、所使用的技術都不盡相同。爲此，我們需要了解一些基礎的微前端模式。
架構模式
微前端應用間的關係來看，分爲兩種：基座模式（管理式）、自組織式。分別也對應了兩者不同的架構模式：
基座模式（管理式）
通過一個主應用，來管理其它應用。設計難度小，方便實踐，但是通用度低。
自組織模式
應用之間是平等的，不存在相互管理的模式。設計難度大，不方便實施，但是通用度高。
通過上面兩個對比， 基座模式實施起來比較方便，方案上便也是蠻多的。
而不論種方式,都需要提供一個查找應用的機制，在微前端中稱爲服務的
註冊表模式。和微服務架構相似，不論是哪種微前端方式，也都需要有一個應用註冊表的服務，它可以是一個固定值的配置文件，如 JSON 文件，又或者是一個可動態更新的配置，又或者是一種動態的服務。它主要做這麼一些內容
a)應用發現:讓主應用可以尋找到其它應用
b)應用註冊:即提供新的微前端應用，嚮應用註冊表註冊的功能
c)第三方應用註冊:即讓第三方應用，可以接入到系統中
d)訪問權限等相關配置
應用在部署的時候，便可以在註冊表服務中註冊。如果是基於註冊表來管理應用，那麼使用基座模式來開發比較方便
設計理念
中心化：應用註冊表,這個應用註冊表擁有每個應用及對應的入口。在前端領域裏，入口的直接表現形式可以是路由，又或者對應的應用映射
標識化應用:我們需要一個標識符來標識不同的應用，以便於在安裝、卸載的時候，能尋找到指定的應用。一個簡單的模式，就是通過康威定律來命名應用
應用生命週期管理
高內聚，低耦合
生命週期
前端微架構與後端微架構的最大不同之處，也在於此——生命週期。微前端應用作爲一個客戶端應用，每個應用都擁有自己的生命週期：
Load:決定加載哪個應用，並綁定生命週期
bootstrap：獲取靜態資源
Mount：安裝應用，如創建 DOM 節點
Unload：刪除應用的生命週期
Unmount：卸載應用，如刪除 DOM 節點、取消事件綁定
這部分的內容事實上，也就是微前端的一個難點所在，如何以合適的方式來加載應用——畢竟每個前端框架都各自不同，其所需要的加載方式也是不同的。當我們決定支持多個框架的時候，便需要在這一部分進入更細緻的研究。
如何去拆分應用
技術方式
路由分發式:通過 HTTP 服務器的反向代理功能，來將請求路由到對應的應用上。
前端微服務化:在不同的框架之上設計通訊、加載機制，以在一個頁面內加載對應的應用。
微應用:通過軟件工程的方式，在部署構建環境中，組合多個獨立應用成一個單體應用。
微件化:開發一個新的構建系統，將部分業務功能構建成一個獨立的 chunk 代碼，使用時只需要遠程加載即可。
前端容器化:通過將 iFrame 作爲容器，來容納其它前端應用。
應用組件化:藉助於 Web Components 技術，來構建跨框架的前端應用。
實施的方式雖然多，但是都是依據場景而採用的。有些場景下，可能沒有合適的方式；有些場景下，則可以同時使用多種方案。
路由分發式
路由分發式微前端，即通過路由將不同的業務分發到不同的、獨立前端應用上。**其通常可以通過 HTTP 服務器的反向代理來實現，又或者是應用框架自帶的路由來解決
路由分發式的架構應該是採用最多、最容易的 “微前端” 方案
前端微服務化
前端微服務化，是微服務架構在前端的實施，每個前端應用都是完全獨立（技術棧、開發、部署、構建獨立）、自主運行的，最後通過模塊化的方式組合出完整的前端應用.
採用這種方式意味着，一個頁面上同時存在二個及以上的前端應用在運行。而路由分發式方案，則是一個頁面只有唯一一個應用。
組合式集成：微應用化
微應用化，即在開發時，應用都是以單一、微小應用的形式存在，而在運行時，則通過構建系統合併這些應用，組合成一個新的應用。
微應用化更多的是以軟件工程的方式，來完成前端應用的開發，因此又可以稱之爲組合式集成。對於一個大型的前端應用來說，採用的架構方式，往往會是通過業務作爲主目錄，而後在業務目錄中放置相關的組件，同時擁有一些通用的共享模板。
微件化
微件（widget），指的是一段可以直接嵌入在應用上運行的代碼，它由開發人員預先編譯好，在加載時不需要再做任何修改或者編譯。**而微前端下的微件化則指的是，每個業務團隊編寫自己的業務代碼，並將編譯好的代碼部署（上傳或者放置）到指定的服務器上，在運行時，我們只需要加載相應的業務模塊即可。對應的，在更新代碼的時候，我們只需要更新對應的模塊即可。
在非單面應用時代，要實現微件化方案，是一件特別容易的事。從遠程加載來對應的 JavaScript 代碼，在瀏覽器上執行，生成對應的組件嵌入到頁面的相應部分。對於業務組件也是類似的，提前編寫好我們的業務組件，當需要對應的組件時再響應、執行。
前端容器化之 iframe
iframe 作爲一個非常 “古老” 的，人人都覺得普通的技術，卻一直很管用。它能有效地將另一個網頁/單頁面應用嵌入到當前頁面中，兩個頁面間的 CSS 和 JavaScript 是相互隔離的——除去 iframe 父子通信部分的代碼，它們之間的代碼是完全不相互干擾的。iframe 便相當於是創建了一個全新的獨立的宿主環境，類似於沙箱隔離，它意味着前端應用之間可以相互獨立運行
前端容器化之 Web Components
Web Components 是一套不同的技術，允許開發者創建可重用的定製元素（它們的功能封裝在代碼之外），並且在 web 應用中使用它們
目前困擾 Web Components 技術推廣的主要因素，在於瀏覽器的支持程度。在 Chrome 和 Opera 瀏覽器上，對於 Web Components 支持良好，而對於 Safari、IE、Firefox 瀏覽器的支持程度，並沒有那麼理想。
應用微化架構
應用微化架構，是一種開發時整體，構建時拆分，運行時分離的前端架構模式。即應用微化架構從一份代碼中，構建出適用於不同環境的多套目標代碼。
- 構建時拆分架構
- 代碼刪除架構:以刪代碼的方式，來形成每個前端應用。
- 微前端準備式架構:即，隨時可以拆分爲多個前端應用。
由於它與微應用化的相似性，我們將它與微應用化做一個對比。它與微應用化不同的是，應用微化是在構建時對應用進行拆分，而非在本地模式下對應用拆分。相似的是，它也是基於構建系統的應用拆分方式。由於它與微應用化的相似性，我們將它與微應用化做一個對比。它與微應用化不同的是，應用微化是在構建時對應用進行拆分，而非在本地模式下對應用拆分。相似的是，它也是基於構建系統的應用拆分方式。
微應用化，是一個隨時可合併式架構。而應用微化，則是一個隨時可拆分式架構。
它不僅僅是一個適合於前端的架構模式，也是一適用於後端的架構模式
整潔前端架構
Clean Architecture 是由 Robert C. Martin 在 2012 年提出的架構模式。它具有這麼一些特點：框架無關性、可被測試、UI 無關性、數據庫無關性、外部機構（agency）無關性。
對於前端架構來說，Clean Architecure 實際上是：Clean Architecture + MVP + 組件化。
這種架構模式特別適合於：組織內即寫前端又同後端的團隊。它易於映射前後端 API，且可以使用 usecase 作爲防腐層。
不得不提及的是，對於小規模的團隊來說，它帶來的弊端可能會遠遠大於好處——帶來大量冗餘的代碼。儘管通過 Angular Schematics 可以通過參數來生成代碼，但是這種分層架構地於簡單的應用來說，還是過於複雜、難以上手。對於不寫測試的項目來說 ，usecase 也不能帶來它們所承諾的好處。