天貓618大促復盤框架「京東618思維導圖」

1 背景與挑戰(zhàn)1.1 背景介紹1.1.1 課程概述了解雙11 的歷程學習當前主流的電商系統(tǒng)架構(gòu)體系了解大促對電商系統(tǒng)的一些挑戰(zhàn)面對大促活動，站在架構(gòu)師角度思考，可能有哪些問題，如何應對1.1.2 雙11歷程

（最早接觸雙11的年份？）

起于2009年，剛開始的雙十一還并不出名，電商開展促銷月都是以各自的店慶月作為基礎的。國美在線是4月份，京東6月份，易購8月份，而淘寶商城選擇了雙十一作為促銷月。促銷的初衷是光棍節(jié)(11月11日)大家沒事干，就該買點啥東西去當禮物送人。于是乎，雙11就這樣誕生了。

2009年 銷售額0.52億，27家品牌參與;2010年 銷售額9.36億，711家品牌參與；2011年 銷售額33.6億，2200家品牌參與；2012年 銷售額132億，10000家品牌參與；2013年 銷售額352億，20000家品牌參與；2014年 銷售額571億，27000家品牌參與；2015年 銷售額912億，40000家品牌參與；2016年 銷售額1207億，98000家品牌參與；2017年 銷售額1682億，140000家品牌參與；2018年 銷售額2135億，180000家品牌參與；截止到2019年11日23時59分59秒 銷售額2684億。

了解雙11背景下電商公司的應對措施，有助于提升高訪問量背景下的系統(tǒng)架構(gòu)知識。

1.2 電商整體架構(gòu)1.2.1 概述

從組織架構(gòu)到技術(shù)架構(gòu)，當前各大電商系統(tǒng)基本趨于中臺化。中臺在2015由阿里提出，其實是一種企業(yè)架構(gòu)而不是單純的技術(shù)層面，目前幾乎各大電商都進行著中臺化的建設。

? 中臺沒有什么神秘的，說到底，中臺就是對 ”共享“ 理念系統(tǒng)化的歸納和總結(jié)。

重復功能建設和維護帶來的重復投資煙囪式建設造成系統(tǒng)壁壘，數(shù)據(jù)孤島業(yè)務沉淀促進可持續(xù)發(fā)展大中臺小前臺快速響應市場的需要

?

1.2.2 上層業(yè)務

? 即大中臺，小前臺的前臺，電商中直面用戶的B2B,B2C等各個業(yè)務線。

1.2.3 業(yè)務中臺

? 業(yè)務中臺基于公共服務的沉淀，需要收斂一些基礎的業(yè)務服務，如商品、訂單、會員、庫存、財務、結(jié)算等等。

1.2.4 數(shù)據(jù)中臺

? 數(shù)據(jù)中臺不是一個平臺，也不是一個系統(tǒng)。數(shù)據(jù)倉庫、數(shù)據(jù)平臺和數(shù)據(jù)中臺是有區(qū)別的。簡單的舉例：數(shù)據(jù)平臺可以理解為數(shù)據(jù)庫，數(shù)據(jù)倉庫類比為報表，而數(shù)據(jù)中臺更貼近上層業(yè)務，帶著業(yè)務屬性。

1.2.5 技術(shù)中臺

? 與業(yè)務無關的基礎沉淀，中間件，系統(tǒng)框架，監(jiān)控，日志，集成部署等等

1.2.6 運維中臺

? 不一定存在，系統(tǒng)運維相關的內(nèi)容，硬件，機房，包括企業(yè)云平臺的建設等可以劃分為單獨的運維中臺

1.3 面臨挑戰(zhàn)1.3.1 考量維度

（根據(jù)項目情況有所偏重，例如分布式與一致性是一對矛盾）

高性能：提供快速的訪問體驗。高可用：網(wǎng)站服務7*24正常訪問。可伸縮：硬件彈性增加/減少能力（快速擴容與釋放）。擴展性：方便地增加/減少新的功能/模塊（迭代與服務降級）。安全性：安全訪問和數(shù)據(jù)加密、安全存儲等策略。敏捷性：快速應對突發(fā)情況的能力（災備等）。1.3.2 內(nèi)部瓶頸木桶效應：水管最細的地方?jīng)Q定流量，水桶最低的地方?jīng)Q定容量（QPS壓測調(diào)優(yōu)為例）CPU：序列化和反序列化、復雜運算、大量反射、大量線程的應用內(nèi)存：使用內(nèi)存的中間件或服務，如redis，memcache，jvm大量對象堆積內(nèi)存的應用等網(wǎng)絡帶寬：大流量高并發(fā)環(huán)境下，雙11用戶訪問量激增，造成網(wǎng)絡擁堵磁盤IO：文件上傳下載，數(shù)據(jù)庫頻繁讀寫，不合理或大批量的日志輸出數(shù)據(jù)庫連接數(shù)：應對雙11，應用服務器連接池大批擴容，警惕底層數(shù)據(jù)庫、Redis等連接數(shù)瓶頸1.3.3 外部服務短信：外部短信延遲與送達率問題，可以搭建短信平臺，多家渠道做路由和切換分流（讓你設計短信平臺，會考慮哪些問題？如何做架構(gòu)？）支付：銀行支付與回調(diào)延遲，搭建支付中心，對接多支付渠道快遞對接：快遞服務對接（快遞100）外部云存儲：云存儲文件訪問，流量擴容（大家所使用的存儲？nfs的架構(gòu)與事故）CDN：外部靜態(tài)文件訪問提速服務（使用過的項目？）2 應對措施

