00:11
嗨，你好，我是西林。前一段时间我遇到这样一个问题，接到我朋友的邀请，帮忙解决一个问题。他们几年前做了一个不大不小的项目，使用的是当时看起来前景非趁的Angela框架，所有业务呢也都跑在这个框架下。几年之后的今天，当时的业务已经处于低迷状态了，舍弃呢不太可能，而随着前端的发展，安拉开发者在国内是很难招聘到的，而如果将业务选用新的技术站进行重构，那成本就非常高，问我怎么办？我就建议他们使用微前端的方式来对整个项目的架构进行升级，我也有幸参与到了项目的升级工作当中，赚了一顿小烧烤。围前端这个概念我相信很多人已经听过了，甚至也有过使用的经验。
01:11
但是真正实际上手做过的少之又少，不是每一个前端都有机会接触到项目架构的设计，所以这一次呢，我就结合自己的经验来说一说目前微前端架构的设计理念以及具体应用的实践方案。欢迎点赞收藏转发关注什么是微前端？不管你对微前端有没有接触过，我先来问一个问题，你是如何实现多个应用之间的资源共享的？比较多的处理方式呢？就是NPN包的方式进行抽离和引用。比如多个项目之间可能存在某些业务逻辑或者模块是可以复用的，那我们就可以抽离出来以NPM包的形式进行管理和使用，但是这样呢，却带来了一个问题，首先第一个就是开发效率。
02:11
问题，如果需要迭代NPN包内的业务逻辑，需要先发布mpn包，然后在使用了该MP包的应用中进行更新，再进行各自项目的构建，整个过程是非常繁琐的，如果涉及到应多的话，那花费的人力和物力还有精力也就更多了。那么再一来呢，就是多团队协作的问题，不同的团队或多或少的都存在不同的编码风格，我在项目中每引入一个NPM包就可能意味着一种不同的编码方式，这样会让我们的项目杂乱无章。多个团队同时开发一个大型且复杂的产品是一个非常棘手的问题，那微前端的概念就是通过引入一种更加优雅的方式来解决我们面临。
03:11
的这些问题，其实早在2016年微前端的概念就已经诞生了。微前端的概念官网有这样一句话阐述了对微前端概念的定义，巴拉巴拉巴巴拉哒，啦啦啦啊，快点吧，反正我也读读，读不出来。嗯，好，那翻译过来呢，就是与多个可以独立发布功能的团队一起构建现代化外部应用程序的技术策略和方法。那从微前端官网我们也可以了解到，微前端概念是从微服务概念扩展而来的，摒弃了大型单体应用的方式，将前端整体分解为小而简单的块，这些块可以独立的开发。
04:11
二独立测试，独立部署，同时仍然可以聚合为一个产品出现在客户面前。你可以这样理解为前端，它是一种将多个可独立交付的小型前端应用聚合为一个整体的架构设计。那这里呢，也有两个点是需要注意的，首先第一点微前端它不是一门具体的技术，而是整合了技术策略和方法的架构理念。技术实现上你可以使用脚手架，辅助插件或者规范约束等等，以生态圈的形式展示出来，是一种宏观上的架构。这种架构目前有多种方案，当然都有利弊之处，一会儿呢我们会详细的介绍。那第二点就是微前端并没有技术。
05:11
术站的约束。每一套微前端架构下的具体应用都可能使用了不同的技术站。你可以将re技术站和VI技术站的项目整合成一个项目去运行，也可以统一使用一种技术站开发所有微前端架构下的应用。说到底，微前端最大的价值就在于可以帮助我们拆分句型的应用，降低耦合度，使应用变得更加可维护，同时兼容历史应用，轻松实现增量开发。
我来说两句