一、背景
在开发过程中，经常会遇到业务方快速上线功能需求，如协议页、图文介绍页、引导页等静态页或榜单、抽奖等动态活动页。无论是静态还是动态页面，会增加研发工作量与时间成本，下面列举一些痛点：
- 活动上线成本
- 支持多语言
- 不同业务之间的活动组件无法复用
- 组件无法实现动态更新
开发一个能够让各业务方的产品或运营人员快速配置活动并上线活动页的平台就油然而生。
二、方案
1. 上线成本
对于上线成本，既然是统一的配置平台，可以给每个活动分配唯一的活动id，再通过制定一定的规则（如不同url定制不同的页面json结构），可以实现区分不同的环境快速调试和上线。
2. 研发成本
为了解决这个的问题，讨论了两种方案，一种是基于npm包;另一种就是基于公司自研的开源微前端解决方案EMP，下面给出两种方案的具体对比：
- npm方案
这种方案存在很多的问题，列举一下比较致命的点
1. 从UI层面抽离出功能相似的组件，不同业务之间的UI风格差异大，抽离成本剧增
2. 每次改动npm包版本，平台都必须手动更改对应版本并发版，平台稳定性低
3. 组件及其定制逻辑直接与配置平台强关联，代码耦合，平台健壮性极差
通过分析发现问题的根本在于多个业务耦合到一个平台导致的，如果我们可以换个思路。
1 对于组件复用问题，是否存在不需要抽离npm包就可以共用组件的方法呢？
2 对于业务间相互影响的问题，是否可以通过抽离配置平台的能力，提供给各个业务使用呢？
调研过程中，发现EMP微前端方案好像可以解决我们的问题，流程图走起~
- emp方案
我们看看这个方案如何解决上述npm方案存在的问题：
1. 各个业务只需要根据配置平台的约定，增加对应组件的配置，再暴露业务组件列表，便可以直接复用组件，业务组件改造成本基本为0
2. 对于特定资源（不同业务组件、平台功能迭代等）的更新，只需要构建发版该资源本身，引用到的业务可以实现同步更新
3. 将配置平台的能力和业务组件定制分离，每个业务组件模块和平台只需关注自身的逻辑，避免了不相关联的资源之间造成的的耦合，平台的健壮性显著提升
三、改造过程与结果
由于变色龙平台结合EMP方案，改造的过程和结果如下
- 业务接入：通过配置emp-config.js暴露组件和配置给变色龙配置平台
- 变色龙配置平台：通过配置project-config.js来引入各个业务的组件列表
- 变色龙配置平台
- 页面及其对应的json结构
四、写在最后
欢聚变色龙能够在短时间内跑通闭环，结合EMP的微前端方案，通过平台免去了反反复复的上线成本，通过EMP可以轻松实现组件复用，另外对于业务逻辑和颗粒度更细的方法也是可以共享复用的，业务组件的改造成本直线下降了，另外组件可以提供由平台约定的配置从而实现在平台丰富组件功能，实现组件的动态赋能。
今日的分享就到这里拉~ 在这里，真心地向小伙伴们安利EMP微前端，如果业务有需要，接入微前端后从中获取的收益相信是巨大的，口说无凭，这里奉上使用指南，快去尝试一下吧~ 欢迎大家一起探讨交流！
