GMTC·2019近日在深圳召开。腾讯在线教育团队高级工程师袁龙在会上发表了《在线教育小程序云开发的工程实践》演讲，介绍了腾讯在线教育的小程序工程、小程序CI、CD、多终端云开发。发展探索和实践经验。演讲内容整理如下。

1、腾讯在线教育业务背景

首先介绍一下腾讯在线教育的三大主营业务。

- 成人专业、兴趣学习的腾讯课堂

- 小学、初中、高中K12领域企鹅辅导

- 适合学习英语的孩子

这三个业务在每一端都有产品实现，以满足不同终端用户的需求，当然也包括小程序。

我们的小程序以工具为主，主要带动业务流量，如腾讯课堂签到小程序、企鹅快算小程序等。还有基于平台内容的小程序来承载服务，例如腾讯课堂小程序。

2. 小程序工程实践

刚才我们介绍了我们的业务会有很多小程序，那么我们是如何实施小程序工程实践的，遇到了哪些问题。

首先我们看一下我们小程序相关的需求场景。由于业务迭代很快，我们的单个小程序会并行多个需求，同一个小程序也会有多个需求同时开发。

这是一般的开发方法。开发者单独开发，然后预览二维码并将代码上传到小程序后端。您可以看一下这可能会导致什么问题。其实与我们平时的Web开发方式相比，不难看出这里的开发环境并不统一。除了操作系统和版本之外，还有我们的小程序开发者工具。

有一次，小程序发布后，我们收到反馈称小程序的某个页面无法打开。由于此次发布并未涉及无法打开的页面，最终排查发现该问题是由上传代码并更新开发者工具的同学造成的。降级开发者工具并重建上传后问题解决。

除了开发环境不一致之外，后续过程中其实也存在很多问题。

基于以上问题，我们做了一些思考，最终创建了一个小程序工作流程来解决这些问题。今天主要给大家介绍一下后续的搭建、测试、发布和协作。

让我们首先看看构建和发布。从图中可以看出，“构建npm”和“上传代码”这两个环节都依赖于微信开发者工具。微信开发者工具还提供了CLI和HTTP调用的能力。

为了更好地将这些能力与我们的需求结合起来，我们基于微信开发者工具的CLI开发了我们的小程序构建工具。该工具的使用流程如图所示，包括发布前检查主干分支的合并、验证npm包版本的合法性、构建npm、自动获取所需的版本号以及描述上传模型。

有了这个工具，我们在上传小程序代码之前就更加安全了。

为了更好的保证我们小程序的质量，我们在自动化测试方面也做了尝试。小程序的自动化测试分为UI测试和单元测试。

我们先来看看 UI 测试。我们使用`-`和`jest`来进行UI测试。

上图为腾讯课堂小程序的课程详情页面。这里需要测试验证的项目包括点击播放、切换目录、播放状态检测、底部按钮状态检测等。

这是我们的测试示例，我们可以在其中看到每个用例的执行情况

我们在UI测试过程中也遇到了很多坑，需要注意的地方也很多。

我们来说说小程序的单元测试。我们使用“-”和“jest”进行单元测试。

这里我们主要验证组件结构的渲染结果以及组件的实例方法。

我们在进行单元测试时也遇到了很多陷阱。

我们再回顾一下之前开发过程中的另外两个问题。我们开发的构建工具只做预发布和构建工作，我们的构建环境还没有统一。

为了让我们的流程更加完善，彻底解决各个环节中的问题，我们整理了小程序的结构，如图所示，分为三个部分：

左边我们的发布平台有一个完整的发布流程，包括关联要求、发布前检查、文件、发布审核文件、发布内容通知等。

右边是我们借助公司CI平台实现的小程序的CI和CD。我们部署了一台Mac机器，使用自动化工具和小程序IDE实现了小程序的自动化构建和发布，并推送了构建和发布结果。

右下角的客服机器人服务作为消息中心，负责推送我们构建的二维码，告知小组构建和发布的情况。主要用于消息推送。同时，我们还增加了将项目分支绑定到需求组、设置预览页面以及基于其触发构建的功能。

整个架构在实际开发过程中实现，大致如下

我们可以看到触发机制中有@这样的操作，那么它具体是怎么完成的，作用是什么。

我们触发机器人并向机器人发送相应的指令，将需求绑定到组中，设置预览页面路径，触发组中的构建等操作，同时我们还进行登录重试操作。如果构建机上的微信开发者工具的登录状态失败，我们会返回登录二维码，扫码登录并重试之前的构建过程。

目前小程序团队也在开发小程序CI的相关包，独立于微信开发者工具，可以更方便地接入CI。您可以期待一下。

我们的这个流程也在公司内部积极推进。公司已经有十多个团队，接入了三十多个小程序。

3. 小程序云开发实践

