一、簡介
為了解決龐大的一整塊後端服務帶來的變更與擴充方面的限制，出現了微服務架構（Microservices）：
微服務是面向服務架構（SOA）的一種變體，把應用程式設計成一系列松耦合的細粒度服務，并通過輕量級的通信協定組織起來
具體地，将應用建構成一組小型服務。這些服務都能夠獨立部署、獨立擴充，每個服務都具有穩固的子產品邊界，甚至允許使用不同的程式設計語言來編寫不同服務，也可以由不同的團隊來管理
然而，越來越重的前端工程也面臨同樣的問題，自然地想到了将微服務思想應用（照搬）到前端，于是有了「微前端（micro-frontends）」的概念：
Micro frontends, An architectural style where independently deliverable frontend applications are composed into a greater whole.
即，一種由獨立傳遞的多個前端應用組成整體的架構風格。具體的，将前端應用分解成一些更小、更簡單的能夠獨立開發、測試、部署的小塊，而在使用者看來仍然是内聚的單個産品：
Decomposing frontend monoliths into smaller, simpler chunks that can be developed, tested and deployed independently, while still appearing to customers as a single cohesive product.
二、特點
簡單來講，微前端的理念類似于微服務：
In short, micro frontends are all about slicing up big and scary things into smaller, more manageable pieces, and then being explicit about the dependencies between them.
将龐大的整體拆成可控的小塊，并明确它們之間的依賴關系。關鍵優勢在于：
- 代碼庫更小，更内聚、可維護性更高
- 松耦合、自治的團隊可擴充性更好
- 漸進地更新、更新甚至重寫部分前端功能成為了可能
1、簡單、松耦合的代碼庫
比起一整塊的前端代碼庫，微前端架構下的代碼庫傾向于更小/簡單、更容易開發
此外，更重要的是避免子產品間不合理的隐式耦合造成的複雜度上升。通過界定清晰的應用邊界來降低意外耦合的可能性，增加子應用間邏輯耦合的成本，促使開發者明确資料和事件在應用程式中的流向
2、增量更新
理想的代碼自然是子產品清晰、依賴明确、易于擴充、便于維護的……然而，實踐中出于各式各樣的原因：
- 曆史項目，祖傳代碼
- 傳遞壓力，當時求快
- 就近就熟，當時求穩……
總存在一些不那麼理想的代碼：
- 技術棧落後，甚至強行混用多種技術棧
- 耦合混亂，不敢動，牽一發何止動全身
- 重構不徹底，重構-爛尾，換個姿勢重構-又爛尾……
而要對這些代碼進行徹底重構的話，最大的問題是很難有充裕的資源去大刀闊斧地一步到位，在逐漸重構的同時，既要確定中間版本能夠平滑過渡，同時還要持續傳遞新特性：
In order to avoid the perils of a full rewrite, we'd much prefer to strangle the old application piece by piece, and in the meantime continue to deliver new features to our customers without being weighed down by the monolith.
是以，為了實施漸進式重構，我們需要一種增量更新的能力，先讓新舊代碼和諧共存，再逐漸轉化舊代碼，直到整個重構完成
這種增量更新的能力意味着我們能夠對産品功能進行低風險的局部替換，包括更新依賴項、更替架構、UI 改版等。
另一方面，也帶來了技術選型上的靈活性，有助于新技術、新互動模式的實驗性試錯
3、獨立部署
獨立部署的能力在微前端體系中至關重要，能夠縮小變更範圍，進而降低相關風險。
是以，每個微前端都應具備有自己的持續傳遞流水線（包括建構、測試并部署到生産環境），并且要能獨立部署，不必過多考慮其它代碼庫和傳遞流水線的目前狀态：
就算舊的系統是按固定周期季度釋出或手動釋出的，甚至隔壁團隊誤釋出了一個半成品或有問題的特性也無關緊要。也就是說，如果一個微前端已經準備好釋出了，它就應該随時可釋出，并且隻由開發維護它的團隊來定
4、團隊自治
除代碼庫及釋出周期上的解耦之外，微前端還有助于形成完全獨立的團隊，由不同團隊各自負責一塊産品功能從構思到釋出的整個過程，團隊能夠完全擁有為客戶提供價值所需的一切，進而快速高效地運轉
為此，應該圍繞業務功能縱向組建團隊，而不是基于技術職能劃分。最簡單的，可以根據最終使用者所能看到的内容來劃分，比如将應用中的每個頁面作為一個微前端，并交給一個團隊全權負責。與基于技術職能或橫向關注點（如樣式、表單、校驗等）組織的團隊相比，這種方式能夠提升團隊工作的凝聚力