? 該小節(jié)從中臺的各個團隊角度，介紹雙11期間的一些應對措施和遇到的問題。

2.1 業(yè)務中臺2.1.1 訂單中心1）異步化

（異步化的目的是什么？大家使用過的mq？遇到的問題？）

場景：

? 大促期間新增許多需要獲取訂單狀態(tài)的服務，比如應對雙11而臨時增加的數(shù)據(jù)中臺訂單大屏展示等

解決：

? 異步化，并對消息隊列調(diào)優(yōu)，多隊列分流

問題：

? 注意異步化引發(fā)的亂序問題，一是傳輸階段，二是消費階段

? 局部有序與絕對有序

圖解：

rabbitmq傳輸：隊列級別順序保障，單消費者消費一個隊列可以嚴格保障順序性，需要擴充隊列數(shù)提升性能

kafka傳輸：分區(qū)級別順序保障，只能保障投放和傳輸階段的順序性

消費階段：1對1消費存在性能問題，接收消息后對key做二次分發(fā)，放入多個內(nèi)存隊列，開啟多線程消費

2）過期訂單

（場景及思考，如果讓你做架構(gòu)設計有什么方案？這些方案有什么優(yōu)缺點）

? 雙11搶單是最常見的場景，搶單不支付會占據(jù)大批量資源，如商品庫存。如何取消過期訂單是架構(gòu)師必須面對的問題。主要有以下幾種方案：

掃表實現(xiàn)

原理：

? 通過定時任務輪詢掃描訂單表，超時的批量修改狀態(tài)

優(yōu)點：

實現(xiàn)非常簡單

缺點:

大量數(shù)據(jù)集，對服務器內(nèi)存消耗大。數(shù)據(jù)庫頻繁查詢，訂單量大的情況下，IO是瓶頸。存在延遲，間隔短則耗資源，間隔長則時效性差，兩者是一對矛盾。不易控制，隨著定時業(yè)務的增多和細化，每個業(yè)務都要對訂單重復掃描，引發(fā)查詢浪費

java延遲隊列實現(xiàn)

原理：

? 通過DelayQueue，每下一單，放入一個訂單元素并實現(xiàn)getDelay()方法，方法返回該元素距離失效還剩余的時間，當<=0時元素就失效，就可以從隊列中獲取到。啟用線程池對數(shù)據(jù)監(jiān)聽，一旦捕獲失效訂單，取出之后，調(diào)用取消邏輯進行處理。（多線程課題案例）

優(yōu)點:

基于jvm內(nèi)存，效率高，任務觸發(fā)時間延遲低。

缺點:

存在jvm內(nèi)存中，服務器重啟后，數(shù)據(jù)全部丟失。依賴代碼硬編碼，集群擴展麻煩依賴jvm內(nèi)存，如果訂單量過大，無界隊列內(nèi)容擴充，容易出現(xiàn)OOM需要代碼實現(xiàn)，多線程處理業(yè)務，復雜度較高多線程處理時，數(shù)據(jù)頻繁觸發(fā)等待和喚醒，多了無謂的競爭

消息隊列實現(xiàn)

原理：

? 設置兩個隊列，每下一單放一條進延遲隊列，設定過期時間。消息一旦過期，獲取并放入工作隊列，由consumer獲取，喚起超時處理邏輯

? 如果采用的是RabbitMQ，其本身沒有直接支持延遲隊列功能，可以針對Queue和Message設置 x-message-ttl，用消息的生存時間，和死信隊列來實現(xiàn)，具體有兩種手段， A: 通過隊列屬性設置，隊列中所有消息都有相同的過期時間，粗粒度，編碼簡單 B: 對消息進行單獨設置，每條消息TTL可以不同，細粒度，但編碼稍微復雜。

優(yōu)點：

消息存儲在mq中，不占用應用服務器資源異步化處理，一旦處理能力不足，consumer集群可以很方便的擴容

缺點：

可能會導致消息大量堆積mq服務器一旦故障重啟后，持久化的隊列過期時間會被重新計算，造成精度不足死信消息可能會導致監(jiān)控系統(tǒng)頻繁預警

