1. 程式人生 > >京東商城交易平臺的高可用架構之路

京東商城交易平臺的高可用架構之路

京東商城

作者:王曉鍾

編輯:木環、郭蕾

據騰訊科技報道,6 月 18 日零點,京東全民年中購物節拉開了高潮的序幕。第一個小時的銷售額超過去年同期的 250%。從凌晨開始的海量訂單讓 6 月 1 日就拉開序幕的京東年中購物節奏出最強音,大量使用者瞬間湧入,峰值訂單被不斷重新整理。為了應對如此大規模的流量增長,京東研發團隊幾乎全年都在高築牆、廣積糧,一直著力從技術層面為使用者提供流暢的交易體驗,以保證在峰值交易時期系統的高可用性。在京東整個電商體系中,交易系統佔據著其中的半壁江山,購物車、結算、庫存、價格等相關的環節都包含在其中,可以說交易系統的高可用能力基本上決定了整個京東商城的高可用能力。在過去的一年時間裡,京東的交易系統做了哪些迭代和優化?今年又有哪些創新?整體的交易系統規劃是怎麼樣的?InfoQ 記者帶著這些問題採訪了京東商城交易平臺高階總監王曉鍾。

受訪嘉賓介紹

王曉鍾,京東商城交易平臺高階總監,京東交易黃金流程與智慧營銷生態系統的掌舵人,帶領的產品與研發團隊為京東商城提供了核心交易的系統保證。

InfoQ:能否整體介紹下交易平臺目前的架構體系?

王曉鍾:交易平臺負責商品、價格、使用者、庫存、訂單等電商核心基礎資訊的中心化管理,以及對購物車、結算頁、優惠券 / 禮品卡、訂單中心等黃金交易流程的管控和平臺化服務。交易平臺致力於技術改變生活,打造智慧營銷的交易平臺。為使用者提供黃金交易流程;為客戶提供智慧營銷解決方案包含促銷建議、智慧庫存定位等智慧營銷工具;為研發團隊提供穩定、可靠的交易服務。

架構

  1. 渠道 是交易的流量入口來源,目前主要包含幾大部分,PC、APP、微信、手 Q 等。目前 APP 入口已經佔據了整體流量的 70% 以上。
  2. 元件 完成對現有基礎服務的抽象與整合,將現有服務資源以多元化的方式展示給外界,靈活的組織並支援多種協議的互動,最終實現了系統的模組化、服務平臺化、功能配置化。元件最大限度的減少外界對內部邏輯的耦合,從而實現對需求快速響應。
  1. 基礎服務 位於整個黃金流程的最底層,其扮演者交易平臺心臟的角色。其中商品服務、價格服務、庫存服務、使用者服務、購物車等更是核心中的核心。
  2. 中介軟體、基礎設施 是基礎服務的基石,對業務系統提供高效能,高可用的技術支撐。

InfoQ:過去一年,交易平臺在保證底層的基礎平臺穩固方面做了哪些事情?有哪些點讀者是可以參考學習的?

王曉鍾:除了我們一直在做的、已經形成常規的工作,比如線上壓測、效能優化、擴容、故障切換、限流、降級之外,過去一年,我們在系統維穩方面做了一些精細化的工作。

  1. 核心呼叫鏈監控。在黃金交易流程中的各個服務入口點和服務相關依賴、呼叫方等進行聯合監控。當服務效能下降、可用率下降時,可以快速的定位到故障點。把監控和故障解決方案聯動起來,比如一鍵切換、服務降級、限流等,可以快速的發現和解決問題。
  2. 自動切換。對於成熟的切換流程,比如資料庫、快取、服務等節點的客戶端,當檢測到故障時,可以根據策略自動切換到健康的節點,同時在故障節點恢復後自動切換回來,減少人工操作的錯誤和耗時,提高系統的可用率。
  3. 非同步化程式設計模式。部分服務通過徹底的非同步化改造來提升吞吐量,還是有一些效果。但是由於純非同步化對於現有系統的改造還是挺大的,所以目前還在嘗試前行階段。
  4. 共享資源池。提前準備一些資源共享池,各服務混用,平時設定較低的權重。當某個服務的常規資源組不足時,則增加其在共享池中的權重,這樣可以快速的使用資源,而不用臨時擴容。
  5. 全鏈路壓測。從入口開始模擬使用者的行為進行壓測,流量通過依賴傳遞,從瀏覽、搜尋,到提交訂單以及最後的生產,自動覆蓋到鏈路中的所有環節。配合上面提到的核心呼叫鏈監控,解決以往只是單服務的壓測,覆蓋面不全的問題。

