微信小程序云端解决方案探索之路

小程序刚推出的时候，不少人都以为它就是 H5，由于开发小程序的三大语言和 HTML、CSS、JS 是一脉相承的，即便改变了扩展名也改不了其实质。

那么小程序的实质究竟是不是 H5 呢？通过咱们的论证分析，咱们认为小程序并非 H5 应用。主要缘由以下：

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

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

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

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

门槛和挑战

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

会话管理

咱们最先开发了一个一笔到底的案例来实现会话管理，案例须要根据用户保存用户的做品，每次用户登陆，均可以看到用户本身的绘画。

可是，由于小程序不支持 Cookie 传输，因此会话服务须要自行实现。

咱们会话管理的实现目标是：

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

咱们案例按照这个流程进行会话创建：

其中在小程序和服务器咱们分别提供 JS 和 Node SDK 来提供会话支持。这个案例完成了会话服务的功能性目标，能够提供会话创建和验证的能力。可是弊端在于，该能力只能被 Node 开发者使用，其余语言的开发者没法使用。同时，由于小程序的 appId 和 appSecret 存放在外网能够访问的服务器上，也有必定安全性问题。会话服务和咱们的业务耦合在一块儿，也给后续的横向扩展带来了麻烦。

因而，咱们提出了改进的手段：

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

其中多语言的 SDK 正式由于会话管理服务器的独立而能够快速开发到。

优化后，会话的创建流程以下图所示：

而会话的验证流程以下图所示：

咱们的会话服务改进取得的效果仍是很明显的：

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

信道服务

咱们面临的另一个挑战就是 WebSocket。在进行案例分析以前，先跟你们分析一下微信支持 WebSocket 的缘由。

传统的 HTTPS 链接请求，每一个请求都须要创建一次链接，耗费比较多的资源。同时微信有最大链接数的限制（5个），因此实时通讯的需求很差作，长链接的方案也只能串行传输，这种方案耗电高体验差。

当咱们把目光转向 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 其实是要实现一个三方通讯。

咱们看一下使用 PaaS 服务来创建 WebSocket 链接的过程：

创建链接后，小程序和业务服务器之间能够经过下面的形式进行通讯：

通过 PaaS 的改造，咱们获得了一个新的 WebSocket 方案。该方案的优劣在哪里？

首先，优点比较明显，由平台来提供的服务，由平台本身完成扩展能力的支持以及稳定性和性能的保障，业务无需担忧。同时，业务也无需关心 WebSocket 协议的实现，由于业务服务器和信道服务以前的通讯都是传统的 HTTP，这样也能够节约业务服务器的长链接资源。

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

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

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

整合

咱们上面对于会话服务和信道服务都进行了一个有益的实践，那么这两个服务是否能够整合，信道服务里面是否能够支持会话识别？

事实上咱们能够作这个事情。下面的表格描述了会话服务和信道服务与服务模块之间的关系。

咱们能够把客户端的部分整合为客户端 SDK，把业务服务器的部分整合为服务器 SDK，而且提供会话服务器的源码开源。

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

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

产品化实践

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

这个方案，会帮你分配好资源并自动部署下面的架构，让开发者能够专一于业务开发。

自动部署的过程其实挺复杂的，有兴趣的同窗能够参考下图了解。