GMTC2018 《去哪儿网+Node,js+实践及性能监控方案》兴百放

2020-02-27 200浏览

1.去哪⼉儿⽹网 Node.js 实践及性能监控⽅方案兴百放 2018.06
2.
3.
4.• 去哪⼉儿⽹网前后端分离⽅方案和静态资源离线包 • Node.js 和 React SSR 实践 • 应⽤用和性能监控⽅方案
5.前端 1. 项⽬目分离js / c，ss ⻚页⾯面分离发布系统 vm 后端
6.前端 2. 项⽬目分离j，s / css部/ vm分⻚页⾯面分离发布系统后端
7.3. Node.js 作为⻚页⾯面渲染层
8.静态资源离线包⽅方案（qp）
9.• 在项⽬目根⽬目录中，新建 index.yaml 配置⽂文件 • 唯⼀一id 项⽬目中如何使⽤用 qp 包 • 针对的 iOS 和 Android 版本 • 打包内容 • 忽略略内容 • 使⽤用打包平台发布，⽆无需⼈人⼯工⼲干预⽤用户对离线包完全透明，且⽆无感知。
10.• 保证资源的安全性，不不被中间⼈人恶意篡改 • 传输安全和存储安全，使⽤用 RSA 加密 • 快速回滚需要考虑的问题 • 原来假回滚（重新发版） -> 真回滚 • 下线和强制更更新 • 下线：针对当前包 • 强制更更新：将要下载的包 • 提⾼高更更新率 • 减少 qp 包的⼤大⼩小 • 使⽤用 HTTP2 协议 • 使⽤用差分包⽽而不不是全量量包http://ued.qunar.com/qp/
11.强制更更新能在 2 ⼩小时内达到 90% 离线包更更新率效果（强制更更新）
12.普通更更新通常7，8个⼩小时后才能稳定在75%左右离线包更更新率效果（普通更更新）
13.第⼀一部分总结 • 去哪⼉儿⽹网三种前后端分离⽅方案，以及各种⽅方案的优缺点和适⽤用情况 • 简要介绍静态资源离线包实现⽅方式和部分细节
14.• 去哪⼉儿⽹网前后端分离⽅方案和静态资源离线包 • Node.js 和 React SSR 实践 • 应⽤用和性能监控⽅方案
15.• ⼀一些前端开发，只关注浏览器器端，服务器器端开发关注很少，或者根本就不不关注; • 认为 Node.js 只适合开发⼀一些⼯工具类的功能，对于后端开发是个玩具; 为什什么没有⼤大规模使⽤用？ • Node.js 的⽣生态不不如其他后端语⾔言⽣生态健全; • 涉及到后端开发的知识⾯面⽐比较⼴广，在没有这些基础知识或者经验积累的基础上，考虑问题⽐比较⽚片⾯面，最终做出的系统问题⽐比较多，容易易被后端鄙视; • 对于 Node.js 开发后端，对项⽬目负责⼈人要求⽐比较⾼高（项⽬目的⽬目录规范，开发规范，系统的安全性，稳定性，可靠性，扩展性，维护成本等）; • 以往前端不不需要 7 x 24 保持待命状态，但是接触后端后，需要接收报警短信，有时出现问题还需要⻢马上随时随地解决;
16.• 提⾼高开发效率（不不⽤用 Nginx ，代理理⼯工具等等） • 降低沟通成本（除接⼝口格式外，不不需要和后端交互） • N前o后端d职e责.更js更新清能晰 -解> 后端决⽣生产哪数据些，前问端消题费数和据痛点？ • 可以使⽤用 React SSR 技术 -> ⾸首屏渲染、SEO 等 • RESTful API -> ⾃自身使⽤用或对外提供，不不依赖后端
17.1. 如何确定项⽬目⽬目录划分的规范，命名规范（view or views） 2. 确定规范后，如何保证⼤大家都认可，并且严格遵守三3. 如年何年保证前系统所的安⽤全用性框，稳架定性，的可扩问展性题（基于express） 4. 守护进程程序的选择（pm2 or supervisor） 5. 多环境运⾏行行规则（local / beta / prod） 6. 如何利利⽤用系统 cpu 多核，以及多进程之间的通信
18.重新选O择r 框架在⽂文档说明、框架扩展、插件数量量、部署流畅性以及开发体验上，最终选择的是 Egg.js。
19.• egg-qversion • egg-qconﬁg • egg-qwatcher • egg-accesslog • egg-healthcheck • egg-checkurl • egg-swift 插件开发
20.1. 不不能利利⽤用发布系统中相应的端⼝口和⽬目录字段，只能在 qunar_xx 服务中写死，不不友好原来部署流程（service ⽅方式）问题 2. 不不能区分多环境策略略。⽐比如：beta 环境和 prod 环境配置规则不不⼀一样 3. 启动过程中出现错误，不不⽅方便便定位问题，需要到机器器上排查 4. 写系统服务需要了了解 shell 命令和系统服务格式，对于前端开发同学，成本稍⾼高 5. 除了了端⼝口、项⽬目路路径、运⾏行行环境，node.js 启动⽅方式外，处理理逻辑相似
21.• 在项⽬目中建⽴立 deploy_scripts ⽬目录，新增 start.sh （名称可以随便便命名） • 在 start.sh 中填⼊入 Node.js 启动逻辑，⽐比如 node index.js (之前是 N ⾏行行，如今最多两⾏行行)改进后的部署⽅方式 • 在发布系统选择 node 发布⽅方式，填⼊入端⼝口号，发布路路径，以及启动脚本名称（start.sh），停⽌止脚本填⼊入发布系统内置的 stop.sh （按照端⼝口杀掉进程）
22.start.sh 样例例
23.React SSR 实践
24.Action 写法
25.reactRender ⽅方法
26.视图（xx.ejs）
27.前端（xx.js）
28.React SSR 遇到的问题 • CASE1 共享代码如何处理理请求
29.React SSR 遇到的问题 • CASE2 共享代码如何处理理错误
30.React SSR 遇到的问题 • CASE3 后端代码获得设备信息
31.第⼆二部分总结 • 简要分析 Node.js 没有被⼴广泛使⽤用的原因 • Node.js 解决了了哪些问题和痛点 • 出于什什么考虑选择 Egg.js 以及开发⼀一系列列⽐比较实⽤用的插件 • Node.js 发布⽅方式的演进，⼤大家可以借鉴借鉴 • React SSR 实践思路路，以及⼀一些⽐比较典型的问题
32.• 去哪⼉儿⽹网前后端分离⽅方案和静态资源离线包 • Node.js 和 React SSR 实践 • 应⽤用和性能监控⽅方案
33.性能监控对框架本身没有做太多，因为 eggjs 本身已经经历过淘宝双⼗十⼀一的洗礼，相信在阿⾥里里内部对这块已经做的不不少优化，所以简单使⽤用的是公司级别的机器器监控。
34.应⽤用程序级别 01 应⽤用监控应⽤错误数、接⼜消耗时长，接⼜异常信息、accesslog 等 02 前端⻚页⾯面级别脚本全局错误、静态资源⽂件加载错误、异步接⼜错误、页⾯渲染时长等
35.应⽤用监控业务逻辑框架（egg.js） egg-accesslog egg-checkurl egg-qconﬁg egg-qwatcher 机器器⽇日志系统（kibana） Watcher
36.Watcher 系统
37.⽇日志系统
38.举个栗栗⼦子（3台4C-8G虚机）
39.举个栗栗⼦子（3台4C-8G虚机）
40.举个栗栗⼦子（3台4C-8G虚机）
41.举个栗栗⼦子（3台4C-8G虚机）
42.YAPI 平台https://yapi.ymfe.org/index.htmlhttps://github.com/YMFE/yapi
43.
44.
45.
46.

GMTC2018 《去哪儿网+Node,js+实践及性能监控方案》 兴百放

GMTC2018 《去哪儿网+Node,js+实践及性能监控方案》兴百放