手把手带你了解微前端

前段时间呢,因为公司业务的特殊性 有一个项目他是由四个系统组成
然后系统之间相互之间又有一些联系和重复的功能，所以我们在技术方案评审的时候想有没有什么办法能够把这个东西整合起来做成一个拓展性强并且可插拔的应用
我们花了一段时间去讨论，得出一个结论就是去做一套微前端架构
因为这套架构设计是由我全权负责 所以我就将我这次做架构的经验 给大家分享出来，希望能够给有需要的同学提供一些思路。那么话不多说 我们开始吧
首先我们需要去了解一下什么是微前端，微前端其实就是一个有很多子应用的主应用，有点像装载了很多飞机的航母。它是可以依赖航母，也可以离开航母独立存在，就是一个可插拔的架构方案
了解了它们的原理，我们就可以明白，所以我们在开发的时候就是先有一套主程序，主工程去负责登陆，主体布局，菜单路由，和主题一类的全局化配置，属于框架的部分，
然后就是子工程，每个子工程都负责一个当独的业务，每一个业务都可以用不同的技术去实现，可以用不同的技术栈，vue、react、angular、jq也行，他们只关注这一块的业务，每个业务是一个独立的模块，所以不会相互之间产生影响
比如说这个模块负责的是产品1，技术可以用vue， 这个模块负责的是产品2，技术可以用react...等等
然后我们再去介绍在子工程之外的公共库，也就是三方包，可能我们这些工具包有元组件组件库，业务组件库，请求库 ，它提供我们的一个上传 下载，还有有关于公共的安全 包括这个WebSocket的一个使用，它们都是比较核心的工具。
另外我们可能还有一些说明文档 包括规范文档系统架构说明文档，一般来说我们会让它越详细越好，这样才能够让别人更容易上手，也更能体现它一个存在的意义，能够让用户更加深刻地了解到
我们这个危潜端架构的使用方式
还有我们也会有一些规范来提升它的可维护性， 比如说我们在这个这套规范里面严格定义它的目标结构，包括它的文件的命名，配置文件的命名 一些组件命名 我们都会有一个严格的标准，还有用EsLint 和 prettier 去做一个所有代码的一个格式化校验，提升代码的可读性，当然还有Git做一个版本管理的工具，方便追溯和回滚。

其实最终来说，能够在同一个体系下兼容不同的技术栈，是我们抛开业务层，选择这个技术栈很重要的一个点，它可以让我们后续对前端技术有更多的尝试和跟进当下的技术，产生更多的可能性。
好了， 那今天的分享到这里就结束了，下一期我会去讲一下 关于微前端搭建的过程中 出现的一些问题 然后我是怎么去解决这些问题填坑的，我们下次再见