InfoQ 专访腾讯高级工程师：小程序云开发即将发布实时数据推送服务

小程序云开发 - 实时数据推送是小程序云开发即将发布的一个云服务， 可以监听云数据库的数据变更，实时推送到小程序端。省去了开发者搭建 WebSocket 的成本，是小程序中实时推送的高效实践方案。本文是 InfoQ 前端之巅对腾讯高级工程师周子杰的采访，他将为我们详细讲解实时数据推送服务的开发背景、技术解决方案及未来相关的产品计划。本次采访由「云加社区」支持。

InfoQ 前端之巅： 请您简单的介绍一下自己以及目前所负责的工作。

周子杰： 我刚毕业时来到了腾讯文档团队，负责腾讯文档实时编辑系统开发，并设计冲突处理算法。今年转到腾讯云云开发团队，负责搭建低时延、高并发、高可用的数据库实时推送服务。毕业后的这三年一直在做实时推送系统方面的工作，有时候也会做一些 Node.js 接入层的工作，目前是腾讯的高级研发工程师。

InfoQ 前端之巅： 您之前负责腾讯文档实时编辑系统开发，现在负责云开发 - 实时数据推送系统，这两者都对数据的实时性有一定的要求，您认为两者有什么相同点和不同点？

周子杰： 它们从设计上讲是相似的，但是在侧重点上又有所不同:

对于腾讯文档来说，它的侧重点在于数据的可靠性，因为文档编辑的时候，内容稍微出现一点错误，后续所有的编辑就没有意义了。但是对时延和并发的要求不高。

小程序云开发中的数据实时推送是一个云服务 ，需要提供给更多的产品使用，而每个产品都有着自己的应用场景，对数据可靠性、延时、并发量也有着不同的需求，所以我们的实时推送服务在需要在数据稳定性、低延时和高并发量上做到极致，并且微信前端 sdk 加上数据的确认和重传机制，为数据稳定性保驾护航。

InfoQ 前端之巅： 请您介绍下前端如何确定数据的丢失呢？

周子杰： 我们目前是这样设计的：后台去做监听，当监听到新的事件时就会往前端推送。在推送数据消息事件时会带上有序序号，比如现在给前端推一号事件、二号事件，但是突然发现接下来的是五号事件，这就可以判断出中间已经丢失了一些数据。之后客户端会重新请求后台发送丢失的数据。

InfoQ 前端之巅： 之前做腾讯文档的开发经验，有哪些是可以用在实时数据推送系统里的呢？

周子杰： 腾讯文档和云开发 - 数据实时推送系统在技术上是共通的，很多都是通用的技术，尤其在数据可靠性上参考了很多文档的成熟技术方案。而它们主要的区别在于：两者所需要支持的并发用户数是不同的。文档支持的并发用户数没有那么多，假设我们这个产品日活是一百万的话，那它最高的同时连接后台的用户数可能就在十万左右。而数据实时推送系统是一个云服务，其主要目的是给客户开发的产品提供数据推送服务，而云开发同时向非常多的应用提供服务，需要很高的并发支持。所以在高并发上我们作了更多的优化。

InfoQ 前端之巅： 小程序云开发项目中的实时推送系统主要基于什么需求背景？

周子杰： 需求背景主要有两方面：

• 一方面是小程序云开发本身有提供云数据库的功能，在此基础上我们考虑对它做更好的封装，从而给用户提供更好的体验，满足更多的场景。

• 另一方面是很多用户给我们提出了这样的需求（比如直播的弹幕功能，他们希望有实时消息推送的功能）。他们希望云开发能提供 WebSocket 的功能，就是希望有能通过后台直接往前台推送消息的功能。因为如果没有这个功能，用户就要自己去搭 WebSocket 服务，他们自己搭建的服务可能无法保证良好的可靠性和并发性。如果要提供良好的性能，需要的开发成本会很高。于是，为了满足用户的需求，我们就立项做数据库的实时推送系统，我们的愿景是：希望实时推送能成为一项服务，不局限于推送数据库的实时消息，只要你需要，它可以推送任何的消息。目前只是基于数据库的消息推送，就是数据库的数据被修改后就将最新数据推送到前端。未来实时推送做成一项服务后，只要有数据消息（可以是自己自定义的一个消息），就可以往前端推送。

InfoQ 前端之巅： 现在 Serverless 的概念比较火，小程序云开发又是一款 Serverless 服务，他为开发者提供了云函数、云数据库和云文件存储等功能，请你解释下采用的云数据库与普通的关系型数据库在数据存储上有什么区别？为什么选取云数据库？