我们解决了小程序工程化的问题。面对频繁的业务需求，尤其是前端开发效率一直高于后端的场景，我们是否能够有更多的发挥空间？小程序是首要任务，我们计划尝试使用云开发。

云开发简介

云开发是腾讯云为移动开发者提供的一站式后端云服务。可用于多种客户端，目前支持小程序和网页客户端。云开发目前主要提供云数据库、云存储、云功能三大基础能力，构成了较为完善的后端能力。

看看我们的实际业务场景。因为我们是一个现有的业务，基础后端服务已经成熟，所以我们希望多个小程序之间共享云功能等资源，包括与Web共享。但是小程序内置的SDK调用方式并不能满足我们目前的需求。

既然不能使用云开发，那么我们就重新梳理一下目前前端业务和后端服务之间的调用链路。我们的请求从前端到网关，经过我们的CGI接口，然后调用具体的底层服务。我们可以添加 Node BFF 层。承载一些CGI接口的能力。

如果自己搭建中间层，必然会面临如下所示的很多问题。这个工作量很大，大部分前端同学可能都没有那么专业。

其实最近很流行，可以解决我们上面的问题。

我们先来看看

架构包括触发器、云功能平台、Bass服务。

当云函数平台收到事件时，会启动一个容器来运行函数代码。如果此时收到新的事件，并且没有可用的空闲容器，则会启动另一个函数实例来处理该事件。

使用云功能，配合API网关，可以解决我们之前的SDK调用问题，满足我们的业务场景。

现在我们计划连接，如何将我们现有的服务迁移到它上面，或者如何像应用程序开发一样进行开发。

我们来看看两者的比较。网关输入参数结构不一致。这里需要对代理层进行适配，是否需要添加路由适配，迁移后是否涉及到业务逻辑的调整。

从下图可以看出，除了适配代理层之外，调用返回的内容也需要适配。云开发提供了包来解决这个问题

我们将它与我们基于Koa开发的服务框架结合起来推出——用于业务开发

这是一个使用示例，访问起来很方便

我们再看一下云函数的执行流程，如图

我们可以看到，当实例不存在时，就会进行所谓的冷启动过程。冷启动涉及启动容器、下载代码、开放网络等，这会增加函数的执行时间。

如何优化冷启动

首先，我们可以添加预处理，将耗时的操作放置在函数入口之外，例如服务地址解析、数据库连接等，以减少函数执行的耗时。

其次，当我们在函数中调用服务时，我们使用VPC()网络来减少网络层时间。可以看到我们改进后，函数执行时间减少了近50%，稳定在50%左右。

如果功能逻辑较重、路由较多，则代码量可能会较大，冷启动过程中代码下载时间也会增加。这里我们可以将较重的逻辑拆分到不同的云函数中，并提供统一的（认证）入口进行调用，从而优化函数加载的效率，减少冷启动时间。

不过这里增加了一层功能代理层，可以根据实际效果来选择。

如图所示，我们还是希望使用云开发，通过SDK调用。如何解决多终端复用问题

回顾我们之前的问题，使用内置的SDK无法实现多个小程序调用同一个云开发环境。

我们与云开发团队深度合作，推出了小程序小程序，实现了多个小程序调用。

由于我们已经使用API​​网关调用来上线该功能，现在切换到SDK调用需要一些适应。

由于调用方需要封装并带上路由参数，因此功能变化比较小，只是调整解析即可。

除了开发之外，我们还需要规范云功能的部署。小程序开发者工具提供了通过右键菜单部署云功能的能力。然而，这种方法存在一些问题：

云开发提供了CLI工具来操作云功能，包括登录、初始化、功能部署、功能触发等。通过这个工具，我们的功能可以在单独的项目中单独开发，与小程序项目分开管理。

CLI提供了非常灵活的配置，可以配置超时、私有网络、是否在线安装依赖等。我们将配置分开，针对不同的云开发环境使用不同的配置文件，标准化云功能工程项目。

在CLI的帮助下，我们还创建了一套云函数发布流程来统一函数构建环境。开发阶段，通过Git Hook触发将提交的代码部署到测试云开发环境中。预发布和发布阶段也部署到相应的云开发环境中。我们在发布阶段将代码归档。如果功能需要回滚，我们使用Just the code。

团队在禾云开发了两个小程序。腾讯课堂小程序的API网关调用已经迁移为SDK调用，也用在对应的H5上。

最后总结一下，这次我主要跟大家分享一下我们团队是如何做小程序工程的，还有目前很流行的云开发，对于我们的服务实现来说非常方便。云化发展也是未来的发展趋势。

希望这次分享能够给大家带来一些思考，给企业带来一些帮助。

谢谢大家！

该团队隶属于腾讯，是国内最专业的前端团队之一。

我们专注前端领域多年，负责过QQ信息、QQ注册、QQ群等亿级业务。目前专注于在线教育领域，精心打磨腾讯课堂、企鹅辅导三大产品。