全棧出征，京東技術基石如何為“618”大促護航？

雲妹導讀：

618、11.11 等電商節已經成為電商平臺的頭等大事之一，在數億消費者與商家狂歡的同時，如何保證平臺的穩定、各項儲存服務到位、如何保持複雜的網路環境下的資料使用和多方呼叫等問題，成為考驗平臺技術部門的重要一環。 在《揭秘京東618大促背後的技術基石 》線上沙龍中，來自京東的  5  位技術專家帶來了五大精彩議題，覆蓋  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 開源，感興趣的同學可以透過以下連結詳細瞭解。

 

專案地址：

論文地址： 

白亞東，京東智聯云云產品研發部架構師

 

演講題目：《京東智聯雲資料庫如何支撐百萬級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 未來的一個重要發展方向。

 

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