千萬級PV下的nodeJS運維方案（拋磚引玉版）

在大流量下的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服務器的壓力。

日誌級別：

1. 業務日誌
2. 業務框架日誌
3. daemon日誌
4. script日誌（含：環境日誌）

第四步：警報分級

日誌通過解析服務處理後，將數據發送給監控平臺，而後再經過分級和閾值判斷確實是否應該觸發警報。警報手段分爲：郵件、短信、電話 等。

第五步：染色處理

值班人員收到警報後從監控平臺獲取具體信息，若是是複雜問題，經過cookie染色，指定流量鏈路和操做，即可追蹤定位到絕大多數的問題。

第六步：流量追溯

更好肯定用戶的流量走向，經過traceid和tracecode以及配合requestid，咱們即可復現用戶的流量走向以及內部邏輯操做。

最後：閉環建設

最後經過整合這六個步驟，使每一部分相互聯結和轉化，將整個鏈路串聯在一塊兒，從而完成運維流量透明化和操做透明化的目的

結語

整體經過這六步操做，完成了網盤的高性能node應用 和最低SLA的建設要求，以及對流量和操做的透明化要求。

本文給出node大流量下的運維方案思路，主要起拋磚引玉的做用，具體細節還需本身深刻體會和理解； 它並非一篇普適性的科普文章，因此須要必定的運維基礎才能夠更好地理解文章中的內容。若是你有node運維這方面的需求，那麼但願這篇文章能夠給你一些啓發和參考。