redis實現(xiàn)

原理：

? 利用redis的notify-keyspace-events，該選項默認為空，改為Ex開啟過期事件，配置消息監(jiān)聽。每下一單在redis中放置一個key（如訂單id），并設置過期時間。

優(yōu)點:

消息都存儲在Redis中，不占用應用內(nèi)存。外部redis存儲，應用down機不會丟失數(shù)據(jù)。做集群擴展相當方便依賴redis超時，時間準確度高

缺點:

訂單量大時，每一單都要存儲redis內(nèi)存，需要大量redis服務器資源

被動取消

原理：

? 在每次用戶查詢訂單的時候，判斷訂單時間，超時則同時完成訂單取消業(yè)務。

優(yōu)點：

實現(xiàn)極其簡單不會有額外的性能付出不依賴任何外部中間件，只是應用邏輯的處理

缺點：

延遲度不可控，如果用戶一直沒觸發(fā)查詢，則訂單一直掛著，既不支付也未取消，庫存也就被占著2.1.2 支付中心

支付交互流程，支付系統(tǒng)設計偏重，關于做過的那些支付系統(tǒng)2014與2018的架構(gòu)變化，政策的變動經(jīng)歷。

1）重復支付

（2018重復支付事故）

原因：

? 在第一步發(fā)起的時候，用戶進入支付方式選擇頁。選第一個支付方式并支付完后因為通知延遲，以為支付失敗。在支付又選了第二種，再次支付。

應對方案：

? 程序屏蔽，前端js觸發(fā)按鈕置灰或者遮罩提示（支付成功？遇到問題？），或者在支付方式選擇頁直接跳轉(zhuǎn)。

? 后端處理，發(fā)現(xiàn)不同通道下的支付成功回調(diào)，拋消息隊列或記錄日志。

數(shù)據(jù)修復：

? 首先查支付日志，確認針對同一筆訂單收到了不同支付渠道的回調(diào)。

? 其次，在支付平臺管理后端可以查到入賬記錄，人工介入。

? 最后對賬階段會發(fā)現(xiàn)對方多帳，我方補單時出現(xiàn)重復訂單。

問題處理：

? 調(diào)取退款接口或者在支付渠道的管理后臺操作退款（一定要多次確認無誤）。

2）異常訂單

支付但未開單

場景：

? 用戶明明支付成功，但未開通訂單

問題分析：

? 一般支付渠道會間隔性多次回調(diào)開單鏈接，如果支付未開單，銀行未回調(diào)的可能性比較小，著重排查開單接口是否可用。如果可用追查日志是否出現(xiàn)異常記錄。

應對措施：

對賬階段可以查漏，程序自動完成補單，但是處理相對延遲，取決于支付渠道的對賬文件下發(fā)周期（2011-2013年，支付測試數(shù)據(jù)與財務人工對賬的歷程）人工補單，人工查詢支付渠道后臺數(shù)據(jù)，確認已支付的情況下，介入補單流程人工處理

未支付但已開單

場景：

? 用戶未支付，或者財務中心未收到這筆款項，訂單狀態(tài)已開通。這種就問題比較嚴重了

應對措施：

? 首先排除人為操作因素。其次排查系統(tǒng)是否存在漏洞或者級聯(lián)開單的情況（支付中心測試環(huán)境數(shù)據(jù)回調(diào)造成線上意外開單經(jīng)歷）

3）回調(diào)延遲

場景：

? 用戶是期望支付完成的同時立馬看到結(jié)果。但是中間多層遠程的調(diào)用，可能發(fā)生訂單狀態(tài)更新延遲問題。

解決：

? 主動查詢。在用戶查看訂單的時候，如果是類似“支付中”的中間態(tài)時，觸發(fā)遠程訂單狀態(tài)查詢接口。（大家看到的點擊“支付完成”跳轉(zhuǎn)的過程，觸發(fā)遠程支付結(jié)果查詢）

4）支付路由

（你所看到的收銀臺圖標內(nèi)情...）

背景：

? 保障支付可用性及支付分流，支付中心對接多家渠道

方案：

支付中心對接多個支付渠道，支付寶，微信，各銀行或第三方支付供應商。對不同用戶，進入支付方式選擇頁時，做支付分流。做好監(jiān)控統(tǒng)計，一旦某個支付渠道不可用或者延遲較大，切掉，下線，或者降權(quán)。2.1.3 營銷中心1）概述

? 大促和活動不分家，一般營銷中心所面對的主要是促銷策略、優(yōu)惠方式等業(yè)務上的架構(gòu)問題。

? 從促銷活動的范圍來看，分為單品促銷活動、套裝促銷活動、店鋪促銷活動，平臺促銷活動。

? 從促銷類型來看，分為滿減、折扣、贈品等。