隨著業務的發展,功能的複雜度也在不斷增加,定位故障原因變的困難了起來,很多時候線上發生故障大部分的時間都在定位問題,故障的解決只要有預案就可以很快處理。呼叫鏈監控就很重要,可以站在全域性的角度,快速的定位問題,和故障預案處理結合可以解決我們的痛點。

隨著服務的不斷擴容,機器數量的增加,出現問題時,故障修復的速度變慢,自動化的故障切換可以使人工解放出來,處理更重要的事情,可以讓大家不用總是在半夜起來處理故障。

InfoQ:目前交易平臺的服務是依據什麼維度進行劃分的?

王曉鍾:目前交易平臺主要依據業務能力來劃分服務的:購物車、結算頁、促銷、價格、庫存、商品、使用者等,為 PC,手機,微信等渠道提供高可靠的大中臺服務。

這種劃分模式好處在於:

  1. 架構穩定,因為業務能力相對穩定和相互獨立。
  2. 開發團隊是自主的,圍繞著交付業務價值而不是技術特性來組織。
  3. 服務之間共同合作,鬆耦合。

InfoQ:能否分別從業務、系統、基礎設施三個層面談談你們的監控體系方案?

王曉鍾:在京東這樣的大規模分散式系統面前,每時每刻伺服器可能都宕機,網路隨時可能都在抖動,大量介面呼叫量日均過億,同時具有流量聚集效應的促銷每天都會有好幾波,如果沒有一套強大的監控體系,我們就像睜眼瞎一樣。經過多年的努力,京東目前已經形成多套監控系統,建立了比較完善的監控體系,時刻監視著系統的健康狀態,並在發現問題時第一時間進行預警:

1)業務層面的監控,主要是核心業務指標,比如實時訂單量,並按渠道、省份、運營商、機房、品類、活動等各個維度進行細分,從而在及時發現核心業務指標變化的同時,能夠快速定位、排查問題,並做出應急響應。

2)系統層面的監控,主要是方法或程式碼塊的呼叫量、成功率以及響應時間。同時,不同語言平臺有特定的監控指標,例如 Java 應用,我們也非常關心 JVM GC 情況。這些指標我們會按例項、叢集、機房等進行逐級彙總計算。對於響應時間,我們更關心的是 TP99 甚至 TP999 任何一指標低於預設閾值都會觸發報警。在採集單一介面效能資料的基礎上,我們將請求訪問鏈經過的一系列子呼叫串起來,包括 RPC 服務之間、訪問快取、訪問資料庫等等,實現呼叫鏈條薄弱環節的快速發現,快速解決。

3)基礎設施的監控,主要是網路質量和機器健康度的監控,像常規的頻寬、丟包率、重傳、連通性,CPU、記憶體、磁碟等等。在網路方面,除了內網,我們也非常關心公網網路質量,一旦發現運營商或者區域故障,就會做立即出預案響應,7*24 小時確保使用者購物體驗。

在監控指標完善的同時,我們更多在解決監控自身的延時性。京東自身訪問量大,所以在提高監控的延時性同時又不能影響業務自身效能,本身就是就一個挑戰。目前我們在業務層面、系統層面都做到了秒級粒度,基礎設施方面的重要指標也有了秒級資料。在預警方面,除了傳統的郵件、簡訊,我們集成了京東內部 IM 工具,同時還有手機語音呼叫。

在這麼多指標,這麼精細的資料面前,傳統的監控儀表盤也會讓我們再度迷失,因此我們開發了天眼系統進一步將各個監控子系統進行整合,結合前述的呼叫鏈,在一個大屏上多個核心主流程的各環節、各呼叫層次的當前健康狀況一覽無遺,一旦有故障我們可以在短時間內快速響應並恢復。

InfoQ:對於惡意的流量攻擊,京東做了哪些準備工作?準備如何預防?

王曉鍾:惡意流量攻擊,是每個網際網路企業都必須面對的難題。目前我們把流量攻擊分為兩大類:網路協議層和應用邏輯層。

