全棧出征，京東技術基石如何爲「618」大促護航？

6 月 18 日 24 時，2020 年的 618 大促落下帷幕，京東 618 大促期間累計下單金額達到 2692 億元，創下新紀錄。

與往年不一樣，今年 618 是京東核心業務全面上雲的第一年，也是京東融合人工智能、雲計算、物聯網等業務板塊升級爲京東智聯雲以後其技術能力的第一次大考。

面對創新高的雲端數據和流量洪峯，京東技術扛住了，這主要得益於做爲京東技術基石的京東智聯雲全棧出征，爲 618 搭建了一套穩固且高彈性的技術底座，支撐超大流量、超高併發的技術平臺。

近日，京東智聯雲技術沙龍在線上舉行，來自京東的 5 位演講嘉賓帶來了各自的主題分享，分別從分佈式圖搜系統、分佈式文件系統、全方位安全體系、數據庫等角度，揭祕京東技術全棧是如何爲今年的 618 大促提供技術支撐的。

朱洪銀，京東軟件工程師

演講題目：《支撐618大促流量洪峯利器——分佈式文件系統ChubaoFS》

演講精華：

今年的 618 大促，京東面臨着不少難題與挑戰，這主要包括計算和存儲分離的需求，數據的生產者和消費者使用不用的協議訪問文件，容器平臺須要提供可持久化的分佈式存儲平臺，提供更大的磁盤空間，以及對海量小文件友好、同時能夠提供高性能、高可用、高可擴展性。

這些挑戰，被京東自研的融合分佈式文件系統與對象存儲服務的 ChubaoFS一一化解。

從架構上來看，ChubaoFS 包含 Master、MetaNode、DataNode、Client 四個模塊，具備高性能、多租戶、通用存儲引擎、高可擴展性、兼容POSIX接口、支持對象存儲 6 個關鍵特徵。

ChubaoFS 的元數據子系統是由多個 MetaNode 節點組成的，能夠水平擴容，在一個 MetaNode 上能夠分佈多個 MetaPartition。

在京東，ChubaoFS 已經穩定服務於 2000 多個應用以及在線業務，爲公司節省了上千臺機器，成本節約效果明顯。

朱洪銀介紹到，618 大促期間，客戶端的數據劇增，各個業務方可能根據訪問量的變化進行大量擴容，這時 Master 就會遇到帶寬瓶頸，若是幾十萬個 Cilent 同時訪問一臺機器，會對一臺機器形成很大的壓力，因此 ChubaoFS 在中間加了一層以緩存系統的元數據，這樣客戶端幾十萬的請求，最終打到 Master 集羣上可能會縮小 1000 倍，Master 的壓力明顯下降。

第二點是大促期間的熱點數據訪問。面對熱點數據訪問場景，有三種處理手段，第一種是 S3；若是使用的是 POSIX，則直接開啓 cache 緩存選項，提高讀寫性能；第三種是從集羣的角度，在建立 vol 時會多分配一些 DataPartition 和 MetaPartition 資源，減少每臺機器的 IO 壓力和內存壓力，從而提高響應速度。

在 618 期間，ChubaoFS 的總體 QPS 讀達到 3000W，而 TP999 只用 5 毫秒，寫是 800W，響應速度是 65 毫秒，性能很是高。

最後一點是高可用，ChubaoFS 支持磁盤故障自愈，並具備 FollowerRead 功能，支持跨機房、跨 pod 部署，單機房出現了問題，另一個機房也能夠提供服務，從而解決高可用的問題。

目前，ChubaoFS 已在 GitHub 開源，感興趣的同窗能夠經過如下連接詳細瞭解。

項目地址：https://github.com/chubaofs/c...

論文地址： https://arxiv.org/abs/1911.03001

白亞東，京東智聯云云產品研發部架構師
演講題目：《京東智聯雲數據庫如何支撐百萬級QPS大促》

演講精華：

白亞東透露，京東智聯雲以超高彈性應對海量併發，流量洪峯較去年 618 提高了 195% 多，總帶寬也同比增加 113%，雲安全防禦保障實時攔截攻擊 12.3 億次，支撐超過去年京東雙十一峯值 1.8 倍計算上雲專區專線峯值流量。京東智聯云云數據庫 RDS 的 QPS，更是達到平時的 3.5 倍，流量洪峯達到平時的 3 倍。

京東智聯云云數據庫 RDS 分八個步驟備戰大促，首先是識別保障範圍，明確邊界範圍，明確保障業務優先級；第二步是業務評估及與檢查，評估整個業務鏈路上須要的資源，提早擴容和採購；第三步是預案整理，包括服務高可用、數據高可用預案、降級保護預案、彈性擴容預案等；監控及報警梳理，發現系統壓力，在系統真正故障或不可用時及時介入處理，以確保系統運行平穩；第五步是業務壓測及預案演練；第六步是值班，讓整個業務鏈路徹底串起來；當這些前期準備工做作到位後，6 月1 日起作好值班工做，值班通訊 24 小時無縫銜接，確保線上報警第一時間響應；最後一項重要工做是大促技術覆盤，找到須要完善、改進，以及將來須要進一步增強的地方，爲下一次大促作長遠準備。