? 業(yè)務復雜度高，一般遵循 “同類營銷僅可選其一，不同類營銷可疊加” 的規(guī)則。同類疊加意義不大且會造成系統(tǒng)復雜度上升，引發(fā)用戶困惑。

2）前端設計

? 用戶體驗上的設計，比如購物車里商品的排序，按商鋪分門別類。優(yōu)惠總價格及時調(diào)整。這些依賴于前端的ui設計和交互體驗。

3）贈品設計

(SPU , SKU 基礎概念，如何設計表結(jié)構(gòu)？京東怎么做的)

? 贈品有兩種設計方案，一種是不做單獨的SKU，只有一個空的描述，設計簡單，缺點是沒有商品詳情頁，無法給用戶直觀的查看和估值。

? 另一種是單獨做SKU，贈品也會作為一個商品存在，與主商品關聯(lián)，下單的時候?qū)詣蛹拥缴唐妨斜恚瑑r格降為0。這種更為常見。整個商品有完善的詳情頁，用戶可以直接看到價格甚至單獨下單購買。

4）排他與優(yōu)先級

? 檢查同類別促銷，將最大優(yōu)惠力度的規(guī)則應用到訂單，并且滿足排他性，同類只享受其一。比如滿10減3，滿20減5，那么用戶購買大于20時，只減5即可。

? 不同類別不做排斥，如購物車整體滿減后，不影響單個商品的折扣。在記錄數(shù)據(jù)時，優(yōu)惠要細化到每個單獨的訂單明細上。退款也做到明細級別的單獨退。

5）價格分攤

（有沒有遇到精度問題？價格字段如何設計？）

? 滿減或平臺券等優(yōu)惠，在多個商品下單時，涉及到金額的分攤。即 優(yōu)惠總額度/購物車總額 ，得到比例后再按比例均分到每個商品。只有分攤才能在發(fā)生部分退款時退回真實金額。

? 但是這會涉及到一個精度問題。舉例如下：滿99減9活動，假設用戶購買了 30 40 50=120，3件商品應付111元。按比例折算的話，9/99取4位小數(shù)是0.9090，那么分攤后為 30x0.9090 40x0.9090 50x0.9090=109.08與實際支付金額出現(xiàn)偏差。這會造成財務無法平賬。

? 解決方案：記賬時在訂單明細記錄，將誤差 111-109.08=1.92計入金額最大的明細，也就是50元商品上。那么最終記賬為：30x0.9090 40x0.9090 （50*0.909 1.92）= 111

6）退單處理

? 退單后要同時恢復用戶的權(quán)益，比如優(yōu)惠券的再次使用，限購次數(shù)等。確保用戶體驗。

2.1.4 商品中心1）限時商品的下架控制

? 這個和超時訂單設計方案類似，前面已經(jīng)提到不再贅述。

2）庫存管理

? 普通商品可以直接借助數(shù)據(jù)庫鎖實現(xiàn)，一般分樂觀鎖和悲觀鎖兩種方案，如果采用悲觀鎖（如select語句帶forupdate），會帶來很大的性能阻塞，所以更多的采用樂觀鎖設計。（冪等性課題的鎖機制有詳細講解）

? 樂觀鎖就是在最后執(zhí)行庫存扣減操作時，將事務開始前獲取的庫存數(shù)量帶入到SQL語句中作為更新的where條件，如果數(shù)量相等，則該條更新庫存的語句成功執(zhí)行返回update條數(shù)為1；如果不相等，則表示該商品的庫存信息已經(jīng)被其他事務修改，需要放棄該條update的執(zhí)行，采用重試處理。

? 庫存秒殺商品因為大批量的訪問在一瞬間涌入，數(shù)據(jù)庫扛不住。可以采用 redis緩存做decr處理，正常下單后，再使用mq異步更新到db。（秒殺不超賣課題的庫存控制）

2.2 技術(shù)中臺2.2.1 數(shù)據(jù)庫優(yōu)化

? 數(shù)據(jù)庫層的調(diào)優(yōu)，一般發(fā)生在大促前的預備階段，一旦大促開始，對數(shù)據(jù)庫的優(yōu)化已經(jīng)來不及了。

在大促開始前梳理耗時查詢業(yè)務，對關鍵業(yè)務壓測。開啟mysql的慢查詢?nèi)罩荆▋煞N方式）#配置文件方式，需要重啟mysql #日志文件位置 log-slow-queries=/opt/data/slowquery.log #超時時間，默認10s long_query_time=2 #臨時開啟，不需要重啟 set global slow_query_log=on; set global long_query_time=10; set global slow_query_log_file=‘/opt/data/slow_query.log’ 復制代碼使用mysqldumpslow命令解析mysql慢查詢?nèi)罩?- 慢查詢?nèi)罩疽晕谋敬蜷_，可讀性很高 -- 查詢次數(shù)，耗時，鎖時間，返回結(jié)果集條數(shù)（掃描行數(shù)），執(zhí)行者 Count: 1 Time=10.91s (10s) Lock=0.00s (0s) Rows=1000.0 (1000), mysql[mysql]@[10.1.1.1] SELECT * FROM order_history 復制代碼借助explain查看sql執(zhí)行計劃，對sql調(diào)優(yōu)，或其他優(yōu)化工具。2.2.2 緩存優(yōu)化

