Udesk微前端之路

Udesk为什么要做微前端？

微前端是最近这两年比较热的一个概念，随着前端框架的流行以及前端工程化的程度越来越高，多数公司都会采取前后端分离的方式，来构建自己的单页面应用系统。Udesk在2017年初便开始实践微前端了，只不过当时微前端这个概念还没有被广泛提起。虽然现在微前端已经深入人心，也有一些大公司把微前端做的比较工程化了，比如蚂蚁金服的 qiankun ，美团也有微前端的内部实践，不过在那个时候还没有这些工具。

我们当时正处在前端技术栈迁移的阶段，希望把主要开发框架从Ember逐步迁移到React，但又不希望把现有系统彻底重写，所以需要一种方式能够逐步增量更换技术栈。由于Udesk业务和客户量都发展很快，把整个产品线都停下来完全做系统重写是不可能的，所以我们希望这个过程能够是渐进、增量式的，新功能要与 Ember主系统无缝集成，而且要保持SPA的使用体验，不能做页面刷新。

除了技术方面的需求，在业务也有很迫切的需求。从2016年开始，Udesk拉起了多条新业务线，前端团队也很快扩大到了近40人的大团队，每一个业务线都是独立的SaaS产品。新业务产品需要与核心客服系统有机集成起来，甚至新产品之间也要相互融合。另外，客服系统已经比较庞大，需要对系统能够按业务模块进行拆分解耦，子应用要能独立开发、部署、运维，提高系统的灵活性和弹性。

前端项目有哪些痛点？

随着前端系统规模的变大，在系统打包尺寸、构建效率和业务分离等方面都给我们提出了新的挑战。虽然Webpack提供了很多机制来尽量减少包的尺寸，比如 minify 、 tree-shaking 、 dll 、 split chunks 、 HappyPack 、 dynamic import 等。其中最接近系统分治理念的就是 dynamic import 做代码分割，一般的做法都是根据路由把系统分成多个子包，主包只包含首页面渲染需要用到的代码，这样主包的尺寸就会大幅减少，从而提高了首屏加载的速度。

但这些还是解决仅仅 单一系统 的问题，对于一些 ToB 的大型系统或者跨地域的团队来说，这些是还是不够的。他们需要解决下面这些痛点：

业务分离，系统分治解耦；

团队技术栈不同，异构系统集成；

按业务进一步拆分bundle；

单个大型系统构建时间长；

业务子系统独立开发、部署、限制错误边界；

低代码场景，需要嵌入用户侧自定义代码；

上面这些从根本上来说还是一个系统分治的架构思想，无论我们怎么优化webpack，当一个系统业务模块很多的时候，我们优化带来的尺寸下降，还是很快会被大量的业务代码所淹没，主系统仍然是一个庞大的 Frontend Monolith (前端单体) 。当然除了代码尺寸问题，更重要的是所有业务线耦合在一起，一块编译、一块部署，一旦发现一个问题，整个系统需要做回滚，那些没有问题的业务模块也会受到影响，如果有的团队是在异地，甚至跨时区的话，协同部署更是很难的事情。

如果系统能被分割为N个子应用的话，不但可以按需嵌入到主系统，我们还可以把多个子应用按业务相关性进行自由组合，就可以形成满足不同客户场景的多种 解决方案 ，这对于 ToB 业务来说还是有很大优势的。

微前端还能提供解决历史技术栈的一剂良方，对于一个大型系统来说，变更技术栈是一个很难的事情，意味着使用新的语言或框架把所有历史代码重写。一方面开发工作量十分巨大，但这还不是最重要的，时间成本才是最难承受的。假如老系统重写需要两年时间，那我们是停下主业务两年，等待新版本完成再上线吗？这恐怕是任何一个公司都无法承受的。如果采用微前端，我们可以把系统拆分为多个子业务模块，完成一个模块就上线一个模块，系统迭代速度大大加快，而且同时也有时间响应老系统的开发需求。还有一个优势就是，新模块可以使用最新的技术栈。由于现代框架都很轻，而且模块化和隔离性都做的很好，完全可以在一个页面中运行多个框架实例，甚至两个不同版本的框架。所以在新模块中可以使用各种新框架，方便团队的技术升级，和新技术探索。

架构图

技术选型

由于保持单页面的使用体验是我们的核心诉求之一，所以前面两个方案很快就被淘汰了，接下来我们就主攻 jsSDK 这个方向。最后在填了很多的坑之后，最终子系统被成功嵌入到了主系统中，而且效果也是非常不错的。每个子系统独立开发、部署、运维，发版节奏完全自己控制。主系统按需动态加载子系统，动态渲染并挂载，与主系统虽然跨了技术框架，但仍可以完美融合，并且浏览器前进、后退、甚至刷新页面后都可以正常还原子页面，与一个系统的单页面使用体验无异。

实现方案