6月18日24時，2020年的618大促落下帷幕，京東618大促期間累計下單金額達到2692億元，創下新紀錄。
與往年不同，今年618是京東核心業務全面上雲的第一年，也是京東融合人工智慧、雲計算、物聯網等業務板塊升級京東智聯雲之後其技術能力的第一次大考。
面對創新高的雲端數據和流量洪峰，京東技術扛住了，這主要得益於作為京東技術基石的京東智聯雲全棧出征，為618搭建了一套穩固且高彈性的技術底座，支撐超大流量、超高並發的技術保障。
近日，京東智聯雲技術沙龍在線上舉行，來自京東的 5 位演講嘉賓帶來了各自的主題分享，分別從分布式圖搜索系統、分布式文件系統、全方位安全體系、資料庫等角度，揭秘京東技術全棧是如何為今年的 618 大促提供技術支撐的。
ChubaoFS整體QPS讀可達3000W，TP999僅用時5毫秒！
朱洪銀，京東軟體工程師
演講題目：《支撐618大促流量洪峰利器——分布式文件系統ChubaoFS》
演講精華：
今年的618大促，京東面臨著很多難題與挑戰，這主要包括計算和存儲分離的需求，數據的生產者和消費者使用不用的協議訪問文件，容器平台需要提供可持久化的分布式存儲平台，提供更大的磁碟空間，以及對海量小文件友好、同時可以提供高性能、高可用、高可擴展性。
這些挑戰，被京東自研的分布式文件系統ChubaoFS化解。
從架構上來看，ChubaoFS 包含 Master、MetaNode、DataNode、Client 四個模塊，具有高性能、多租戶、通用存儲引擎、高可擴展性、兼容POSIX接口、支持對象存儲 6 個關鍵特徵。
ChubaoFS的元數據子系統是由多個MetaNode節點組成的，可以水平擴容，在一個 MetaNode上可以分布多個 MetaPartition。
在京東，ChubaoFS 已經應用於 1000 多個業務，為公司節省了大約 1000 多台機器，成本節約效果明顯。
朱洪銀介紹到，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/chubaofs
論文地址: https://arxiv.org/abs/1911.03001
資料庫RDS，抗住平時3倍QPS與流量洪峰
白亞東，京東智聯云云產品研發部架構師
演講題目：《京東智聯雲資料庫如何支撐百萬級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，以規避安全設計缺陷；第四，體用統一的安全中心對所有的安全風險作統一管控和處理。
結合企業安全體系結構和京東智聯云云原生的安全功能，可以看到基於雲原生功能和安全產品，可以構建從基礎設施到應用安全的全方位多層次安全防護體系，為企業數字化轉型中護航。
分布式圖搜系統，調用量最高一天達5億次
俞凱，京東智聯雲視覺研發部資深軟體工程師
演講題目：《分布式圖搜系統在618大促期間的落地——應對海量商品審核，實現秒級響應》
演講精華：
618大促期間，所有商家、用戶評論、客戶諮詢等圖片都需要進行審核，過濾涉黃涉暴圖片。這一操作的人工成本巨大，需要藉助AI的力量來實現。圖片過濾面臨著巨大的困難和挑戰，包括大庫低時延、大庫高並發，並保證數據實時性、一致性、可靠性。
為應對上述挑戰，京東智聯雲在業務中積累出一個通用化、高可用、高性能、高並發、可插拔、自動化的圖搜平台，希望支持億級底庫、海量並發、秒級返回，支持動態入庫、實時可查，支持第三方算法庫的接入，對外賦能。
（圖搜系統架構圖）
1、微服務架構
-
採用K8S進行服務部署、編排
-
採用Istio進行負載均衡和流量管理
-
採用OSS/mysql進行數據持久化
-
採用redis進行業務數據緩存
-
採用kafka/http/grpc進行服務通信
2、服務分層
-
基礎服務：包含算法倉庫、圖片服務、索引服務
-
核心服務：包括調度服務和路由服務
-
業務服務：包含人臉識別、行人重識別、商品識別服務。
該圖搜索系統的核心模塊包括調度模塊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大促保障之路》
演講精華：
數據蜂巢(Dcomb)是一款輕量級數據處理系統 ，已在京東物流大規模使用，系統採用分布式架構，具有高可用及負載均衡的特性，可實現數據實時採集、歷史數據加工同步、實時數據單表加工同步，以及實時數據寬表加工同步四大功能。
Dcomb系統架構採用的是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未來的一個重要發展方向。