（業(yè)務篇紅包雨課題里有緩存結(jié)構(gòu)的深度應用）

1） 策略

熱點數(shù)據(jù)預熱：

（常規(guī)加載機制畫圖展示）

? 常規(guī)緩存設計趨向于懶加載，大促期間的熱點數(shù)據(jù)盡量做到預熱加載。比如某個促銷專題，不要等待活動開始的一瞬間再讀庫加緩存，搞不好引發(fā)擊穿。

細粒度設計：

（細粒度緩存結(jié)構(gòu)畫圖展示）

? 集合與單體分開存儲，緩存結(jié)構(gòu)細粒度化。如某個櫥窗的推薦商品列表，常規(guī)存儲一個key，value為整個商品集合。優(yōu)化為列表與每個商品詳細信息設置兩個獨立緩存值，在查詢環(huán)節(jié)組裝，可以降低發(fā)生修改時對緩存的沖擊。新增一個推薦則失效列表，修改商品則僅僅失效當前商品緩存。

可用性：

（回顧三種緩存問題）

只要緩存失效時間設置分散，雪崩的可能性不大防范惡意攻擊引發(fā)穿透，前端做到防刷，業(yè)務層面要注意合法性校驗，非法key的失效時間需要評估。擊穿可能性升高，大促高并發(fā)下，修改時，如果采用key刪除策略很可能觸發(fā)擊穿，修改少可以優(yōu)化為雙寫。2）多級緩存

? 優(yōu)化緩存體系，對關鍵業(yè)務請求，如商品詳情頁，采用多級緩存處理

? 首先看瀏覽器緩存，一般瀏覽器緩存可分為兩種手段，分別交給瀏覽器和服務端執(zhí)行

客戶端判決：為請求header設置Expires（http1.0） 和 Cache-Control（http1.1），客戶端本地比較決定是否使用緩存服務端判決：借助Last-Modified/If-Modified-Since（http1.0）或ETag/If-None-Match，服務器端比較決定返回200帶body還是304僅有head頭 (畫圖展示)Last-Modified < ETag < Expires < Cache-Control

? CDN：借助CDN的dns解析，對用戶做ip分流，CDN作為應用服務器的代理，抵擋前端的流量洪峰。同樣，前面提到的http緩存策略對CDN依然有效。

? Nginx緩存：nginx除了作為負載均衡，也可以作為請求級別的緩存，一段典型配置如下：

　　proxy_cache_path 緩存文件路徑

　　levels 設置緩存文件目錄層次；levels=2:2:2 表示三級目錄，每級用2位16進制數(shù)命名

　　keys_zone 設置緩存名字和共享內(nèi)存大小

　　inactive 在指定時間內(nèi)沒人訪問則被刪除

　　max_size 最大緩存空間，如果緩存空間滿，默認覆蓋掉緩存時間最長的資源。

# 定義緩存路徑、過期時間、空間大小等 proxy_cache_path /tmp/nginx/cache levels=2:2:2 use_temp_path=off keys_zone=my_cache:10m inactive=1h max_size=1g; server { listen 80; server_name xxx.xxx.com; # 添加header頭，緩存狀態(tài)信息 add_header X-Cache-Status $upstream_cache_status; location / { # 定義緩存名 proxy_cache my_cache; # 定義緩存key proxy_cache_key $host$uri$is_args$args; # 針對返回狀態(tài)碼單獨定義緩存時間 proxy_cache_valid 200 304 10m; # url 上設置請求 nocache=true 時不走緩存。 proxy_cache_bypass $arg_nocache $http_nocahe; proxy_pass http://localhost:8080; } }復制代碼

? 分布式緩存：redis做應用層緩存，不多解釋。但是要注意做好擴容預案和業(yè)務層優(yōu)化

依據(jù)預估量做相應的擴容或資源申請，純做緩存時可以關閉持久化，內(nèi)存超出60%將變得不穩(wěn)定。頻繁交互業(yè)務從java端下移到lua腳本實現(xiàn)，一方面可以實現(xiàn)原子性，另一方面有效減少網(wǎng)絡延時和數(shù)據(jù)的冗余傳輸。以平臺優(yōu)惠券領取為例：（搶紅包接口課題有涉及）2.2.3 分流與限流

（算法與數(shù)據(jù)結(jié)構(gòu)應用 - 限流算法有詳細實現(xiàn)）

