干货分享：蚂蚁金服前端框架和工程化实践

框架发展历史

 

 

这是我们的框架发展时间线。
• 2015 年之前我们有 Sea.JS、Arale、SPM 开源技术方案，大家可以有所耳闻。
• 2015 年我们接入 React，从自研的 Roof 到 Redux 再到开源的 Dva，一步步验证我们的最佳实践，并把这些实践交给开源社区检验。
• 2017 年开始尝试了新一代的企业级前端框架，Umi 和 Bigfish，前者是从无线业务中长出来的，后者是从中台业务中长出来的。
• 一个团队出两个框架毕竟不是长久之计，后来老大直接把两拨人调到一个组，于是就愉快地合并在了一起。

 

 

在 Umi 和 Bigfish 时代，我们从刀耕火种的时代跨入了工业化时代。因为在此之前，用户需要接触很多技术栈和细节，在 Umi 和 Bigfish 中，用户只要知道一个框架，剩下的全部不用了解。框架像一个魔法球，把各种技术栈吸到一起，加工后吐给用户，以此来支撑业务。

web前端全栈资料粉丝福利（面试题、视频、资料笔记、进阶路线）

 

 

在两个框架合并之后，我们的现状是这样：
• umi 对外开源，bigfish 对内服务内部同学。
• bigfish 扔掉原有实现，改造成 umi + umi 插件集的一个架构。
• 我们不是第一个这么做的，类似的还有 eggjs 和 chair。这是一种很好的方式，开源和业务两不误。
• 那么，这是我们的框架终局吗？以及是否还有更好的方式？大家也可以思考下，后面在未来规划区域会有探讨。

 

 

这是一些蚂蚁的内部数据：
• 1100+ 内部应用数
• 新增产品 80% 都用此框架
• 包含 100+ 插件数量，社区够活跃，尤其是内部的
• 1500+ 内部使用者

目前来看，这个框架基本统一了内部的框架使用情况，不仅有不熟前端的 Java 开发，略熟前端的外包，还有资深的前端同学。要获得那么多同学的认可，并不是件容易的事。

为什么我们能成

那么，为什么我们能成？个人理解，我觉得有几个关键词：
• 人
• 业务
• 流程
• 开源

 

 

人是非常重要的一环，甚至比技术本身更重要一些。

那么别人为啥要用你的框架？首先，框架要好用，这是最基本的；然后，使用者尤其是资深的前端同学，还得在这上面找到自己的成就感和 ownership，另外如果绩效漂亮就更好了。总不能别人用你的框架，然后只有你自己一个人的绩效好，那是不会长久的。

我们的解法是插件体系。

 

 

框架不是凭空而来的，需求来自于业务，所以用框架写业务的同学往往能发现框架不足的点，他们可以开发适用于自己业务的框架插件，反哺框架。如果这是通用需求，那就亮了。框架的内部开发群有 100+ 人，包含大量来自业务线的同学，这就是插件体系的好处，人人都能贡献。为了让写插件变得简单，我们给框架分了五层架构。

 

 

包含依赖层、插件层、插件集层、应用类型层和部署模式层，大家可在任何一层都可贡献代码，
• 可以写一个独立的功能插件，比如和某个服务的对接，比如扩展路由的某个功能，比如实现一套特殊的补丁方案；
• 可以做归类，把一系列插件整理到一个插件集里，适用于某一类的业务开发；
• 可以扩展应用类型，比如 SPA、MPA、微前端等等；
• 可以扩展部署模式，比如和不同的框架或平台做结合；

 

 

这是插件生命周期图，包含：
• node 环境执行的编译时
• 浏览器上执行的运行时
• ui 辅助层的编辑时

大部分插件体系只会考虑 node 编译时，我们加上运行时和编辑时的支持，赋予了插件更大的能力。具体做了什么就不展开了，没个框架都不同，但做的事情其实大体一致，往上说是 html、css、js，往下说还有各种工具的配置，比如 webpack、babel、postcss、dev 中间件 等等。