在刚结束的 全球互联网技术大会（GITC） 里面我在前端专场给大家分享了「微信小程序云端解决方案探索之路」介绍到了我们之前对小程序云端解决方案的探索过程。
小程序特性思考小程序刚推出的时候SEO关键词介绍到了我们之前对小程序云端解决方案的探索过程。
小程序特性思考小程序刚推出的时候很多人都觉得它就是 H5因为开发小程序的三大语言和 HTML、CSS、JS 是一脉相承的SEO关键词因为开发小程序的三大语言和 HTML、CSS、JS 是一脉相承的即使改变了扩展名也改不了其实质。
那么小程序的实质到底是不是 H5 呢？经过我们的论证分析我们认为 小程序并不是 H5 应用 。主要原因如下：
在小程序里面无法使用 DOM 接口所以 HTML5 生态中一切基于 DOM 的库都无法使用（如 jQuery）
小程序并非使用 URL 访问所以没有域名的概念。这个特性有两个影响
不存在跨域问题所以访问控制是直接在微信 MP 上配置域名白名单
不支持 Cookie 存储这将导致后面我们重点研究了会话管理的实现
从上面两个角度来考虑我们认为 小程序更偏向于传统的 CS 架构 。
那么小程序和传统 CS 架构的区别在哪儿？主要包括下面两点：
网络和续航 小程序在移动端运行网络环境会比较复杂频繁的网络连接可能会过度消耗资源导致续航下降所以小程序对网络和资源的优化都提出了要求。
伸缩能力
小程序寄托在微信平台上运行作为一个十亿级的社交平台业务可能会面临爆炸式的增长。如果在爆点小程序不能快速伸缩应对那么将失去这样一个重要的机会。所以小程序对其后台架构的伸缩能力提出了比较高的要求。
门槛和挑战在上面一些结论下我们进行了一些尝试包括上传下载、会话管理、WebSocket、视频点播等等。这次重点来分享会话管理和 WebSocket因为我们面临的挑战主要集中在这两个案例上。
会话管理 <a name="session"></a>我们最早开发了一个 一笔到底 的案例来实现会话管理案例需要根据用户保存用户的作品每次用户登录都可以看到用户自己的绘画。
但是因为小程序不支持 Cookie 传输所以会话服务需要自行实现。
我们会话管理的实现目标是：
完成微信要求的鉴权流程生成用户会话
利用会话确定每个请求对应哪个微信用户
安全性和扩展性满足要求
我们案例按照这个流程进行会话建立：
会话建立流程其中在小程序和服务器我们分别提供 JS 和 Node SDK 来提供会话支持。这个案例完成了会话服务的功能性目标可以提供会话建立和验证的能力。但是弊端在于该能力只能被 Node 开发者使用其他语言的开发者无法使用。同时因为小程序的 appId 和 appSecret 存放在外网可以访问的服务器上也有一定安全性问题。会话服务和我们的业务耦合在一起也给后续的横向扩展带来了麻烦。
于是我们提出了改进的手段：
会话管理服务器独立提供
提供多语言的 SDK
appId 和 appSecret 存放到数据库中
其中多语言的 SDK 正式因为会话管理服务器的独立而可以快速开发到。
优化后会话的建立流程如下图所示：
会话建立流程而会话的验证流程如下图所示：
会话检查流程我们的会话服务改进取得的效果还是很明显的：
流程和安全性上完全符合了微信的鉴权要求
独立会话服务器可以方便进行独立的升级和扩展也为多语言 SDK 的开发打开了方便的大门
信道服务 <a name="tunnel"></a>我们面临的另外一个挑战就是 WebSocket。在进行案例分析之前先跟大家分析一下微信支持 WebSocket 的原因。
传统的 HTTPS 连接请求每个请求都需要建立一次连接耗费比较多的资源。同时微信有最大连接数的限制（5个）所以实时通信的需求不好做长连接的方案也只能串行传输这种方案耗电高体验差。
当我们把目光转向 WebSocket 之后会发现 WebSocket 通信全程只需要建立一次连接就可以实现双向的实时通信更省电的情况下获得更好的体验。
这就是小程序支持 WebSocket 的一个重要原因可以提高业务的体验并增加续航。
鉴于很多同学可能对 WebSocket 还不了解这里简单介绍一下。
WebSocket 示意图