? CDN的引入本身起到了按ip分流的作用，但是我們可以在下層做到更細粒度化的控制。根據(jù)業(yè)務情況將不同的請求分流到各自的服務器。

? 限流不同與分流，是對下層的保護，當系統(tǒng)超過一定流量后，超過的流量做直接拒絕處理，以便保護后端的服務，原則就是要么不進來，進來的都正常服務。常見的限流算法有三種：計數(shù)器（滑動窗口）、漏桶、令牌桶。

1） 業(yè)務分流

? 根據(jù)不同的業(yè)務線分發(fā)請求，配備二級域名如b2b.xxx.com，b2c.xxx.com，或者在nginx軟負載層針對不同虛擬主機名做upstream分發(fā)

? 新上的雙11活動頁，或者促銷專題頁面，采用新訪問入口和機器部署，與主站分離。活動結(jié)束后也利于機器資源的快速釋放（有沒有遇到臨時性需求的場景？上線就用1天）

2） 終端分流

? 按不同的請求終端分流，在header頭的user-agent中可以捕獲用戶的訪問終端。android，ios，pc，根據(jù)不同終端設備，做流量分發(fā)，到不同的應用機器。同時方便對用戶終端流量的監(jiān)控和統(tǒng)計。

3）nginx限流

? 評估雙11可能的流量，結(jié)合具體業(yè)務模塊，配備對應限流措施。主要有流量限制和連接數(shù)限制兩個維度。

? 流量限制：限制訪問頻率，其目的是基于漏桶算法實現(xiàn)ip級別的防刷。Nginx中使用 ngx_http_limit_req_module 模塊來限制請求的訪問頻率，基于漏桶算法原理實現(xiàn)。

#$binary_remote_addr 表示通過remote_addr這個標識來做限制#binary_的目的是縮寫內(nèi)存占用量，是限制同一客戶端ip地址#zone=one:10m表示生成一個大小為10M，名字為one的內(nèi)存區(qū)域，用來存儲訪問的頻次信息#rate=1r/s表示允許相同標識的客戶端的訪問頻次limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; server { location /b2b/ { #zone=one 設置使用哪個配置區(qū)域來做限制，與上面limit_req_zone 里的name對應 #burst=5,設置一個大小為5的緩沖區(qū),當有大量請求時，超過了訪問頻次限制的請求可以先放到這個緩沖區(qū)內(nèi) #nodelay，如果設置，超過訪問頻次而且緩沖區(qū)也滿了的時候就會直接返回503,如果沒有設置，則所有請求會等待排隊 limit_req zone=one burst=5 nodelay; }}復制代碼

? 連接數(shù)限制：Nginx 的 ngx_http_limit_conn_module模塊提供了對資源連接數(shù)進行限制的功能。（同一個出口ip，如公司內(nèi)部共享一個出口ip，可能會被整體限制）

#$binary_remote_addr同上limit_conn_zone $binary_remote_addr zone=addr:10m;server { location /b2b/ { # 限制每個ip下最大只能有一個連接 limit_conn addr 1; }}復制代碼4）網(wǎng)關限流

? 從代理服務器放進來的流量，會進入應用服務器，第一道關卡是微服務的網(wǎng)關。應對大促，針對各個微服務具體業(yè)務具體分析，配備對應限流措施。zuul和gateway是團隊中最常遇到的網(wǎng)關組件。