周子杰： Serverless 是一个模糊了前端跟后台关系的概念。云开发是对 Serverless 的一个落地实践，但比一般的 Serverless 服务相比，又增加了数据库、文件存储等基础能力，构成一个完整的、可支持小程序、Web、安卓等开发的应用服务中台。对于一个前端开发人员来说，可以通过云开发去做一些后台功能，很大程度上减少了前后端的沟通成本。

云开发的数据库与普通的数据库区别是这样的：传统的后台服务需要先部署 MySQL 或 MongoDB 等数据库，然后通过后台服务去操作数据库，再往前端提供接口，前端同学如果想操作数据库的话必须通过接口，这中间的沟通成本非常大。

云开发的数据库其实是一项服务。从开发的整个链路来看，与传统的开发没什么区别的， 它也需要建立自己的后台服务，只是云数据库相当于一个桥梁，处在连接后台服务和前端的位置，主要是面向前端开发人员使用的一项数据库服务。云开发的数据库不需要后台提供接口 API 了，前端同学只需要写几行调用代码，就可以实现数据库的增删查改，他们也不用再关心后台用了什么数据库、如何搭建等问题，沟通成本和使用成本都降低了很多。用户可以更聚焦于自己的业务，不用操心其他配置的事情了。

InfoQ 前端之巅： 在开发实时推送系统时有没有遇到一些技术痛点？如何解决的？

周子杰： 现在面对最大的技术痛点是如何支持更多的实时连接数。数据库实时推送是一个新的模块，实现高可用不是一个简单的事情，在第一次压测时，我们 8 核的机器最高支持的连接数大概只有几千，经过几次优化现在已经有非常高的并发和可用性。后续还会持续进行优化迭代，以更好的应对高并发需求。

InfoQ 前端之巅： 在搭建数据库的实时推送系统的过程中，需要考虑哪些因素？怎样保证低延时、高并发、高可用性的性能呢？具体采用了哪些做法？

周子杰： 实时推送项目是腾讯云与微信小程序合作的功能。从整体架构上分成了三个模块：小程序的前端 SDK、中间接入层和后台。他们分别承担的业务为：

• 小程序的前端 SDK：这个业务需要在前端做些逻辑去保证服务的可靠性。然后在提供一个简单的接口给前端同学用。这部分由微信小程序的同学负责的。接入层和后台的工作由我们团队来负责的。

• 中间接入层：其任务是与前端保持 WebSocket 长连接，接入层会去后台轮询，取到最新的消息事件后就发送给前端。

• 后台：就是一个比较传统的服务，在这一层监听到最新消息就返回。

为了保证数据的可靠性和完整性，在做模块设计时，我们采用互不信任的原则，即上述三个模块之间是互不信任的。为此，我们做了很多的冗余设计。如果系统中的某一模块没有调用成功，我们会采取一些措施来弥补这个缺失。比如说小程序的 SDK，它会定期的去接入层查询最新消息事件的版本号，如果查到与本地的版本号对不上，它就会重新拉取一下这个消息事件。这样即使出现数据丢失或者网络连接断掉的异常情况时，依然能保证数据的可靠性。

为了保证低延时，除了在接入层提供 WebSocket 接口以外，后台所有的业务都使用了基于 TARS 框架的 RPC 通信，TARS 是一个成熟的开源框架，其性能很好。

为了处理高并发，我们持续优化接入层，让其尽可能的维持更多的实时连接。

InfoQ 前端之巅： 实时推送系统在未来有什么计划？

周子杰： 目前推送系统的核心功能已经开发完成，在多款腾讯内部小程序 / 小游戏进行内测，计划将于 8 月下旬正式对外开放。此外，在产品层面，我们将对接入层做进一步优化。前端要跟后台、接入层打交道，需要接入层提供 WebSocket 来保证长连接服务。只有长连接服务的存在，才可以给客户端推送消息，所以为了保证同一台机器能支持更多的长连接服务，我们要对接入层机器上部署的业务做裁减，目的是为了把接入层的服务做地更轻量，然后把更多的服务交给后台来做。就等于说接入层是一个非常轻量的服务，只需要保持长连接的功能，接入层其他的一些功能移到到后台去做了。

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

https://mp.weixin.qq.com/s/vRzdEG-GDjgIowe7u9uh5A