作者：laelli 李锂

编辑：edwinzeng 曾鑫鹏

微保在微信钱包入口上线两年，两年的时间，我们不仅创造了非凡的用户价值，实现了用户规模的增长，在技术上，微保技术团队以 打造高效能、专业的团队为目标 ，沉淀了大量的经验和思考。微保第一次在 GMTC 舞台上亮相，想要和广大技术开发者形成交流，期望在交流中相互启发成长。

GMTC 全球大前端技术大会，刚刚在深圳落下帷幕，这次会议的主题是大前端的下一站。主办方考虑把大前端未来的议题放在深圳也是非常应景，深圳大湾区正在如火如荼的建设之中，同样也让人对深圳这座城市的未来充满的无限美好的遐想。

1

GMTC 主题解析

大前端的未来有哪些？本次大会出现了两个个比较新的主题：

• 小程序的应对与挑战

• Serverless实战

这两个主题关注度也空前的高，场场爆满 。

小程序目前作为微信主推技术，已经成为日活3亿的大流量平台，各大厂商都投入大量精力开发了小程序应用承接流量，小程序成为了前端开发的另一个重要的战场。

而对 Node 技术不断深入的使用，终于让前端开发再也不安于只折腾浏览器内的代码架构这点事儿，他们把激情蔓延到了后端架构上，借助 Serverless 技术兴起的东风，让前端开发后端逻辑更加得心应手。

2

微保的参与

微保 2017 年开始使用小程序开发应用，并于 2017 年 11 月在微信钱包入口上线，作为小程序最头部的尝鲜用户，我们对小程序开发有很多深入的思考和实战经验。

另外，微保的前端开发团队中有很多有后端开发背景，我们也早在 2018 年上半年开始尝试 BFF(Backend for Frontend) 实践，最终在 2019 年下半年演进为基于Serverless的架构。

微保这次在 GMTC 上分享的议题没有放在《小程序的应对与挑战》上，也没有放在《Serverless实战》上，而是选择了一个更宽泛的议题《大前端工程化实践》，我们想和大家分享的是我们通过哪些工程化的思路解决了小程序开发中的问题，Serverless 是做为工程化中的一种架构手段被引入。

3

分享实录

3.1 概览

3.2 早期的微保 vs 现在的微保 & 我们遇到的具体问题

2017年12月发布的版本，是微保正式上线后的第3个版本，只有3款保险产品，一个只有4人的前端开发团队，代码整体打包不超过1M，非常名副其实的小程序。

2019年10月发布的版本，距离微保正式上线正好2年，中间经历了84个版本。可以看到它和传统的 App 没什么两样了，4个功能板块，5个保险类目，40+个保险产品，4个前端开发团队（40+人），目前包大小以及突破微信在10月份的限制8M，向着12M迈进，这是一个超级小程序 。

超级小程序会遇到哪些问题，以下5点，我们觉得是首当其冲的

1. 微信对包大小的严格管控，主包大小不能超过2M，各个分包大小不能超过2M，总体不能超过12M，微信之所以做这样的限制是因为小程序是使用时下载，用户感知不到传统 App 下载安装的过程，这降低了小程序的使用门槛，但对开发人员在包大小优化上提出了很高的挑战。

2. 12M的大包编译速度很慢，小程序开发者工具处理这样的大包也会经常卡死 ，大大降低了开发人员开发效率，打断他们编码的思路。

3. 整个微保小程序涉及到 40+ 个前端开发，68 个 Git 仓库，组织的效率的提升是一个不容忽视的课题。

4. 数据的加载速率，页面的加载速率对互联网应用来说至关重要，加载时间过长，用户失去耐心，会造成非常高的打开流失率

5. 小程序必须作为一个整体发布，如何协调发布过程，让其有条不紊的进行，重要而富有挑战。

下面我们会从小程序框架、大前端架构、发布工具3个方面阐述我们是如何解决这些问题的。

3.3 工程化的基础 - 小程序框架

微保为了做到深入的工程化，不是直接写的原生小程序代码，而是有自己的编码约定，wmp-webpack-plugin 工具就是将微保的代码编译成小程序代码，这个是工程化的基础。配置文件、样式文件、模版文件都可以通过编译的方式来进行静态变量替换，变量可得到集中统一规范的管理。

还是借助编译工具，我们将一个整体的小程序变成了若干模块，各模块可独立安装运行，开发人员只要安装目前它兴趣的模块，这大大缩短了编译速率，小程序开发工具也顺滑如飞。

组件化是必须的，解决这个问题，研发效率的70%的问题就被解决掉了。组件化能少写代码，但少的代码是否就一定意味着包大小的减少？答案是不一定，还需要对组件在模块中的引用做全面的依赖分析，才能在主包大小（影响的是首次加载速率，这至关重要）和总体包大小上做一个合理的trade-off。

