项目很大，是否忍一下？

微” 字的理解：“巨石应用”、“超大型工程”（半个小时编译、半小时启动那种，服务拆分）

简单概括满足开发时粒度的拆分、部署与应用的无关性（如：子应用的部署迁移不影响上层使用）、一致性的通信接入标准（框架）。最终因量级的爆发式增长，打的补丁处理（注册、发现、监控和追踪） 也就是说微前端、微服务，这个微字的共性就是工程化项目的粒度拆分，实现类似网关层，保证了最终应用和部署之间可以缓冲，至于应用、服务本质上两者处理的粒度细化后的诉求有所不同，因此演化出了自己的方言要求。

微前端是一种前端开发的架构方法，已经变得越来越流行，这也预示着它很可能代表 Web 开发的未来。所以学习这种架构带来的好处对你的应用程序和开发团队是不言而喻的。

为什么要用微前端？

大的应用体量维护成本是很高的，拆分成单独的模块，由主应用处理登录等通用逻辑，子应用来只负责模块的业务实现，这样不管资源加载、按需加载、人员维护成本降低、增量升级、独立部署都有很好的体检提升。

• 不同团队间开发同一个应用技术栈不同

• 希望每个团队都可以独立开发，独立部署

• 项目中还有很多老的应用代码

我们可以将一个应该划分成若干个子应用，将子应用打包成一个个的 lib, 当路径切换时加载不同的子应用。这样每一个子应用都是独立的，技术栈也不用做限制，从而解决前端协同开发的问题

什么是微前端？

Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently. -- Micro Frontends

微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。

微前端架构是一种前端架构模式，旨在将一个大型的 Web 应用程序拆分为更小、更独立的部分，每个部分可以由不同的团队开发、部署和维护。在微前端架构中，每个子应用程序可以独立开发、构建、测试和部署，同时也可以独立于其他子应用程序进行扩展和缩放。

微前端架构的一个重要概念是应用程序的“微服务化”。这意味着将应用程序拆分为不同的功能模块，每个模块可以由不同的团队开发和维护。每个模块可以在自己的生命周期内独立开发和部署，并与其他模块进行通信和集成。

微前端架构的另一个重要概念是“集成”。在微前端架构中，不同的子应用程序可以通过共享组件、通信机制和协议来集成到一个整体中。这种集成可以是同步的，也可以是异步的。这种灵活性使得不同的子应用程序可以按照自己的节奏进行开发和部署，同时确保整个应用程序的一致性和可用性。

微前端架构的技术特性主要包括以下几个方面：

1. 模块化：微前端架构通过将一个大型的应用拆分为多个小型的模块，实现了代码和功能的模块化，使得开发人员可以更加方便地进行模块化的开发、测试、部署和维护。

2. 独立部署：每个微前端模块都可以独立部署，可以根据需要对不同的模块进行独立升级、回滚和扩容等操作，避免了对整个应用进行重启和部署的情况。

3. 独立运行：每个微前端模块都可以独立运行，可以通过前端路由和页面嵌入等技术实现模块之间的相互调用和通信，同时也避免了模块之间的相互影响。

4. 技术栈无关性：微前端架构可以将不同的技术栈进行集成，允许使用不同的编程语言和框架进行开发，方便团队成员使用自己熟悉的技术栈进行开发。

5. 动态加载：微前端架构通过动态加载技术实现按需加载，可以将代码和资源进行动态加载，避免了页面加载速度慢和资源浪费的问题。

6. 数据共享：微前端架构可以通过共享数据、状态和事件等技术实现模块之间的数据共享和通信，避免了不同模块之间数据不一致的问题。

7. 可维护性：微前端架构的模块化设计和独立部署等特性，使得开发和维护变得更加简单和容易，方便进行代码的维护、升级和扩展等操作。

特性

• 技术栈无关 主框架不限制接入应用的技术栈，子应用可自主选择技术栈

• 独立开发/部署 各个团队之间仓库独立，单独部署，互不依赖

• 增量升级 当一个应用庞大之后，技术升级或重构相当麻烦，而微应用具备渐进式升级的特性

• 独立运行时 微应用之间运行时互不依赖，有独立的状态管理

• 提升效率 应用越庞大，越难以维护，协作效率越低下。微应用可以很好拆分，提升效率

微前端的优缺点

优点

1. 可以与时俱进，不断引入新技术/新框架

2. 前端技术栈日新月异，微前端可以在维护好遗留系统的前提下，不断引入新技术和新框架，提高开发效率、质量、用户体验。微前端可以很好的实现应用和服务的隔离，互相之间几乎没有影响，可以很好的支持团队引入新技术和新框架。

3. 局部/增量升级 对于许多组织来说，追求增量升级就是他们迈向微前端的第一步。对他们来说，老式的大型单体前端要么是用老旧的技术栈打造的，要么就充斥着匆忙写成的代码，已经到了该重写整个前端的时候了。一次性重写整个系统风险很大，我们更倾向一点一点换掉老的应用，同时在不受单体架构拖累的前提下为客户不断提供新功能。

4. 代码简洁、解耦、更易维护 微前端体系下，每个小模块的代码库要比一个单体前端的代码库小很多。对开发者来说这些较小的代码库处理起来更简单方便。而且微前端还能避免无关组件之间不必要的耦合，让代码更简洁。我们可以在应用的限界上下文处划出更明显的界限，更好地避免无意间造成的这类耦合问题。

5. 独立部署 就像微服务一样，微前端的一大优势就是可独立部署的能力。这种能力会缩减每次部署涉及的范围，从而降低了风险。不管你的前端代码是在哪里托管，怎样托管，各个微前端都应该有自己的持续交付管道；这些管道可以将微前端构建、测试并部署到生产环境中。我们在部署各个微前端时几乎不用考虑其他代码库或管道的状态；就算旧的单体架构采用了固定、手动的按季发布周期，或者隔壁的团队在他们的主分支里塞进了一个半成品或失败的功能，也不影响我们的工作。

缺点

1. 重复依赖 不同应用之间依赖的包存在很多重复，由于各应用独立开发、编译和发布，难免会存在重复依赖的情况。导致不同应用之间需要重复下载依赖，额外再增加了流量和服务端压力。

2. 团队之间更加分裂 大幅提升的团队自治水平可能会让各个团队的工作愈加分裂。各团队只关注自己的业务或者平台功能，在面向用户的整体交付方面，会导致对用户需求和体现不敏感，和响应不及时。

思路

前端：WebPack 5 和模块联合、qiankun、 Luigi 等,简单一点儿，联邦模块实现了三个要素（URL 加载，渲染 root,参数）是不是跟 jq 时代的组件化封装类似? 只不过面临的情况就是多体系 React、Vue2、angularjs、Vue3、html、强交互、框架融合、样式隔离等问题。

服务：Dobbo、Eureka、nacos 等,当然要说好用和稳定还是 nacos 相对好一些,nginx 按理说更好用，但是外置的，界面配置、链路追踪、内部组件约定等满足不了，不过又有新问题，框架太多，建设阶段不同，重构收益小，又有新问题，higress 可以做一下研究