去哪儿 Serverless 性能优化及高可用

作者介绍

• NodeJs 在计算上单线程的特性使得其在运算能力较薄弱，无法应对计算量大的场景
• 缓存内容散乱，没有进行统一的管理

以标签组件的配置为例，其包含标签内容、标签UI、展示位置、展示条件等属性，我们会依据这些属性，结合酒店的信息来为其不同房型展示不同的标签。

从整体来看，要展示一个酒店内所有的标签信息，需要经过房型数目* 标签配置 * 酒店信息的匹配计算，线上数据的监控显示，其整体响应的计算时长 P99 均值达到 400ms 左右，速度较慢。

1. 线程的数量问题

• 数据长度位：表示当前要修改的数据内容的长度，置于 buffer 0 位

• buffer 修改 mutex 位：表示当前 buffer 是否正在被操作，置于buffer 1 位

• 线程数目位：表示当前线程池中的线程数目，置于 buffer 2 位

• 线程状态位：表示当前各个线程的工作状态，置于 buffer 3 位 ～ (3+线程数目) 位

• 线程数据位：表示当前要修改的内容，置于 buffer (3 + 线程数目 + 1) 位 ～ (3 + 线程数目 + 1 + 数据长度) 位

方式比较

我们对两种方式进行了初步的实现，以一条线上的数据为参照，来做两种方式进行线程通信耗时的比对：

可以看到，在线程调度方面，由于 sharedBuffer 方案中通过记录各个线程的状态，可以很明确的知道要调度的空闲线程，相比 postMessage 去轮询，它的耗时非常小。

而在数据传递方面，sharedBuffer 由于要传递的数据包含对象等类型，从 buffer 中对其存取需要一些列的转换，相比 postMessage 要慢不少。

再从数据传递、数据操作和异常处理方面进行分析：

sharedBuffer 由于数据的操作都是 buffer 上进行的，读取buffer转为可用数据的操作时间较长， 且直接操作和截取buffer的过程对于我们是不可知，有风险的，相比于 postMessage 的消息即用，我们并不能确保截取操作后的buffer经过转换后依然是可用的数据对 象。

在异常处理方面，postMessage 可以将异常消息主动发送给主线程，而 sharedBuffer 由于存在 Atomics.wait 的使用让某些线程阻塞的情况，如果因为其他线程异常而不去唤醒该线程，则该线程可能会是一直阻塞的状态。

（三）方案设计

综合考虑两种方式，我们决定将两种方式进行结合，取 sharedBuffer 直接感知各线程的优势和 postMessage 消息即用的特点，设计了以下方案：

• 配置类数据缓存

• 可枚举计算结果的缓存

• 预热配置：

• 缓存隔离：

• 操作监控:

方案实践

通过对函数的缓存增加服务初次启动时函数实例的命中率，对冷数据缓存增加函数在初次执行时对缓存数据的命中率，执行时间的波动成功降下来了，当前波动从原来的 30ms 到现在保持在 10ms 以内。

通过数据缓存层，我们成功使得函数的调度响应平稳下来，实现了数据接收和缓存配置的可拓展性，减少了因缓存未命中的时间波动。数据缓存层通过定时任务主动触发缓存数据的更新，未来还会加入由 qunar 自主研发的 qmq 消息队列以被动接收更新的形式获取要更新的缓存数据进行拓展。

五、接入效果

在国庆高流量下，Neeko 标签函数整体耗时下降，P99 从 400ms 降低到152ms 降低 72% ，响应时间无波动：

调用量级：

优化后：