小程序框架实践上，做的比较深入的是数据预加载功能，小程序不同于H5，跳转本身会有比较大的时间消耗，在安卓机上更为明显。我们基于此，提出了数据预加载方案，能在页面开始跳转时，就发起目标页面的数据加载请求，这大大提升了数据加载体验。

3.4 大前端架构 - API 聚合渲染

从一个产品详情页说起，保险是一个特殊的商品，对普通用户来讲非常复杂，保险产品的产品详情页就会非常长，可以看到，微保的一个产品详情页，最基础的要调用8个接口，这就会带来2个显而易见的问题，页面加载缓慢，小程序业务逻辑复杂。

之前小程序调用后端接口的方式是直接通过网关和后端交互，后面我们为了解决上述问题，在小程序和网关之间加入了一层（服务端），我们叫它API聚合渲染层，它聚合后端的多个接口，小程序一个页面加载基本只会调用 API-Render 提供的一个接口。

API-Render 还提供了渲染功能，它将后端返回的业务逻辑数据，转化为视觉逻辑数据，小程序就不用处理复杂的业务逻辑，而是拿到数据，直接放入相应的组件进行展示，大大减少了小程序包大小。

2019 年，我们又对这个架构各层的职责进行了深入的思考和梳理，让每个层的职责更加专注明晰。API-Render 成为了产品逻辑层，需要处理复杂多变的产品逻辑。我们使用什么手段来保证产品逻辑层灵活高效&安全可控呢？

我们找到了兴起的 Serverless 技术，把产品逻辑层拆分为独立的函数，以函数为粒度部署，可以做到随改随发，Serverless 另一个重要的优势是资源以函数为粒度调度，资源的分配可以做到更加高效。

尤其对互联网金融类产品来说，互联网带来了巨大的流量，同时金融类订单的提交（如购买保险）相对来说又是非常低频的操作，高频和低频接口基于 Serverless 技术被分配不同的资源，大大节省了成本。

3.5 迭代开发利器 - 持续集成工具

2019.11.27 开始的双周迭代涉及了8个产品线，180+个需求，26个仓库变更，一次小程序的发布需要牵扯的东西非常多，如何保证流程有条不紊的进行？

这里我们将需求从开始编码到发布的流程结合Git 分支流程一起梳理了一遍。黄金流程一共涉及4个阶段14个节点。我们在这4个阶段，14个节点中找到了一个洞见，MR 是核心驱动力，管理好复杂流程，就是要管理好MR 的生命周期。

MR 既然是核心，那如何管理 MR 的质量，这里我们做了一个头脑风暴，并对每个 idea 在实现难度上打分

经过实践，我们发现"为MR编写有效描述"和"代码评审"是 性价比高 的做法。解决这两个问题，在前期就可以杜绝很多问题的发生。

一个 MR 不只是包含代码，还需要包含一个有效的描述，这里我们有一个最佳实践，如果这个 MR 涉及的逻辑比较复杂，建议是配一个 清晰的流程图 ，如果这个 MR 涉及 UI 的改动，改动的前后对比图。开发人员、评审人员、测试人员都会从中受益。

CodeReview 是 MR 质量非常重要的一个环节，当开发分支请求合并到迭代分支时就会走 CodeReview 流程。CodeReview 流程非常简单，但为什么很多团队 CodeReview 没有坚持下来，或者流于形式，或者直接放弃呢？

微保的一个洞见是"处理 MR 一定要及时"。及时的反馈能给到开发人员以鼓励，从而进入一个良性循环。微保为了保证 CodeReview 被及时处理，基于企业微信做了一系列的通知。

发布工具的建设也是围绕着 MR 在进行，每个 MR 都会被记录在迭代中，并跟踪其状态。测试人员通过工具提供的看板，管理 MR 的测试状态，全部的 MR 进入到了测试通过阶段，意味者可以安排产品体验，体验完成后就可以发版。工具做了很多流程化 、自动化和可视化的事情，从而保证了迭代有条不紊的进行。

3.6 总结

总结阶段，我们通过一个连线题，带大家把上述内容进行了一遍完整的回顾。每个方案不只是解决了一个问题，而一个问题也被多个方案从多维度解决。

4

微保的展望

小程序框架、Serverless API、小程序持续集成工具，我们目前还只是做了一些中浅层次的探索和实践。

2020年，我们还会在这3点上做更加深度的实践，并总结好的方法，这3个点都可以形成一个独立的更加深度探讨的议题，希望在2020年能和大家见面分享。