對於數據庫來講，_可用性_和_可靠性_是永恆的話題，商用數據庫提供全套管理系統，但缺點是貴。開源數據庫也有不少生態工具，藉助其餘組件解決的方案，也能完成相應的功能，但有必定的技術門檻和維護成本。

數據備份是容災的基礎，也能夠防止系統出現操做失誤和系統故障致使數據丟失。京東智聯云云數據庫 RDS 提供數據備份和日誌備份兩種備份功能，並提供覆蓋恢復、按備份恢復、按時間點恢復三種恢復功能，用戶若是誤刪實例，能夠經過多種方法恢復數據。

另外，在跨地域容災方面經過將雲數據庫 RDS 實例備份文件同步到不一樣 Region 的地域，RDS 可實現跨地域容災，開啓跨地域備份服務，不會對原雲數據庫 RDS 實例使用性能形成任何影響。

在高可用性方面，京東智聯云爲用戶多個地域提供了雲計算服務，同一個地域下的不一樣可用區網絡延遲在 1.5 毫秒之內，支持單可用部署，支持遷移可用區，並可實現故障自動切換、故障自愈。

京東智聯云云數據庫的產品，目前支持 MySQL、Percona 和 MariaDB 等，實例管理有生命週期管理、只讀管理、高可用管理，以及升配降配、實例重啓等其餘運維，備份管理、賬戶管理、恢復管理、庫管理。

在安全、審計和日誌方面，RDS 現支持標準模式和高安全模式，高安全模式具有必定的 SQL 攔截能力，經過分析關鍵系統函數來實現防護 SQL 注入；審計上，雲數據庫 MySQL 開啓審計後會統計全部 DDL 和 DML 操做信息；性能優化上，RDS 能夠從多個角度統計 SQL 執行性能和及索引的各類統計數據，幫助用戶發現問題SQL和潛在性能瓶頸，有針對性地進行優化；在日誌方面，提供完整的 binlog 日誌下載，雲數據庫 MySQL 實例每 5 分鐘會自動同步最新的實例日誌文件至雲存儲，且 binlog 產生的空間佔用不收費。

邱雁傑，京東智聯云云產品研發部架構師

演講題目：《護航京東618大促，如何構建全方位立體安全體系》

演講精華：

京東 618 大促面臨不少安全威脅及挑戰，包括 DDoS 攻擊等基礎安全、業務風控和數據安全。618 大促期間，京東智聯雲共遭受過 800G DDoS 流量攻擊，在 CC 攻擊方面攔截64億次攻擊，CC 和 WEB 漏洞攻擊都是七層的應用攻擊。在其餘攻擊方面，京東還防禦了包括暴力破解、遠程漏洞利用、敏感文件探測等 4 億次其餘攻擊。

邱雁傑還指出了企業加快數字化轉型必須面對的幾個安全痛點。第一，資產管理盲區致使木桶響應；第二，防護建設成本與攻擊成本的不對等；第三，邊界式防護模式中的內部管控缺失；第四，業務多樣化致使的數據安全問題；第五，缺少體系化安全建設思路，難從公司總體安全角度考慮安全體系建設。

要構建一個從基礎設施到應用安全的全方位多層次安全體系，首先要清楚企業整個的系統架構，再針對用戶、員工和第三方合做夥伴這三個不一樣的層次，有針對性地構建安全防禦體系。

京東智聯雲推出一系列基於雲的原生安全能力及產品，第一，_在安全基礎設施層，京東智聯雲用戶可使用 Anti-DDoS 系統，對全部流入京東智聯雲機房流量作統一的流量清洗；第二，京東智聯雲提供原生全鏈路加密，在端上可使用 KMS、SDK 與 KMS 交互，進行數據加密；第三，京東智聯雲原生 DevSecOps 服務提供項目管理、代碼託管、流水線幾大功能，且在項目管理時加入 Sec 流程，在項目設計過程當中提供安全自查 CheckList，以規避安全設計缺陷；第四，體用統一的安全中心對全部的安全風險做統一管控和處理。

結合企業安全體系結構和京東智聯云云原生的安全功能，能夠看到基於雲原生功能和安全產品，能夠構建從基礎設施到應用安全的全方位多層次安全防禦體系，爲企業數字化轉型護航。

俞凱，京東智聯雲視覺研發部資深軟件工程師

演講題目：《分佈式圖搜系統在618大促期間的落地——應對海量商品審覈，實現秒級響應》

