如何实现多个应用之间的资源共享?

之前比较多的处理方式是 npm 包形式抽离和引用，比如多个应用项目之间，可能有某业务逻辑模块或者其他是可复用的，便抽离出来以 npm 包的形式进行管理和使用。但这样却带来了以下几个问题：

• 发布效率低下。如果需要迭代npm包内的逻辑业务，需要先发布npm包之后，在每个使用了该 npm 包的应用都更新一次 npm 包版本，再各自构建发布一次，过程繁琐。如果涉及到的应用更多的话，花费的人力和精力就更多了。
• 多团队协作容易不规范。包含通用模块的 npm 包作为共享资产，“每个人”拥有它，但在实践中，这通常意味着没有人拥有它。它很快就会充满杂乱且风格不一致的代码，没有明确的约定或技术愿景。

这些问题让我们意识到，扩展前端开发规模以便于多个团队可以同时开发一个大型且复杂的产品是一个重要但又棘手的难题。

因此，早在2016年，微前端概念诞生了。

值得留意的几个点：

• 微前端不是一门具体的技术，而是整合了技术、策略和方法，可能会以脚手架、辅助插件和规范约束这种生态圈形式展示出来，是一种宏观上的架构。这种架构目前有多种方案，都有利弊之处，但只要适用当前业务场景的就是好方案。
• 微前端并没有技术栈的约束。每一套微前端方案的设计，都是基于实际需求出发。如果是多团队统一使用了 react 技术栈，可能对微前端方案的跨技术栈使用并没有要求;如果是多团队同时使用了 react 和 vue 技术栈，可能就对微前端的跨技术栈要求比较高。

微前端的使用场景

1. 拆分巨型应用，使应用变得更加可维护。

2. 兼容历史应用，实现增量开发。

微前端的优势

同步更新

对比了 npm 包方式抽离，让我们意识到更新流程和效率的重要性。微前端由于是多个子应用的聚合，如果多个业务应用依赖同一个服务应用的功能模块，只需要更新服务应用，其他业务应用就可以立马更新，从而缩短了更新流程和节约了更新成本。