在大流量下的node方案中,如何保证最低的SLA和问题追踪效率和闭环建设,如果保证请求流量的透明化和业务操作的透明化?这里介绍下百度网盘是如何做的。
难点
- 千万级PV下的node运维
- 可用性保障,保障最低
SLA 99.98%
- 问题追踪和闭环建设
- 流量透明化、操作透明化
解决方案
我们将整个运维方案分为了6步,我们的目的:流量透明化
与 操作透明化
。
第一步:流量跟踪
为了解决微服务引起分布式流量链路问题,我们借鉴了spring cloud
的思想。设计了traceid
和 tracecode
两个跟踪字段,用于追踪落地容器的整个流量链路中的节点信息,通过每个请求的Response Header
中的标识信息进行流量的跟踪和定位。
第二步:灰度发布
大流量下的业务必须提供灰度和AB测试的方案,结合in-router
的upstream
配置能力和BNS(naming service)
节点,将用户流量分为白名单
、内网
、外部
,部署级别分为单台
、单边
和全量
,以此实现流量的控制。
名词解释:
in-router:专门为node流量进行负载处理的ngx集群
BNS:baidu naming service
,通过虚拟域名的方式将IDC
或集群进行逻辑编排,方便流量的定位和处理。
第三步:日志分级
整个日志系统分为4级
,每一级记录不同的信息,详细记录【什么时候、在哪儿、谁、做了什么错误、引起了什么问题】,此外还针对node还做了事件循环的lagTime监控
,以此监控node服务器的压力。
日志级别:
- 业务日志
- 业务框架日志
- daemon日志
- script日志(含:环境日志)
第四步:警报分级
日志经过解析服务处理后,将数据发送给监控平台,然后再通过分级
和阈值
判断确实是否应该触发警报。警报手段分为:邮件、短信、电话 等。
第五步:染色处理
值班人员收到警报后从监控平台获取具体信息,如果是复杂问题,通过cookie染色
,指定流量链路和操作,便可追踪定位到绝大多数的问题。
第六步:流量追溯
更好确定用户的流量走向,通过traceid
和tracecode
以及配合requestid
,我们便可复现用户的流量走向以及内部逻辑操作。
最后:闭环建设
最后通过整合这六个步骤,使每一部分相互联结和转化,将整个链路串联在一起,从而完成运维流量透明化
和操作透明化
的目的
结语
总体通过这六步操作,完成了网盘的高性能node应用 和最低SLA的建设要求,以及对流量和操作的透明化要求。
本文给出node大流量下的运维方案思路,主要起抛砖引玉的作用,具体细节还需自己深入体会和理解;
它并不是一篇普适性的科普文章,所以需要一定的运维基础才可以更好地理解文章中的内容。如果你有node运维这方面的需求,那么希望这篇文章可以给你一些启发和参考。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。