2684億!雙十一背後的技術

所有不可想象,終將化作尋常;我們相信“相信”,一切都是新的。

2019年阿里巴巴雙十一交易額:2684億
在這裏插入圖片描述
作爲技術行業者的你,是否對這數據背後的技術更感興趣?

這千億級的交易量,業務平臺是如何支撐的呢?!按個人的經驗和所瞭解的一些技術,對雙十一的技術棧做一個整理。


限流熔斷

  • 服務限流 :當系統資源不夠,不足以應對大量請求,對系統按照預設的規則進行流量限制或功能限制
  • 服務熔斷:當調用目標服務的請求和調用大量超時或失敗,服務調用方爲避免造成長時間的阻塞造成影響其他服務,後續對該服務接口的調用不再經過進行請求,直接執行本地的默認方法
  • 服務降級:爲了保證核心業務在大量請求下能正常運行,根據實際業務情況及流量,對部分服務降低優先級,有策略的不處理或用簡單的方式處理

服務降級的實現可以基於人工開關降級(秒殺、電商大促等)和自動檢測(超時、失敗次數、故障),熔斷可以理解爲一種服務故障降級處理

相關博文: 扛住阿里雙十一高併發流量,Sentinel是怎麼做到的?


多級緩存

首先我們需要明白,什麼是一個多級緩存系統,它有什麼用。所謂多級緩存系統,就是指在一個系統 的不同的架構層級進行數據緩存,以提升訪問效率。
我們都知道,一個緩存系統,它面臨着許多問題,比如緩存擊穿,緩存穿透,緩存雪崩,緩存熱點等等問題。爲了解決一級緩存存在的風險和問題,產生了多級緩存的概念。

相關博文: 千萬級併發!如何設計一個多級緩存系統?


緩存預熱

緩存預熱就是系統上線後,提前將相關的緩存數據直接加載到緩存系統。避免在用戶請求的時候,先查詢數據庫,然後再將數據緩存的問題!用戶直接查詢事先被預熱的緩存數據!
緩存預熱解決方案:
(1)直接寫個緩存刷新頁面,上線時手工操作下;
(2)數據量不大,可以在項目啓動的時候自動進行加載;
(3)定時刷新緩存;

相關博文: Redis系列十:緩存雪崩、緩存穿透、緩存預熱、緩存更新、緩存降級


降級預案

  • 爲什麼需要降級:當訪問量劇增、服務出現問題(如響應時間慢或不響應)或非核心服務影響到核心流程的性能時,仍然需要保證服務還是可用的,即使是有損服務。
  • 降級的最終目:保證核心服務可用,即使是有損的。而且有些服務是無法降級的(如加入購物車、結算)

相關博文:服務降級方案


異地多活

異地多活一般是指在不同城市建立獨立的數據中心,“活”是相對於冷備份而言的,冷備份是備份全量數據,平時不支撐業務需求,只有在主機房出現故障的時候纔會切換到備用機房,而多活,是指這些機房在日常的業務中也需要走流量,做業務支撐。冷備份的主要問題是成本高,不跑業務,當主機房出問題的時候,也不一定能成功把業務接管過來。

相關博文:業界異地多活高可用架構設計方案總結


前端靜態化

網站的本質其實就是BS,這裏的BS我沒有帶上架構二字,而就是指Browser和Server即瀏覽器和服務器,而網站靜態化技術的作用目標就是讓客戶端即瀏覽器的用戶體驗更好,但是如果我們想讓網站在瀏覽器上運行的更快,在更快的基礎上能設計更多更好的用戶體驗功能,那麼我們需要做的工作其實就不僅僅是着眼於瀏覽器本身,而是要把和瀏覽器相關的一切作用因子結合在一起考慮,這就是網站靜態化技術的本源所在。

相關博文: 網站靜態化處理—web前端優化—上


統一網關

API網關可以看做系統與外界聯通的入口,我們可以在網關進行處理一些非業務邏輯的邏輯,比如權限驗證,監控,緩存,請求路由等等。

相關博文:什麼是API網關 如何設計億萬級統一網關


容量評估

容量評估是架構師必備的技能之一,場景的容量評估包括數據量、併發量、帶寬、CPU/MEM/DISK等。
從而提前對系統和平臺進行系統或功能的改造和升級,來達到支撐業務需求的目的。

相關博文:系統容量評估


雙十一預演

雙十一預演是在測試環境,提前把時間設置爲雙十一當天。當然,這裏並非是通過修改系統時間來模擬,而是修改jvm的時間,來達到模擬雙十一當天的效果。
這樣,能達到提前測試雙十一當天可能存在的業務問題和風險,從而提前發現業務問題。


全鏈路壓測

基於實際的生產業務場景、系統環境,模擬海量的用戶請求和數據對整個業務鏈進行壓力測試,並持續調優的過程。
針對業務場景越發複雜化、海量數據衝擊下整個業務系統鏈的可用性、服務能力的瓶頸,讓技術更好的服務業務,創造更多的價值。

相關博文:聊聊全鏈路壓測


故障演練

伴隨着海量請求、節假日峯值流量和與日俱增的系統複雜度一起出現的,很有可能是預料之中以及意料之外的各種故障。在很多情況下,由於事故處理預案的缺失或者預案本身的不可靠,以及開發人員故障處理經驗的缺失,造成在各種報警之中自亂了陣腳,從而貽誤了最佳戰機。特別是一些平時線上沒出現過的異常故障,一旦突然出現,往往措手不及。
系統是否足夠健壯?是否有足夠的能力應對故障的發生?當面臨故障時會出現什麼行爲?我們並不希望真正線上出現故障時纔去驗證這些問題,這樣風險太大,成本太大。所以希望在線上環境隔離真實流量的情況下,提前模擬產生各種任何可能發生的故障,來觀察系統的反應,驗證預期策略。

相關博文:
阿里電商故障治理和故障演練實踐
如何做好一次故障演練?

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章