2018年去哪儿网+Node.js+实践及性能监控方案.pdf

1、去哪儿网 Node.js 实践及性能监控方案2018.06去哪儿网前后端分离方案和静态资源离线包Node.js 和 React SSR 实践应用和性能监控方案1.项目分离，页面分离发布系统前端js/css后端vm2.项目分离，部分页面分离发布系统前端js/css/vm后端3.Node.js 作为页面渲染层静态资源离线包方案（qp）项目中如何使用 qp 包在项目根目录中，新建 index.yaml 配置文件唯一id针对的 iOS 和 Android 版本打包内容忽略内容使用打包平台发布，无需人工干预用户对离线包完全透明，且无感知。需要考虑的问题保证资源的安全性，不被中间人恶意篡改传输安全和存储安

2、全，使用 RSA 加密快速回滚原来假回滚（重新发版）-真回滚下线和强制更新下线：针对当前包强制更新：将要下载的包提高更新率减少 qp 包的大小使用 HTTP2 协议使用差分包而不是全量包http:/ 2 小时内达到 90%离线包更新率效果（强制更新）普通更新通常7，8个小时后才能稳定在75%左右离线包更新率效果（普通更新）第一部分总结去哪儿网三种前后端分离方案，以及各种方案的优缺点和适用情况简要介绍静态资源离线包实现方式和部分细节Node.js 和 React SSR 实践去哪儿网前后端分离方案和静态资源离线包应用和性能监控方案为什么没有大规模使用？一些前端开发，只关注浏览器端，服务器端开发关

3、注很少，或者根本就不关注;认为 Node.js 只适合开发一些工具类的功能，对于后端开发是个玩具;Node.js 的生态不如其他后端语言生态健全;涉及到后端开发的知识面比较广，在没有这些基础知识或者经验积累的基础上，考虑问题比较片面，最终做出的系统问题比较多，容易被后端鄙视;对于 Node.js 开发后端，对项目负责人要求比较高（项目的目录规范，开发规范，系统的安全性，稳定性，可靠性，扩展性，维护成本等）;以往前端不需要 7 x 24 保持待命状态，但是接触后端后，需要接收报警短信，有时出现问题还需要马上随时随地解决;提高开发效率（不用 Nginx，代理工具等等）降低沟通成本（除接口格式外，不

4、需要和后端交互）前后端职责更新清晰-后端生产数据，前端消费数据可以使用 React SSR 技术-首屏渲染、SEO 等RESTful API-自身使用或对外提供，不依赖后端Node.js 能解决哪些问题和痛点？1.如何确定项目目录划分的规范，命名规范（view or views）2.确定规范后，如何保证大家都认可，并且严格遵守3.如何保证系统的安全性，稳定性，可扩展性4.守护进程程序的选择（pm2 or supervisor）5.多环境运行规则（local/beta/prod）6.如何利用系统 cpu 多核，以及多进程之间的通信三年前所用框架的问题（基于express）重新选择框架Or在文档说

5、明、框架扩展、插件数量、部署流畅性以及开发体验上，最终选择的是 Egg.js。插件开发egg-qversionegg-qconfigegg-qwatcheregg-accesslogegg-healthcheckegg-checkurlegg-swift1.不能利用发布系统中相应的端口和目录字段，只能在 qunar_xx 服务中写死，不友好2.不能区分多环境策略。比如：beta 环境和 prod 环境配置规则不一样3.启动过程中出现错误，不方便定位问题，需要到机器上排查4.写系统服务需要了解 shell 命令和系统服务格式，对于前端开发同学，成本稍高5.除了端口、项目路径、运行环境，node.

6、js 启动方式外，处理逻辑相似原来部署流程（service 方式）问题改进后的部署方式在项目中建立 deploy_scripts 目录，新增 start.sh（名称可以随便命名）在 start.sh 中填入 Node.js 启动逻辑，比如 node index.js(之前是 N 行，如今最多两行)在发布系统选择 node 发布方式，填入端口号，发布路径，以及启动脚本名称（start.sh），停止脚本填入发布系统内置的 stop.sh（按照端口杀掉进程）start.sh 样例R