微前端的场景及收益讨论

[GuoYongfeng]

深受其益

1.支持遗留系统的接入，支持多技术栈并存； 2.打包速度更快了，资源优化更明确了； 3.领域级、产品级、功能模块级等维度的代码维护更清晰了； 4.基于以上三者带来的团队协作效率会有明显的提升；

深受其害

1.基础建设成本增加了，同样一套组件库，在一个公司里面要用不同的技术栈实现； 2.运行时交互风格调整成本高，比如换肤、切主题、或某个体验细节全产品升级； 3.还是体验问题，微前端架构支持各个研发『诸侯自治』，统一调整产品风格的时候贼费劲； 4.会和统一技术栈的愿景「背道而驰」，我们希望把小众的技术框架替换掉、把遗留系统进行架构升级，让研发主力都聚焦到主航道编程模型上，形成公司级、集团级的内部开源力量。

实践

1.微前端理念实践到开发框架级、脚手架级，沙箱、隔离、应用生命周期等没有做； 2.增强「统一工作入口」建设，大家称之为Portal，将各个领域的功能集成上来，微前端架构中的部分能力则放到这里面去实现； 3.依然主张基础技术栈的统一，以获得基础建设的最大化收益。（前端再怎么变化，体验建设依然是第一位的，框架都不一样，UI复用性带来的价值就大打折扣了）

[YataoZhang]

首先，非常赞同相关观点，这里介绍下我们当时做这个的初衷：

我们做的目的

其实我们当初做这个是为了给大应用解耦：

1. 减少构建成本（时间、测试、知识）
2. 提升上下线效率和降低回归成本（新功能可以先上线，但是不打开入口；如果要下线就直接把app的描述文件设置为ignore即可，趋近于零成本）
3. 物料的（业务+基础组件，简单理解为飞冰的物料）跨项目复用
4. 功能间隔离，提升稳定性，减少系统核心复杂度

其他

1. 虽然它可以用来兼容不同的技术栈及解决历史债的问题，但我们并没有着重考虑这个问题
2. 我们的微前端的服务更多的是功能（Feature）级别的，而不是路由级别的
3. 在微前端的基础上，更多的参考了windowNT操作系统的实现原理

思考

微前端不仅仅可以做现在人们常说的处理历史债、统一入口，还可以应用在统一基础建设的前提下做大应用拆分提效上。

[GuoYongfeng]

可以达成的基本观点是「在统一基础技术栈之上推进微前端架构能够发挥更大价值」。