用户故事

缪斯某团队使用Vue2.0框架开发前端页面。

2019年初上线产品，截止2020年下半年生产上有业务7大类型，页面281个，打包后大小为180+MB。 随着时间的增长，产品逐渐出现以下现象：

1. 大部分都是业务逻辑丰富，图片静态资源组件繁多的页面。

2. 业务中引入了大量的脚手架

3. 项目错综复杂，前后有多批人马进行开发，造成了目前项目各种资源类型混乱，组件可复用性低，静态资源庞大，垃圾组件越来越多。

前端Vue项目的高速增长使得项目出现了编译慢、打包慢、上线慢等亟待解决的问题。

​

目前产品主要弊端有：

• 编译太慢。项目中页面多，资源大。如果所有页面全部编译，没有3分钟绝对编译不完。（这还是在开发过程中每次都保存页面）
• 打包速度太慢，我一个同事的macbook air打包速度是在半小时左右。有好多新来的同事第一次打包都会跑来问，是不是死掉了，为什么停住不动了。（我的电脑算是所有人最快的，但是也需要10分钟+）
• 上线风险高。前端Vue工程是每次整体打包，全量上线。网上有一句话说“不要把鸡蛋放在一个篮子里”。打包如果没有专人维护，所以可能会造成有的功能莫名其妙被影响，开发人员就算再小心也有错提，误删的情况发生，影响其他业务。
• 工程和打包后的体积越来越大，不符合敏捷迭代思想。Vue工程资源越来越多，170MB+、200MB+乃至300MB+，如果不做下线和清理，项目就会变的不可维护。

工程组织结构对比

我们的工程组织结构	正常的工程组织结构

从 颜色 和 模块数量 上就可以发现，我们的项目很大，是不健康的。

考虑和改变

通过对缪斯产品的分析，然后结合互联网提出的中小型企业所面临的问题。
梳理出 vue-module-pro 需要解决以下问题：

• 独立部署 : 每一个模块可单独部署,颗粒度可小到某一个单页面的独立部署,不对其他模块有任何影响
• 扩展 : 每一个微模块可以独立横向扩展以满足业务伸缩性，与资源的不必要消耗
• 风险降低 : 通过“将鸡蛋放在多个篮子里”的方式降低业务风险。每次只需要操作对应的微模块，其他微模块不受影响
• 复杂度可控 : 每一个UI业务组件归属每一个微模块,避免代码巨无霸,高效并且降低复杂度,便于维护同时提升开发效率
• 相互通信 : 全局可以进行通信，微模块间的组件可以相互引用。

vue-module-pro 作为一款高性能的 前端微服务化 解决方案，能够解决上述的所有问题。
同时，融入了目前互联网上Vue的最新思想和设计理念，取其精华、去其糟粕。
解决了生产问题 ，融入了新的设计思想和理念 ，开发了多种实用的前端工具 ，同时对 公司旧框架可以平滑升级 。
任何人都能快速上手本项目。

​

本作品采用《CC 协议》，转载必须注明作者和本文链接