zuul.routes.userinfo.path=/user/**zuul.routes.userinfo.serviceId=user-servicezuul.ratelimit.enabled=truezuul.ratelimit.policies.userinfo.limit=3zuul.ratelimit.policies.userinfo.refresh-interval=60zuul.ratelimit.policies.userinfo.type=origin復制代碼routes: - id: user_route uri: http://localhost:8080 predicates: - Path=/* filters: - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 1 redis-rate-limiter.burstCapacity: 1 key-resolver: "#{@ipKeyResolver}復制代碼2.2.4 服務降級

? 當服務器壓力劇增的情況下，根據(jù)實際業(yè)務情況及流量，對一些服務和頁面有策略的不處理或換種簡單的方式處理，從而釋放服務器資源以保證核心交易正常運作或高效運作。是一種舍車保帥的策略。

? 比如平時客戶來我的店鋪購買衣服。平時可以試穿，給出建議，幫助搭配，最后下單支付，送用戶祝福卡片等。雙11大促則簡單粗暴響應下單支付收錢發(fā)貨。其他不太重要的服務關閉開關，騰出資源讓位主交易流程。

? 服務降級可以從前端頁面，后端微服務兩個點著手。

1）頁面降級

? 很好理解，針對頁面元素處理，將不重要的操作入口置灰或屏蔽。平時調(diào)用后端接口實時呈現(xiàn)數(shù)據(jù)的地方替換為靜態(tài)頁也可以理解為一種降級操作。

2）微服務降級

? 配置接口開關，并通過配置中心可以靈活開閉。必要時關閉開關，屏蔽接口的實際查詢，直接返回mock數(shù)據(jù)。例如，購買了本商品的用戶還購買過哪些商品接口，在業(yè)務上需要調(diào)用數(shù)據(jù)中臺訂單統(tǒng)計服務，訪問量大時，關閉對外調(diào)用，直接返回設置好的一批相關商品，起到降級保護作用。

3）快速熔斷

? 快速熔斷可以認為是在應對突發(fā)情況時，對服務請求結(jié)果準確性的一種妥協(xié)。避免因單一服務垮臺導致整個調(diào)用鏈路崩潰。常用手段如下：

拋異常：這種處理需要上層配備異常處理機制，在捕獲異常時，導向錯誤頁、等待頁或稍后重試等。返回NULL：簡單粗暴，可能會出現(xiàn)空白結(jié)果，并不友好。調(diào)用Fallback處理邏輯：更人性化的手段，也最常用。為每個業(yè)務配備一個備選方案。

? 舉個例子：商品頁或訂單詳情頁面，一般都會有猜你喜歡這個模塊，通過對用戶的購買行為、瀏覽記錄、收藏記錄等等進行大數(shù)據(jù)分析，然后給每一個用戶推送自己可能喜歡的商品。在雙11大促背景下，如果推薦服務壓力過大，出現(xiàn)服務出錯、網(wǎng)絡延遲等等之類突發(fā)情況，導致最后調(diào)用服務失敗，則可以配備一個fallback，直接返回當前商品同類別下的幾款商品，作為備選方案，這比拋異常或者返回null空白頁面體驗要更優(yōu)。

2.2.5 安全性

? 大促前做好安全防范。常見的DDos，Arp，腳本等攻擊平時也會存在，日常防范已經(jīng)配備。大促期間需要注意的可能更多的是業(yè)務層面的入侵，比如搶購或秒殺時的惡意刷接口。

實名制，限制單用戶，單ip等維度下的頻次必要的地方添加驗證碼（圖片復雜度升級，或滑塊等新型方式）黑名單機制，一旦發(fā)現(xiàn)惡意行為，列入黑名單，并自動維護2.3 運維中臺2.3.1 做好災備

（2018從一次斷電看災備的背景與經(jīng)歷，30分鐘以內(nèi)）

? 災備是應對大型故障的保底措施，最好的結(jié)局是永遠不要觸發(fā)，但是大促前需要做好災備切換演練，可以選擇大促前用戶量少的時間段進行：

1）前期準備：兩地災備程序同步維護，大促相關的迭代和活動專題上線確保兩地測試ok，鏡像版本統(tǒng)一

2）數(shù)據(jù)庫配置兩地主從，或雙主單寫。切換前做好數(shù)據(jù)同步性檢查

3）啟用腳本，切換代理服務器，代理流量轉(zhuǎn)入災備機房，正式環(huán)境還需要處理dns指向

4）分布式文件災備日常采用rsync等實時同步，采用云存儲的可以忽略

5）es索引等其他數(shù)據(jù)確保日常同步

6）注意掛好維護頁，友好提示

7）配備自動化測試腳本以便快速驗證切換結(jié)果

2.3.2 配備監(jiān)控1）基礎設施監(jiān)控

? 包括物理機、Docker 容器、以及對交換機、IP 進行監(jiān)控 （容器課題）

? 借助zabbix等開源軟件對機器資源配置監(jiān)控，如果采用云化部署，各大云供應商都會配備完善的監(jiān)控機制

2）應用級監(jiān)控

? 主動監(jiān)控，日志或消息隊列形式打點輸出，定時匯報 （日志平臺追蹤課題）

? 被動監(jiān)控，添加監(jiān)控接口，監(jiān)控系統(tǒng)定時請求確認可用性

3）業(yè)務監(jiān)控

? 對具體業(yè)務點做監(jiān)控處理，如訂單量、登錄量、注冊量、某些頁面的訪問量等關鍵點采用異步消息方式推送到監(jiān)控中心，監(jiān)控中心針對特定隊列的數(shù)據(jù)做統(tǒng)計和展示。

4）客服一線反饋

? 主動監(jiān)控依然無法察覺的情況下，來自客服的一線反饋成為最后關卡。優(yōu)先級也最高。開發(fā)故障快速響應平臺，做到實時性保障。做到客服 - 業(yè)務線 - 產(chǎn)品 - 技術(shù)排查的及時響應，快速排查。

2.3.3 資源盤點1）網(wǎng)絡設施擴容

? 網(wǎng)絡帶寬是影響訪問流量的重要因素，做好各個機房網(wǎng)絡帶寬預估，數(shù)據(jù)在兩地機房間傳輸并且要求低延遲的場景，如數(shù)據(jù)庫主從，可以考慮機房專線。使用公有云的服務，可以購買臨時流量。

2）硬件資源盤點

? 對容量做預估和硬件資源盤點。配合大促期間不同服務的架構(gòu)設計，以及項目本身的特性，對cpu，內(nèi)存做評估。偏運算的項目，重度使用多線程的項目偏cpu，需要大量對象或集合處理的項目偏內(nèi)存。

3）容器盤點

? 所有項目容器化部署，基于鏡像即版本理念，打好各個服務的鏡像是docker快速復制擴容的基礎。大促前對各個中心微服務做統(tǒng)計和盤點。

? 借助swarm和k8s等編排工具，快速實現(xiàn)容器的伸縮。 （運維篇會講到）

2.4 數(shù)據(jù)中臺

? 數(shù)據(jù)中臺多為大數(shù)據(jù)相關架構(gòu)體系，大促期間，同樣可能面臨大批數(shù)據(jù)洪峰，比如訂單量激增、用戶行為數(shù)據(jù)暴漲等場景。簡單看一下可能需要做的一些應對。（大屏實時計算課題）

2.4.1 數(shù)據(jù)通道

? 對數(shù)據(jù)傳輸通道擴容，比如kafka擴大分區(qū)數(shù)，rabbitmq增加細分隊列。一方面實現(xiàn)了擴容，另一方面在傳輸?shù)钠鹗茧A段就對數(shù)據(jù)做了一定的分類。

? 數(shù)據(jù)降級，關閉某些非核心數(shù)據(jù)的通道采集，讓位網(wǎng)絡帶寬給核心業(yè)務數(shù)據(jù)。

2.4.2 數(shù)據(jù)展示

? 數(shù)據(jù)大屏開發(fā)。對實時性有一定要求，多采用流式運算。

2.5 其他準備2.5.1 流量預估

? 對關鍵業(yè)務的體量做好預估。如用戶的注冊、下單量、首頁，商品詳情頁等關鍵頁面的qps，為壓測提供參考指標。

2.5.2 資源預估

? 架構(gòu)師統(tǒng)計各中心服務關系，對各個服務擴容做預估，匯總。

2.5.3 壓測準備

（全鏈路壓測課題）

1）線下壓測

（大家當前使用的環(huán)境都有哪些？上線模式是什么樣的）

? 當前成熟系統(tǒng)都具備各種環(huán)境，開發(fā)環(huán)境、測試環(huán)境、準生產(chǎn)環(huán)境等，對線下可以選擇準生產(chǎn)環(huán)境做為壓測，模擬線上。

? 線下壓測數(shù)據(jù)安全，不必擔心對線上造成干擾。所壓測的值可以用于相對性比較，比如其中全鏈路的某個環(huán)境哪個是瓶頸。但是無法精準反饋線上的真實場景。

2）線上壓測（謹慎！）

? 重點看線上壓測，線上壓測壓出的數(shù)據(jù)是最真實有效的。但是因為使用的是生產(chǎn)環(huán)境，操作不當可能引發(fā)災難性后果。

? 1）在全鏈路壓測環(huán)境下，服務調(diào)用關系錯綜復雜，最重要的是實現(xiàn)壓測流量的標識，以及標識在服務上下文間如何有效傳遞不丟失。服務內(nèi)借助threadlocal，但是要注意多線程下失效。服務間通過改寫遠程調(diào)用框架或借助框架提供的Context設置。（分布式日志平臺，訪問鏈路追蹤課題）

? 2）數(shù)據(jù)隔離，數(shù)據(jù)庫可以創(chuàng)建影子表，redis等緩存可以設置shadow_等前綴，從開發(fā)框架層面封裝處理，對數(shù)據(jù)層持久化框架做二次開發(fā)，使其自動發(fā)現(xiàn)壓測數(shù)據(jù)。

? 3）外部服務可以借助服務降級功能，添加開關判斷屬于壓測流量時開關進入降級或mock，比如收銀程序添加擋板，直接返回成功，短信應用直接默認一個短信號碼。

? 4）日志打印需要隔離，可以借助分布式日志平臺收集時采用不同的輸出通道和隊列。

? 5）壓測數(shù)據(jù)最好的方式是流量克隆（TCPCopy工具等），將線上的實際訪問請求克隆放大幾倍加壓到壓測入口，如果實現(xiàn)不了，盡量模擬線上的真實數(shù)據(jù)結(jié)構(gòu)和體量。

? 5）做好全壓流量規(guī)劃，按預估2~3倍加壓，確定流量比例，打壓。

2.5.4 人員配備

? 人員互備，防止故障，及時響應，應對雙11不是什么神秘事。

作者：博學谷狂野架構(gòu)師鏈接：https://juejin.cn/post/7107494985838100517