作者简介
潘斐斐，携程无线平台研发部高级研发工程师。2008年加入携程，目前负责携程Node.js技术栈的基础平台研发工作。
携程在2017年9月份正式上线了Node.js应用，本文主要介绍近两年Node.js技术栈在携程的应用和体系情况。
一、技术栈
应用部署主要分为以上四个步骤：Develop-> Build ->Release -> Publish
Coding阶段会使用脚手架和中间件开发应用，中间件后面会介绍到。
Build Docker会负责源码的构建功能，包括一些C++模块的编译和集成环境，同时会设置构建的缓存机制。
Release Docker负责应用的启动和运行，相对轻量级，更需要关注的是Docker的数量、CPU、内存等基础信息。
Publish负责应用启动之后的健康检查，健康检查完成之后会将Docker拉入集群并提供外部访问。
1.2 版本选择
在Build阶段，会选择Node.js的版本。提供了三个固定版本分别是v6.10.2，v8.9.4 和 v10.15.1。目前 v6.10.2 版本已经基本进入非维护阶段，并逐步更新下线，版本的更迭与Node.js官方几乎保持同步，为保证性能最优，推荐优选最新的LTS。
当时选择Node.js固定版本是考虑到编译环境的简单和稳定性。Node.js中间件和第三方库都需要做预编译，为了保证编译环境的简单和应用稳定，会选择固定的某一个版本。
同时针对这3个固定的版本，中间件发布的时候，也会一并提供window/linux/mac这3个平台预编译的包。Linux预编译包是为了Build Docker和Release Docker准备的，windows和mac预编译的包是为了开发工程师本地开发的时候准备的。
“靠前构建原则”
如果能在线下编译的尽量线下编译，不要在运行构建。例如：
C++模块的预编译
访问SOA或者数据库的环境配置
Babel或者TS
二、运维与监控
Node.js应用部署在Docker上，采用Nginx+PM2的模式。
2.2 核心指标
Nginx会监控整个Docker上所有应用的情况：
1）CPU util：CPU总的使用率
2）CPU throttle count&time：CPU被限制的次数和CPU使用率被限制的总时间。这两个指标的上升一般表示应用有CPU密集型操作，需要检查一下是否有大量的计算等操作。
3）Mem RSS used：这个指标上升一般显示应用内存泄漏的问题。
4）HTTP imcoming&outgoging：http request的数量变化趋势。如果有错误响应或者超过了告警的阈值，则会在趋势图中显示。
5）Connection reset：这个指标如果上升，表示应用出现了大量的拒绝请求，例如是服务器的并发数超过了原本的承载量等原因。
Nginx中监控的是整个Docker的情况，但是我们更需要的是监控应用的指标。
应用一般采用PM2 cluster – i max模式启动，最大化利用CPU。
1）Heartbeat（心跳信息）
每个worker一分钟发送一次Heartbeat（心跳信息）给到CAT数据中心。一般来说，如果Heartbeat告警的话，需要立刻查看一下错误日志，是不是有异常错误导致进程已经退出了。
Heartbeat主要包括CPU、Memory、网络信息等。这些信息和上述提到的Nginx信息不是一个维度的。这个更细节的关注了应用的情况，而不是整个Docker的情况。如果需要分析应用细节的问题，是需要查看这里的Heartbeat信息。
2）性能情况
一般来说，中间件会处理应用常规的性能日志记录。包括：
每一个响应的请求耗时（服务端逻辑处理耗时，不包括网络耗时）
每一个Transaction的耗时。一个Transaction可以简单理解为一个有功能意义的代码片段。
跨应用调用的请求耗时
3）错误/告警信息
错误告警信息是应用中需要重点关注的，包括：
应用逻辑出错，例如处理JSON数据出错等。
HTTP请求出错，会记录状态码、请求地址、返回内容
应用中使用了不同版本的同一个包，会报一条告警信息通知开发工程师
4）详细数据日志
详细数据日志一般有开发工程师针对应用的逻辑埋点，而非中间件统一处理。这些日志会包括返回数据的记录，具体运行在哪一段transaction中。这些日志一般是故障发生时，用来复盘时的辅助手段。
2.3 监控模型
一开始的监控日志是扁平化的，只能看到一条一条简单的日志，但无法将他们的关系串联起来。为了方便排障，设计了调用树的模型，可以将应用中的多个transaction串联起来。
应用发布上线后，需要关注系统的保障通知。经常遇到的故障是发现随着时间的推移，Mem RSS Used这根线会不停的飙升。
遇到这种情况，基本猜测是发生了Memory-Leak（内存泄漏）。我们需要分析heapdump来定位具体的问题点。
不建议在应用中定期发送heapdump的信息来监控，比较消耗内存。所以我们一般在发布到测试阶段，发现问题之后，采样几个不同时间点heapdumpsnapshot进行比对。使用的是开源的heapdump。
首先将两份snapshot文件加载到chrome中，查看statistics，对比这里的内存变化和Docker中的内存变化。
如果两者的变化一致，那么就说明内存泄漏的确发生在Heap区域，那么就可以进行两份snapshot的对比。
如果两者变化不一致，Docker变化量明显比Heapdump的多，那么就说明内存泄漏可能出现非Heap区域（堆外内存区域），需要查看一下snapshot中Buffer的数量是否有变化，是不是buffer导致的，或者查看一下Node.js的官方的changelog是否有提到memory issue。
三、公共服务
SOA client：SOA客户端主要负责调用JAVA/.NET/Node.js等各技术栈的SOA服务。主要服务于数据聚合的场景。
1）Ceph（资源存储客户端），主要存储静态资源，包含JS/CSS/图片等；
2）Redis（Redis客户端），为应用提供Redis缓存服务；
3）Kafka （消息系统） 消息生产者和消费者；
3.3 缓存服务
缓存中间件Cache主要解决以下问题：
实现跨进程共享内存和跨进程锁。(参考开源模块node-shared-cache )
1）监控模块目前携程Node.js支持三种场景的日志
场景一：CAT日志埋点，树状结构展示日志,监控服务运行快慢、监控异常、以及自定义事件监控告警。目前携程CAT已开源 CAT
场景二：可通过特定事件、特定时间、特定tag值过滤查询日志
场景三：可基于时间序列查看各种性能数据聚合结果，如统计某个中间件使用次数、某请求结果的平均值等。
2）foundation-framework基础模块
为不同环境下所有应用提供统一的获取AppId、环境等基础配置的API
提供IPv4、IPv6的检查和IPv6的全地址转换
3）qconfig-client 该中间件支持从携程内部服务配置中心获取不同文件类型的配置，支持配置热更新。
4）携程Node.js还提供：获取mysql数据库连接信息、ABTest、pm2跨进程通讯等功能模块。
为支持DR，nodeJS中间件做以下处理：
1）服务连接失败重试机制。
2）通过IP地址访问服务时，需定时重新获取服务IP地址。
3）同一服务存在多个IP地址时，依次通过不同IP地址访问服务，直到成功或全部失败。
4）特定数据缓存。
在某个服务器宕机或某个IDC机房毁坏情况下，目前nodeJS中间件大部分无需任何操作，可自动恢复；部分中间件需重启应用，以保证应用可用性和数据的实时性。
四、应用场景
图3 Introduction of BFF(Backend for Frontend)
(摘自https://www.jianshu.com/p/eb1875c62ad3)
DA这一层主要的功能是能够提升加载速度，降低重复的数据逻辑处理。
在DA之前，前端展示一般需要请求多条服务做数据聚合。更复杂的情况是，如果需要适配多个平台(Web/Android/IOS)，那么就需要服务写多个接口，造成重复的开发和维护工作。
DA主要负责将数据做逻辑处理，包括缓存、展示限制等，为前端提供更轻量级的服务。
本着“服务自治，服务于UI”的原则，我们用前端工程师更熟悉的JavaScript开发是非常合适的选择，可以降低学习和开发成本，带来更大的灵活性和高效性。实践下来，引入了数据聚合层之后，性能提升在20%左右。
4.2 SSR（Server-SideRendering）
服务端在携程的引入主要考量有几点：
1）SEO的.NET+V8的老架构
2）SPA模式首屏性能问题
3）JS技术栈陈旧等诸多问题
4）不同平台重复编码，无法实现代码同构
所以设计一套SSR的框架来解决历史问题，最终带来了30%的开发效率提升和20%的性能优化。
目前携程的SSR框架是NFES，感兴趣的同学可以点击详细了解。
4.3 内部工具
Node.js技术栈的内部工具，主要在几个方向：
1）构建工具，例如发布平台中的Node.js应用的构建工具
2）跨平台的GUI的工具，一般基于electron框架开发
3）静态资源的发布
五、小结
经过一年多的积累，携程已经上线500+的应用。这一年多，我们比较关注的方向是中间件建设和应用性能的监控优化，后续将计划实践一些Node.js技术栈的框架建设和工程化方向，希望能通过更稳定的基础设施，探索新的应用场景，提升开发效率。
【推荐阅读】
421
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