網路協議層的,主要是 SYNFlood、UDPFlood、DNSFlood、HTTPFlood 這些 4 層或 7 層協議的各種流量攻擊,主要以頻寬或服務資源消耗為主。目前我們通過京東雲平臺自研的流量分析和清洗系統能夠防禦主流的惡意流量攻擊。除此之外,資訊保安部門也會聯合外部力量進行上百 G 的流量攻防演練,確保合作和聯動等實戰能力。

應用邏輯層的惡意流量的範圍和影響則比較廣泛。狹義上,惡意流量利用應用系統的軟體漏洞,做拒絕服務攻擊;廣義上,能夠利用應用的實現邏輯或規則漏洞,非法實現各種商業利益的,無論流量大小,都屬於惡意流量攻擊。這一大型別攻擊由京東的多個部門配合進行整體防禦。

1)資訊保安部門會通過開展安全自查和外部合作報告漏洞的方式,由各業務研發部門實施安全漏洞消除,比如 SQL 注入、程式碼執行、水平越權、資訊洩露等。    2)風控部門會通過資料分析,建立各種等級的風險控制模型,形成動態的不同風險等級的賬戶池,供業務系統使用。    3)業務研發部門則根據業務特性、使用者風險等級、系統壓力等因素,提供不同策略的限流實現。

InfoQ:以商品的實時價格為例,聊聊你們的讀邏輯和寫邏輯流程?

王曉鍾:京東實時價格面臨幾大挑戰:一是資料量大,幾十億的商品;二是呼叫量大,日峰值上百億;三是實時性要求高;最後是業務複雜度高,並不是單一的京東價,不僅要綜合計算各類促銷規則,還要對 PC、手機、第三方合作渠道以及區域進行差異化運營。這裡,我們運用讀寫分離、非同步化策略,選擇支撐大併發、高效能的開源元件進行設計,確保可水平擴充套件、高穩定性。

京東

1)寫邏輯流程:當採銷在後端調整價格或建立促銷時,同步寫入 MySQL 資料庫,然後通過非同步任務更新促銷主 Redis 資料,並同時更新價格主 Redis 的過期時間戳,通過 Redis 自身複製機制,將資料傳播到從節點。2)讀邏輯流程:當用戶在前端瀏覽商品列表、詳情等頁面時,非同步訪問價格實時服務,此時內嵌 Nginx 的 Lua 程式直接讀取本地 Redis(從)中的價格資料,無過期則直接返回使用者;若過期或不存在,則回源訪問價格實時計算服務,即刻返回最新價格給使用者。3)回源寫邏輯:價格實時計算服務讀取促銷主 Redis,在返回最新價格給使用者的同時,非同步寫價格主 Redis 叢集,價格主 Redis 同步資料至前置 Nginx 節點的從 Redis 節點。

InfoQ:今年 618 京東的交易平臺都做了哪些技術上的改進或者創新,以及未來將會考慮哪些優化和升級方向?

王曉鍾:除了上面提到的主要用來維護系統穩定的技術改造之外,今年交易平臺也投入了更多的精力在做提升使用者體驗、提升 GMV 的改進和創新工作。比如利用大資料技術和機器學習模型,來提供千人千價、千人千促的體驗。

我們也在嘗試利用大資料和機器學習等在系統維穩上做一些工作,比如:

1)SQL 注入和惡意程式碼執行方面引入了機器學習模型,通過對已有的攻擊行為進行學習,訓練特徵。引入半監督學習,讓模型可以通過學習,自動發現新型的攻擊。大大提高了攻擊的發現效率和新攻擊的識別能力。各項指標已經完全超越傳統的規則識別。

2)使用有向圖模型對惡意攻擊進行溯源檢測,更加準確快速的進行溯源分析,並且得到了非常好的效果。

下一步,我們會繼續嘗試在這個方向上做一些創新,比如:

1)在人機行為檢測方面進行優化。使用聚類和 nlp 模型對惡意刷單行為進行識別,提高惡意刷單行為的驗證級別,從而極大地降低後臺介面壓力。

2)評論價值評定模型,識別真實評論和刷出來的評論。讓評論產生更大的價值。

3)我們將在故障智慧預測上進行探索。目前很多監控和預警都是事後的,我們希望能做到事前。通過分析歷史性、週期性故障資料,結合當前實時健康度,快速識別出“瀕死”的機器、例項,真正做到監控預警智慧化。

原文來自微信公眾號:聊聊架構