微信小程序云端解决方案探索之路 - GITC 主题演讲

在刚结束的全球互联网技术大会(GITC)里面,我在前端专场给大家分享了「微信小程序云端解决方案探索之路」,介绍到了我们之前对小程序云端解决方案的探索过程。

小程序特性思考

小程序刚推出的时候,很多人都觉得它就是 H5,因为开发小程序的三大语言和 HTML、CSS、JS 是一脉相承的,即使改变了扩展名也改不了其实质。

那么小程序的实质到底是不是 H5 呢?经过我们的论证分析,我们认为小程序并不是 H5 应用。主要原因如下:

  1. 在小程序里面无法使用 DOM 接口,所以 HTML5 生态中一切基于 DOM 的库都无法使用(如 jQuery)
  2. 小程序并非使用 URL 访问,所以没有域名的概念。这个特性有两个影响
    • 不存在跨域问题,所以访问控制是直接在微信 MP 上配置域名白名单
    • 不支持 Cookie 存储,这将导致后面我们重点研究了会话管理的实现

从上面两个角度来考虑,我们认为小程序更偏向于传统的 CS 架构

那么,小程序和传统 CS 架构的区别在哪儿?主要包括下面两点:

  1. 网络和续航 小程序在移动端运行,网络环境会比较复杂,频繁的网络连接可能会过度消耗资源导致续航下降,所以小程序对网络和资源的优化都提出了要求。
  2. 伸缩能力 小程序寄托在微信平台上运行,作为一个十亿级的社交平台,业务可能会面临爆炸式的增长。如果在爆点小程序不能快速伸缩应对,那么将失去这样一个重要的机会。所以小程序对其后台架构的伸缩能力提出了比较高的要求。

门槛和挑战

在上面一些结论下,我们进行了一些尝试,包括上传下载、会话管理、WebSocket、视频点播等等。这次重点来分享会话管理和 WebSocket,因为我们面临的挑战主要集中在这两个案例上。

会话管理 <a name="session"></a>

我们最早开发了一个一笔到底的案例来实现会话管理,案例需要根据用户保存用户的作品,每次用户登录,都可以看到用户自己的绘画。

但是,因为小程序不支持 Cookie 传输,所以会话服务需要自行实现。

我们会话管理的实现目标是:

  1. 完成微信要求的鉴权流程,生成用户会话
  2. 利用会话确定每个请求对应哪个微信用户
  3. 安全性和扩展性满足要求

我们案例按照这个流程进行会话建立:

会话建立流程

其中在小程序和服务器我们分别提供 JS 和 Node SDK 来提供会话支持。这个案例完成了会话服务的功能性目标,可以提供会话建立和验证的能力。但是弊端在于,该能力只能被 Node 开发者使用,其他语言的开发者无法使用。同时,因为小程序的 appIdappSecret 存放在外网可以访问的服务器上,也有一定安全性问题。会话服务和我们的业务耦合在一起,也给后续的横向扩展带来了麻烦。

于是,我们提出了改进的手段:

  1. 会话管理服务器独立提供
  2. 提供多语言的 SDK
  3. appId 和 appSecret 存放到数据库中

其中多语言的 SDK 正式因为会话管理服务器的独立而可以快速开发到。

优化后,会话的建立流程如下图所示:

会话建立流程

而会话的验证流程如下图所示:

会话检查流程

我们的会话服务改进取得的效果还是很明显的:

  1. 流程和安全性上完全符合了微信的鉴权要求
  2. 独立会话服务器,可以方便进行独立的升级和扩展,也为多语言 SDK 的开发打开了方便的大门

信道服务 <a name="tunnel"></a>

我们面临的另外一个挑战就是 WebSocket。在进行案例分析之前,先跟大家分析一下微信支持 WebSocket 的原因。

传统的 HTTPS 连接请求,每个请求都需要建立一次连接,耗费比较多的资源。同时微信有最大连接数的限制(5个),所以实时通信的需求不好做,长连接的方案也只能串行传输,这种方案耗电高体验差。

当我们把目光转向 WebSocket 之后,会发现 WebSocket 通信全程只需要建立一次连接,就可以实现双向的实时通信,更省电的情况下获得更好的体验。

这就是小程序支持 WebSocket 的一个重要原因,可以提高业务的体验并增加续航。

鉴于很多同学可能对 WebSocket 还不了解,这里简单介绍一下。

WebSocket 示意图

我们的 HTTP 连接是在 TCP 的基础上建立的,当服务器支持 WebSocket 的时候,可以相应一个头部,告知客户端进行协议升级。升级协议后,会复用之前的 TCP 连接,在上面实现 WebSocket 协议实现双向通信。更加详细的资料可以参考 MDN 上的说明。

回到我们的案例上来,我们当时使用小程序提供的 WebSocket 做了一个实时的剪刀石头布游戏。

游戏截图

我们使用 Socket.IO 实现其后端后,发现在小程序无法使用 Socket.IO 的客户端代码支持。我们只能自己去啃了一下 Socket.IO 的上层协议,实现了一个简版的客户端,从而实现剪刀石头布这个游戏逻辑。

这个案例验证了在小程序上面 WebSocket 的可行性,但是由于客户端的实现是自行实现,和 Socket.IO 的后端配合可能会出现不可控的情况。同时,我们发现 WebSocket 的后端实现门槛比较高,并且进行横向扩展的话会更加困难。

作为云服务厂商,我们首先想到的方案是使用 PaaS 提供服务来支持 WebSocket 连接。这是怎么一个思路呢?

PaaS 服务支持 WebSocket