演講精華：

618 大促期間，全部商家、用戶評論、客戶諮詢等圖片都須要進行審覈，過濾涉黃涉暴圖片。這一操做的人工成本巨大，須要藉助AI的力量來實現。圖片過濾面臨着巨大的困難和挑戰，包括大庫低時延、大庫高併發，並須要保證數據的實時性、一致性和可靠性。

爲應對上述挑戰，京東智聯雲在業務中積累出一個通用化、高可用、高性能、高併發、可插拔、自動化的圖搜平臺，但願支持億級底庫、海量併發、秒級返回，支持動態入庫、實時可查，支持第三方算法庫的接入，對外賦能。

• 微服務架構

  ○ 採用 K8s 進行服務部署、編排。

  ○ 採用 Istio 進行負載均衡和流量管理。

  ○ 採用 OSS/mysql 進行數據持久化。

  ○ 採用 redis 進行業務數據緩存。

  ○ 採用kafka/http/grpc進行服務通訊。

• 服務分層

  ○ 基礎服務：包含算法倉庫、圖片服務、索引服務。

  ○ 核心服務：包括調度服務和路由服務。

  ○ 業務服務：包含人臉識別、行人重識別、商品識別服務。

  

  該圖搜系統的核心模塊包括調度模塊 scheduler，路由模塊 router、索引服務

indexServer、註冊服務 register，以及算法倉庫模塊 algoHub。針對此前版本遇到的痛點，該系統進化出一些關鍵技術，好比針對解決億級底庫，海量查詢的痛點，經過把億級底庫分紅多個 Slice，經過調度模塊，根據必定的策略調度到合適的 IndexServer 上，以提升性能。

以前的版本將底庫和服務器作了靜態綁定，這種方案靈活性、擴展性和容災能力差，沒法感知庫數量和大小的動態變化，爲了支持實時建庫、入庫，設計了 scheduler 模塊，由它來監控 group、slice、indexServer 的狀態，根據這些狀態對 slice 進行調度和 rebalance，併發布 slice 到 indexServer 的路由信息， router 模塊根據路由信息，路由入庫信息以及分發搜索請求、聚合搜素結果。

在性能參數上，618 期間，該圖搜系統承受了 QPM 爲 80W 的查詢洪峯，特徵服務使用了約 120 張 P40 卡，tps 爲 180；索引服務使用了 25 臺 32 核機器；接入服務使用了 460 臺雙核機器；底庫數量達 100 萬，召回率達 98% 以上，調用量最高的一天達 5 億次。

賀思遠，京東物流架構師

演講題目：《京東物流數據同步平臺——數據蜂巢Dcomb大促保障之路》

演講精華：

數據蜂巢（Dcomb）是一款輕量級數據處理系統 ，已在京東物流大規模使用，系統採用分佈式架構，具備高可用及負載均衡的特性，可實現數據實時採集、歷史數據加工同步、實時數據單表加工同步，以及實時數據寬表加工同步四大功能。

Comb 系統架構採用的是 Master、Slave 分佈式架構。Slave 內部包含 pieworker、streamworker、batchworker 幾個部分。其中，stream 負責數據採集；Store 採用文件隊列，將解析過的數據存到本地；單表對數據進行消費、加工；寬表按照 join 邏輯，將多表關聯，實時輸出；此外還支持數據的離線同步。

目前，Dcomb 系統已經應用於京東物流多個核心業務上，對業務數據進行加工同步，輸出相關報表用以指導生產。

爲了保證今年 618 順利進行，Dcomb 系統作了不少優化工做。

1. 首先是如何保證數據採集傳輸。大促期間，binlog 生成的速度極快，幾十秒就會生成 1G 的 binlog 文件，在數據採集上，瓶頸主要在於序列化和壓縮、解析上，Dcomb 對 MySQL 的 binlog 進行預處理，再併發進行解析，以提高性能。

2. 傳輸。在跨區域將數據從園區傳到 IDC 時，Dcomb 也作了優化，好比二次壓縮，併發傳輸，最大程度的利用區域帶寬，以解決因網絡質量引發的延遲，提升時效性。

3. 消費。當數據到達 IDC 後對數據進行分發可能面臨併發的問題，Dcomb 提供了多種策略，包括嚴格串行，表級，行級併發等保證數據的正確性。

實時寬表加工是 Dcomb 系統重點開發的一個功能，當前的處理方式相似於 Storm，但團隊正在經過借鑑 Flink 等優秀流式計算框架的思想研發第二代寬表計算引擎，這是 Dcomb 將來的一個重要發展方向。

以上僅爲演講嘉賓觀點的精彩提煉，如想了解完整演講內容，請點擊『閱讀原文』，進入官網查看完整演講視頻。也可掃碼關注京東智聯雲開發者微信公衆號，獲取更多技術內容。