《1199億成交額！京東618大捷幕后技術功臣揭秘》要點：
本文介紹了1199億成交額！京東618大捷幕后技術功臣揭秘，希望對您有用。如果有疑問，可以聯系我們。

6月19日消息: 1199億元,是京東6·18全民年中購物節從6月1日開始,截止6月18日24點累計下來的總下單金額.而就在2016年天貓雙十一購物節的總交易額是1207億元.這兩者的數值已經非常接近了.

京東6.18的成績單&&黑科技

6月18日凌晨一點多,京東CEO劉強東通過微信朋友圈發了一條信息：“今年618的第一個小時的銷售額同比去年增長250%多!小小激動一把!”

1199億元,是京東6·18全民年中購物節從6月1日開始,截止6月18日24點累計下來的總下單金額.

而在當日,京東的黑科技發布卻讓我們瞠目結舌.6月18日,京東無人送貨機器人在中國人民大學、清華大學、浙江大學、長安大學、中國傳媒大學和北京科技大學園區正式開始啟用,這或許意味著無人化服務的開始.

從京東發布無人送貨機器人這個角度來看,京東在IT信息系統的研發的投入非常巨大,京東的IT信息系統的復雜與龐大也是毋庸置疑的.

在這么大的公司中,這么多不同架構的IT業務同時運行.一旦出現問題,是得有多么恐怖啊?萬一出現問題怎么辦?

技術先行,數據說話,ForceBot壓測實踐得真知

在6.18之前,技術保障團隊最擔心的問題是環環相扣的各個核心系統,尤其是強依賴,上下游關系緊密結合的系統出現瓶頸的問題.這會影響整個系統鏈路的處理性能,直接影響用戶購物體驗.從而導致訂單量下降,成交量下降的情況.

更重要的一個問題是各系統容量規劃數據不精準問題.每次大促前備戰會必不可少的討論話題就是服務器資源申請擴容問題,各團隊基本都是依據往年經驗和線上資源使用率給出評估量,提出一個擴容量需求,導致各個業務系統每次促銷擴容量非常大數據不精準.

為了解決以上各種苦惱,2016年基礎平臺部整體牽頭啟動了 ForceBot 全鏈路壓測(模擬備戰常態化)這個項目.

此項目牽扯到所有京東研發體系團隊,各系統必須改造識別壓測過來的流量和線上正式流量進行區分標記特殊處理,不能因為壓測流量影響正常用戶體驗和污染線上數據等工作,由于跨團隊協作之多、跨系統協調改造等工作量非常大,挑戰性可想而知!

京東ForceBot設計與架構揭秘

設計目標

2016年主要實現了訂單前的所有黃金鏈路流程高并發壓測用戶行為模擬,包括模擬用戶操作：首頁、登陸、搜索、列表、頻道、產品詳情、購物車、結算頁、京東支付等.

在黃金鏈路中有各種用戶行為場景,比如一般用戶首先訪問首頁,在首頁搜索想要產品,翻頁瀏覽,加入購物車、湊單、修改收貨地址、選擇自提等等.

各系統壓測量依據往年雙11峰值作為基礎量,在此基礎上動態增加并發壓力；同時要區分對待兩個大的場景,日常流量和大促流量.

大促場景下搶購活動集中,交易中心寫庫壓力最大,另外用戶行為和日常有很大的反差,比如用戶會提前加入購物車,選擇滿減湊單,集中下單等等場景.

2016年啟用的鏈路較短,在2017年將實現訂單后生產的全鏈路.

設計實現價值

ForceBot 在2016年雙11替代往年各系統獨自優化、性能壓測備戰狀態,目前所有的備戰數據和各系統性能承載能力、資源規劃等都由 ForceBot 給出直接數據作為依據,在軍演壓測過程中,秒級監控到壓測源、壓測中、京東所有的黃金鏈路系統、接口響應時間、TPS、TP99 等數據,軍演完成后提供豐富的壓測報告,準確的找到各系統并發瓶頸.

同時也承擔了內網單一系統的日常壓測任務,開放給研發和壓測團隊,支撐京東所有的壓測場景統一壓測平臺,對公司內壓測資源的整合和提高利用率.

設計ForceBot架構

新平臺在原有功能的基礎上,進行了功能模塊的解耦,鏟除系統瓶頸,便于支持橫向擴展.

• 對 controller 功能進行了拆解,職責變為單一的任務分配；
• 由 task service 負責任務下發,支持橫向擴展；
• 由 agent 注冊心跳、拉取任務、執行任務；
• 由 monitor service 接受并轉發壓測數據給 JMQ；
• 由 dataflow 對壓測數據做流式計算,將計算結果保存在 db 中；
• 由 git 來保存壓測腳本和類庫.GIT 支持分布式,增量更新和壓縮

這樣極大的減輕了 controller 的負載壓力,并且提升了壓測數據的計算能力,還可以獲取更多維度的性能指標.

改造業務系統

1. 黃金流程業務

   首期識別從用戶瀏覽到下單成功的黃金流程,其包含的核心業務如下：

1. 壓測流量識別

   壓測流量是模擬真實用戶行為,要保障在軍演過程中不能污染線上各種統計等數據,比如：PV UV 訂單量等,更不能影響正常用戶下單購物體驗.

   首先要對用戶、商品進行打標,以便于各個系統進行測試流量識別.針對下單壓測,庫存系統需要根據測試用戶和商品提前準備好庫存量.風控系統需要放行測試用戶和商品的操作.

2. 壓測數據存儲

   業務系統識別出壓測數據后,根據不同的場景,采用兩種方式來存放壓測數據.

• 打標數據并存儲到生產庫中,壓測的數據能體現生產環境性能.定期清理測試數據.統計報表要過濾掉測試數據.改方案能利用現有資源,需要系統進行較多改造.
• 構造壓測庫環境,根據壓測流量,把壓測數據存放到壓測庫中進行隔離.改方案需要較多的資源,但系統改造量小.

  支付系統最大的改造困難就是銀行接口的強依賴,不能用真實的銀行卡扣款和支付, ForceBot 的目標不是壓銀行接口,而是壓自己本身的支付系統.

  所以京東這邊支付團隊目前是自己造了一個假銀行,假接口,通過前端傳遞過來的壓測標識,自動路由到假銀行進行扣款支付；

測試是保障和檢驗能力的最佳的方法,通過模擬測試,反饋出現有的技術問題.

原文來自微信公眾號：高效運維

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/2398.html