7
在大流量下的node方案中,如何保证最低的SLA和问题追踪效率和闭环建设,如果保证请求流量的透明化和业务操作的透明化?这里介绍下百度网盘是如何做的。

难点

  • 千万级PV下的node运维
  • 可用性保障,保障最低SLA 99.98%
  • 问题追踪和闭环建设
  • 流量透明化、操作透明化

解决方案

Alt text

我们将整个运维方案分为了6步,我们的目的:流量透明化操作透明化

第一步:流量跟踪

为了解决微服务引起分布式流量链路问题,我们借鉴了spring cloud的思想。设计了traceidtracecode两个跟踪字段,用于追踪落地容器的整个流量链路中的节点信息,通过每个请求的Response Header中的标识信息进行流量的跟踪和定位。

第二步:灰度发布

大流量下的业务必须提供灰度和AB测试的方案,结合in-routerupstream配置能力和BNS(naming service)节点,将用户流量分为白名单内网外部,部署级别分为单台单边全量,以此实现流量的控制。

名词解释:
in-router:专门为node流量进行负载处理的ngx集群
BNS:baidu naming service,通过虚拟域名的方式将IDC或集群进行逻辑编排,方便流量的定位和处理。
第三步:日志分级

整个日志系统分为4级,每一级记录不同的信息,详细记录【什么时候、在哪儿、谁、做了什么错误、引起了什么问题】,此外还针对node还做了事件循环的lagTime监控,以此监控node服务器的压力。

日志级别:

  1. 业务日志
  2. 业务框架日志
  3. daemon日志
  4. script日志(含:环境日志)
第四步:警报分级

日志经过解析服务处理后,将数据发送给监控平台,然后再通过分级阈值判断确实是否应该触发警报。警报手段分为:邮件、短信、电话 等。

第五步:染色处理

值班人员收到警报后从监控平台获取具体信息,如果是复杂问题,通过cookie染色,指定流量链路和操作,便可追踪定位到绝大多数的问题。

第六步:流量追溯

更好确定用户的流量走向,通过traceidtracecode以及配合requestid,我们便可复现用户的流量走向以及内部逻辑操作。

最后:闭环建设

最后通过整合这六个步骤,使每一部分相互联结和转化,将整个链路串联在一起,从而完成运维流量透明化操作透明化的目的

结语

总体通过这六步操作,完成了网盘的高性能node应用 和最低SLA的建设要求,以及对流量和操作的透明化要求。

本文给出node大流量下的运维方案思路,主要起抛砖引玉的作用,具体细节还需自己深入体会和理解;
它并不是一篇普适性的科普文章,所以需要一定的运维基础才可以更好地理解文章中的内容。如果你有node运维这方面的需求,那么希望这篇文章可以给你一些启发和参考。

张亚涛
5.3k 声望2.8k 粉丝

人首先应该接受现实,承认问题的存在,并且反思它。而不是首先就跳出来回避这个问题,找比我们更差的。质疑甚至抨击提出问题的人,并且一杆子打死。