上图很好地解释了 PaaS 形式和传统 WebSocket 形式的不同之处,PaaS 实际上是要实现一个三方通信。

我们看一下使用 PaaS 服务来建立 WebSocket 连接的过程:

建立 WS 连接

建立连接后,小程序和业务服务器之间可以通过下面的形式进行通信:

WS 通信

经过 PaaS 的改造,我们得到了一个新的 WebSocket 方案。该方案的优劣在哪里?

首先,优势比较明显,由平台来提供的服务,由平台自己完成扩展能力的支持以及稳定性和性能的保障,业务无需担心。同时,业务也无需关心 WebSocket 协议的实现,因为业务服务器和信道服务之前的通信都是传统的 HTTP,这样也可以节约业务服务器的长连接资源。

但是这种方案也有它的局限之处。业务服务器和信道服务器之间采取公网通信,处于对信息安全的考虑,最好还是走 HTTPS 通信,这个过程的通信延迟比较客观。其次,三方通信的调试便利性也不如传统的连接方式。

对于上面两个问题,其实我们也有对应方案。如果业务服务器在腾讯云机房运行,那么可以让业务服务器和信道服务器之间通过内网 HTTP 传输,延迟大大降低。信道服务后续也会提供调试日志供大家分析发现问题。

总体来说,PaaS 方案会帮助更多开发者解决掉了门槛较高的部分。

整合

我们上面对于会话服务和信道服务都进行了一个有益的实践,那么这两个服务是否可以整合,信道服务里面是否可以支持会话识别?

事实上我们可以做这个事情。下面的表格描述了会话服务和信道服务与服务模块之间的关系。

服务与模块关系

我们可以把客户端的部分整合为客户端 SDK,把业务服务器的部分整合为服务器 SDK,并且提供会话服务器的源码开源。

那么上面三个部分加起来,就是目前腾讯云的开源项目 - Wafer

Wafer 包含了会话服务和信道服务的支持,从全栈模块来提供开源的资源,并且提供了丰富的文档。有兴趣的开发者可以使用上面的连接来查看 Wafer 项目。

产品化实践

Wafer 定位

Wafer 帮开发者解决了小程序开发过程中信道服务和会话服务的门槛问题,但是作为小程序开发者,还要关心后台架构、资源采供、资源部署、扩展能力、安全性、域名申请等等与业务开发无关的部分。这部分,我们提出了一个一站式部署的方案。

一站式部署

这个方案,会帮你分配好资源并自动部署下面的架构,让开发者可以专注于业务开发。

整体架构

自动部署的过程其实挺复杂的,有兴趣的同学可以参考下图了解。

自动部署

上面就是 Wafer 的产品化实践 - 腾讯云小程序一站式解决方案。也可以扫码了解更多信息:

QR Code

总结

从 16 年 9 月份开始,团队开始接触微信小程序,对它的一个特性进行了思考和验证。在后面案例开发的过程中,碰到了会话服务和信道服务的两个门槛,不断优化,最终整合成了开源项目 Wafer 及其产品化方案,希望这些方案可以对小程序开发者提供帮助。

GITC 主题演讲的幻灯片可以在这里下载。

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

运维前后端分离的开发流程

既然说到前后端,其实现在的前后端分离和以前的不大一样了。本来前后端分离要解决的一个痛点是多端支持(电脑端,移动端-IOS,Android等)重复造轮子的现...

1003
来自专栏我是攻城师

欢迎来到被容器技术改变的世界!

3465
来自专栏BeJavaGod

网站平台架构演变史(一)

朋友公司的产品已经做了11个年头了,在餐饮业可以说数一数二,网站架构从原始的单一应用一直演变至今,已经十分庞大了,不说完美,但是可支撑的业务量已经十分强大。最近...

3174
来自专栏Rainbond开源「容器云平台」

好雨云帮一周问答集锦(11.21-11.27)

893
来自专栏ThoughtWorks

云与性能测试 | 洞见

近年来,随着云计算技术的发展和各种诸如AWS、GCP、阿里云等云平台的日趋成熟,越来越多的的用户选择把系统搭建在云端,因此云测试的概念随即产生。云测试看字面意思...

3868
来自专栏云计算D1net

欢迎来到被容器技术改变的世界!

如果你将容器整合到构建工作流程中,我们未来的多云环境的所有要素都开始落实到位。 现代应用程序取得发展很大程度上归功于方兴未艾的开发运营(DevOps)潮流以及...

33310
来自专栏web前端教室

大前端?/前端开发职位的未来方向/

对于许多新人来说,他们最开始接触前端这行,都是从前端开发工资高啊,好找工作啊,入门门槛低,这些方面开始了解的。当他们开始学习前端一段时间之后,许多人不可避免的开...

672
来自专栏哲学驱动设计

阿里如何实现100%容器化镜像化?八年技术演进之路回顾(转)

八年时间,阿里集团实现了 100%内部容器化镜像化,经历了几代演进。本文将从最初的架构开始,向大家介绍下阿里内部的容器化演化过程。

531
来自专栏IT技术精选文摘

互联网直播平台架构案例一

直播平台整体架构 ? 视频直播链路 ? 视频流转换成不同清晰度 不同的端,不同的网络环境,需要不同码率,以保流畅 ? 播放器的基本实现 ? SDK在播放器上做层...

2578
来自专栏云计算D1net

如何为稳定的云堆栈构建基础?

在我们完成云堆栈的构建工作——即实现平台即服务(简称PaaS)、规模化容器乃至开发工具集中的各类工具选项——之前,我们首先需要建立良好的操作系统基础以支持这些容...

32714

扫码关注云+社区