H5开发在QQ钱包的应用实践

2015年我们正式成立了钱包团队，从刚开始QQ钱包只有一个钱包入口，一直发展到今天，已经开发出了话费充值、卡券、积分、企鹅网吧、城市服务以及智慧校园等一系列服务。

QQ钱包H5应用日均pv在1000w以上，推广期pv可达上亿的级别，需要解决服务器性能优化问题。

为了提高用户的体验，需要尽快的吐出页面，安卓平台下一般要求为3秒，而在ios平台则是要求2秒以内，在某些业务场景下直接要求秒开。

移动端特别是安卓平台的web性能容易造成瓶颈，例如长列表渲染问题，图片内存占用问题，css3动画性能问题都需要去解决。

ServiceWorker是浏览器为了解决之前AppCache在管理离线缓存上的不足，而提供的在Web应用程序与服务器之间的代理层。

总的来说，Service Worker就是一段在浏览器后台自动运行的程序，负责协助浏览器，管理和响应所有从Web应用发出的请求，以达到更好的离线体验。

性能有所增强，比如预取并缓存用户可能需要的资源，比如页面中所需的静态资源文件；可以同步后台数据同步；响应来自其它源的资源请求；集中接收计算成本高的数据更新；后台服务钩子；自定义模板用于特定URL模式以及可以在客户端进行模块编译和依赖管理。

到达installed态的Service Worker并不会直接进入activating态，如果浏览器中还有其他页面运行着该Service Worker的一个旧版本，那么新的Service Worker就会处于等待的状态，直到其他页面关闭。这主要是为了避免Service Worker中所使用到的资源被意外释放。

一旦其他相关页面都关闭了，就意味着旧的资源文件已经不再需要。这时候我们就可以执行下一步清理的工作。

QQ钱包团队搭建了一套MoggyCache离线包管理系统。通过这套系统我们可以针对项目配置当前项目需要用到的静态资源。并且配置了离线包当前是否开启，或者是针对灰度用户进行开启。都可以配置到这个平台上，而且存储在内部的一个DB上。

我们的node.js服务通过读取上述的配置动态生成了两个脚本，一个是install脚本，一个是worker脚本。

install脚本主要是读取离线包当前的一个开关以及它当前灰度用户的策略，来判断当前用户是否需要安装我们的离线包。

一旦判断出用户需要安装离线包，它就会通过注册的过程把worker脚本注册成当前页面的Service Worker。而这个worker就会把配置里的资源列表下发到worker脚本里面。Worker就会走一遍流程把这些资源加载并缓存在本地。

以上过程仅仅是简化了我们的一些工作，还是没有解决问题。所以我们在这基础之上又新增了它的几个特性。

我们每次配置一个项目的时候，会计算出所有资源的md5，并且存储在DB里面。然后我们的node.js服务就会读取到刚才的配置，把md5下发到刚才的Service Worker里面。

现在我们更新资源需要进行发布的时候，在发布系统上面添加了一个后置脚本，一旦资源发布，这个后置脚本就会触发离线包系统，去重新计算每一个资源的md5，并重新推送到Service Worker。

这时Service Worker就有了两个md5，一个是旧版本的md5，一个是当前最新的版本。通过对比这两个md5，我们就知道哪些资源已经过期了。当发现了过期的资源，Service Worker就会重新到服务器上拉取最新资源。整个过程是自动的，无需人工干预。这就解决了不可靠的问题。

每当有新资源发布的时候，我们都会通过后置脚本的方式通知MoggyCache系统。它就会读取新的资源并进行计算，算出格式的增量包，然后把增量包存储在服务里面。

因为md5已经更新了，所以worker脚本就会重新发送请求到我们的服务。这时如果服务发现资源有可用的增量包，就会把这个增量包直接返回给Service Worker。Service Worker通过判断请求头就可以执行不同的策略。

在QQ钱包成立初期，我们使用的接入层架构是PHP + APACHE。当时PHP的版本非常成旧，我们需要开20台服务器才能完成所有请求的响应，而单机的QPS只有200。

从这些数据里可以看出性能还是不够好。再加上PHP用了腾讯内部编写的一些私有模块，各个模块之间又有不同的版本，导致它还有部署成本高，扩容困难，apache日志缺漏，web服务缺乏监控等一系列问题。

经过一段时间的考察，我们最终选择了NODEJS。

性能优异：node.js采用的是基于libuv库的异步io方案，相比apache的多进程同步阻塞方案在性能上的提升明显的。

前端友好：前端熟悉js的语法，对node.js可以平滑过度，培养新同学更为简单容易。

社区成熟：成熟的社区和完善的技术文档，大量的成熟模块可以为业务使用。

应用场景：我们的MoggyServer服务，主要的使用场景是页面直出。

更加可控：自研的框架，更加可控，扩展性更加强，这些都是我们需要考虑的。

稳定和快速：社区里的框架大多会包含类似静态文件处理，json数据处理等额外的功能，这并不是我们想要的。

我们把服务器平滑重启的逻辑内置到框架里面。通过在发布系统上配置一个后置脚本来通知node.js的子进程有新的文件要发布，并在子进程接收到消息之后把这些消息通知发送给旧的子进程，它就会停止对外服务。

因为新的代码已经发布到线上，就可以用新的代码重新创建新的子进程。旧的子进程把原本还在服务的用户处理完后就会把自己注销掉，整个过程就能达到平滑的效果。

我们用积分将一个业务的页面进行10000次渲染，然后统计它所花费的时间。

这里我们主要是对ejs的模板嵌套语法做了精简，所以有了性能上的提升。

用传统的ejs渲染需要7500毫秒，而用tpl渲染只需要920毫秒。这就是我们做的模版引擎的优化。

QQ钱包现在只运行了7台服务器，就完成了上千万级别的服务量。单机QPS从200已经提升到了900。2017年初，我们的总请求数峰值已经到达了1.69亿，申请了57台机器去支撑，但每台机器的CPU只用了30%。

传统页面加载方案：从用户点击入口，native再去拉起webview，等待webview初始化完成后发送http请求去node服务拉取页面数据，最后对页面进行渲染。

相对传统加载方案中，优化方案在native执行时候实例化webview，同时并行向sonic服务器发起请求，将此前的串行操作优化为并行，因此此处耗时由sum(webview,request)转变成max(webview,request)，降低了客户端层面的耗时。

sonic支持对h5页面级进行本地缓存，将返回的页面分别拆分成数据层以及模版层层分开来缓存，生成本地缓存文件，且缓存时长为永久缓存，如果页面是没有任何变化，这时候会完全显示缓存的数据。

对于页面更新的情况，sonic会去对比和计算客户端缓存中的页面的变更地方，封装成json数据结构返回给客户端进行页面更新以及缓存更新，这样可以大大减小了回包的大小，特别对于移动网络而言可以大幅度为用户节省了请求流量。

我的分享就到这里，谢谢大家！