雙11前系統如何做好高可用

如何在大促中做好系統高可用是大家都非常關心的一個問題，特別是在雙十一之前，在大促過程中做好系統高可用保障是有雙十一大促的客戶都會了解的一個內容。大流量、系統內部/下游不穩定、單機故障、熱點請求等等一系列的問題都會導致一些非預期的情況。那麼今天就圍繞大促來談談，如何在非預期的情況下，始終保持我們的系統高效工作?

確定系統容量

我們需要基於大促的應用表現，確定我們的應用在一定的業務條件下的效能基線，以及系統的成本預算。因此我們在大促前需要不斷進行多次效能評估以及效能最佳化，需要確保應用的效能。那麼如何進行有效的壓測來確定我們系統的容量呢?首先我們需要評估業務變化以及系統的變化，業務變化就比如這次業務相比之前是否有量級的提升，業務的玩法是否有變化比如 618 的預售以及搶紅包、滿減等業務玩法是否會對系統造成穩定性的風險，對使用者動向進行分析;系統的變化有比如這一次大促相比之前有無引入新的技術或者新的架構，比如之前都是部署在虛擬機器中，這一次大促是在容器上進行。總的來說，需要站從全域性視角看系統的關鍵路徑，保障核心業務，梳理強弱依賴。

以上就列舉了我們生產系統中的元件的情況，以及各個元件在大促時需要進行的防護，流量是從最外層 CDN、Niginx 到微服務閘道器、微服務應用最後再到快取、資料庫，因此流量訪問路徑上的每一環都需要做好大促的防護。如果任意一環節出問題，都會牽一髮而動全身，導致我們這次大促的失敗。

下面我將會從系統的各個層面談一談大促的高可用防護，讓系統在非預期情況下始終高質量工作。

閘道器的大促高可用

大促場景下，閘道器做高可用防護為什麼重要?一言以蔽之，閘道器具備將大促的各種不確定性因素轉化為確定性因素的能力，並且這種能力是不可替代的。分別從三個方面來看：

第一點是應對流量峰值的不確定性，必須透過限流規則將不確定的流量變為確定。業務服務模組自己做限流很難實現這一點。因為實現限流防護有個前提，承載這突發流量的服務仍能保持正常的 CPU 負載。業務服務模組即使實現了應用層的 QPS 限流，在瞬時高併發場景下，仍可能因為網路層大量的新建連線導致 CPU 猛漲，限流規則也就形同虛設了。業務模組應該專注在應用層業務邏輯上，若要透過擴容去應對其不擅長的網路層開銷，所需的資源成本是相當高的。而閘道器作為業務流量入口的地位，決定了其必須擅長應對高併發的網路流量，並且這塊效能也是衡量閘道器能力的一個重要指標，應對高併發的效能越強，所需的資源成本就越低，將大促流量從不確定變為確定的能力就越強。

第二點是應對使用者行為的不確定性，需要根據不同的大促場景，模擬使用者行為進行多輪壓測演練，提前發現系統的瓶頸和最佳化點。閘道器既是使用者訪問的流量入口，也是後端業務應答的最終出口。這決定了閘道器是模擬使用者行為進行流量壓測的必經一站，也決定了是觀測壓測指標評估使用者體驗的必須環節。在閘道器上邊壓測，邊觀察，邊調整限流配置，對大促高可用體系的建設，可以起到事半功倍的效果。

第三點是應對安全攻擊的不確定性。大促期間也通常是黑灰產活躍的時間，異常的刷單流量很可能觸發限流規則，從而影響正常使用者的訪問。基於閘道器的流量安全防護能力，例如 WAF 等功能，透過識別出異常流量提前攔截，以及將異常 IP、cookie 自動加入黑名單等手段，既可以使這部分流量排除在限流閾值之外，也可以保障後端業務邏輯安全。這也是大促高可用防護必不可少的一環。

微服務系統的大促高可用

面對突增的大流量

在大促過程中，如果某個時刻激增的脈衝流量到達系統(搶購/秒殺)，那麼服務可能被打掛。同時另外再考慮一個場景：服務間 RPC 呼叫需要進行細粒度管控，如服務 A 的呼叫來源有服務 B 和 C，其中 C 是重點業務，需要優先保障呼叫;但服務 B 有時會有較大併發呼叫，影響整體穩定性。因此對於微服務系統來說，特別是在大促過程中，我們需要一種應用的安全氣囊--流控能力來保障我們系統的穩定性。面對大促突發的流量，流控能力可以將超出系統服務能力以外的請求拒絕掉，我們在微服務層進行 API、介面、方法、引數粒度控制，只讓容量範圍內的請求透過。

上下游依賴不穩定

業務高峰期，某些下游的服務提供者遇到效能瓶頸，甚至影響業務。我們對部分非關鍵服務消費者配置自動熔斷，當一段時間內的慢呼叫比例或錯誤比例達到一定條件時自動觸發熔斷，後續一段時間服務呼叫直接返回 Mock 的結果，這樣既可以保障呼叫端不被不穩定服務拖垮，又可以給不穩定下游服務一些“喘息”的時間，同時可以保障整個業務鏈路的正常運轉。

單機異常

在大促的過程中，應用的某幾臺機器由於磁碟滿，或者是宿主機資源爭搶導致load很高，導致客戶端出現呼叫超時，從而影響系統的整體穩定性。我們可以透過配置離群例項摘除規則，可以自動摘除異常的例項，從而保證整體的服務治理。

流量平滑：非同步批次任務平滑處理，避免過載

非同步任務或訊息批次分發到處理端，大促過程中面對批次數過大或某些任務重負載情況，處理端將會無法及時處理任務，從而造成任務堆積，系統負載飆高，影響任務正常處理。

我們可以採用 MSE 流量治理提供的流量平滑能力(勻速排隊流控模式)，將大批次的併發任務/請求進行平滑，控制相鄰任務的處理時間間隔，多餘的任務會排隊等待處理，而不會直接拒絕。讓系統能夠更平緩地處理任務。流量平滑能力可以配合訊息佇列 RocketMQ 使用，把超過消費端處理能力的訊息均攤到後面系統空閒時去處理，可以讓 MQ 消費端負載保持在訊息處理水位之下，同時儘可能處理更多訊息，達到削峰填谷的效果。

多語言應用的大促防護

MSE 除了針對 Java 微服務的流量防護能力，還支援 Go 應用的流量防護能力。Go 應用支援 Dubbo、Gin Web、gRPC、go-micro 等應用，我們只需接入 SDK 即可具備以上提到的對應的流量防護能力。

微服務訪問資料庫/快取視角的大促高可用

對於我們的系統來說，資料庫是非常重要的一塊，微服務訪問資料庫的過程中常常會遇到一些問題：

某系統對外提供某查詢介面，SQL 語句涉及多表 join，某些情況下會觸發慢查詢，耗時長達 30s，最終導致 DB 連線池/Tomcat 執行緒池滿，應用整體不可用。

應用剛啟動，由於資料庫 Druid 連線池還在初始化中，但是此時已經大量請求進入，迅速導致 Dubbo 的執行緒池滿，許多現場卡在初始化資料庫連線的過程中，導致業務請求大量報錯。

SQL 語句處理時間比較長導致線上業務介面出現大量的慢呼叫，需要快速定位有問題的慢 SQL，並且透過一定的治理手段進行隔離，將業務快速恢復。

針對大多數的後端應用來講，系統的瓶頸主要受限於資料庫，當然複雜度的業務肯定也離不開資料庫的操作。因此，做穩做好微服務必不可少的一個部分就是做好微服務在訪問資料庫視角下的治理能力。目前 MSE 在微服務-資料庫的治理方面支援 Mybatis、Druid、HikariCp 等元件，只要我們的框架中使用到相關元件，就可以具備以下提到的完整的治理能力。

在大促過程中，一些 SQL 語句處理時間比較長導致線上業務介面出現大量的慢呼叫，我們需要快速定位有問題的慢 SQL;同時這些慢 SQL 最終會導致應用執行緒池滿，從而使得應用整體不可用。我們需要有秒級的 SQL 洞察能力，可以幫助我們觀察應用和資源 API 維度的實時資料，從而可以有效地評估系統的整體表現。

MSE 提供的SQL 洞察能力，可以分析 SQL 語句是否寫得合理，透過 SQL 執行的 TopN 列表可以快速定位併發、RT、請求量過大的 SQL 請求。定位了慢 SQL 之後，我們需要有一定的治理手段進行隔離，將業務快速恢復。當流量近似穩態時：併發執行緒數 =QPS * RT(s) ，RT 升高，併發執行緒數升高，代表服務呼叫出現堆積。

我們可以透過 SQL 洞察快速定位併發大的 SQL，並配置服務併發隔離能力，相當於一道“軟保險”，防止慢呼叫的 SQL 擠佔正常服務資源，保證服務整體的穩定性。

另外還有一些突發的場景：在大促活動中湧現一批“黑馬”熱點商品，事先無法準確預知熱點商品，無法提前預熱。這些突發的熱點流量會擊穿快取，使 DB 抖動甚至崩潰，影響了正常流量的業務處理。

透過 MSE 的熱點引數流控能力，自動識別引數中的 TopN 訪問熱度的引數值，並對這些引數進行單獨流控，避免單個熱點訪問過載;並且可以針對一些特殊熱點訪問(如極熱門的搶購單品)配置單獨的流控值。熱點限流能力支援任意業務屬性的引數、我們可以在 SQL 層面配置規則，有效保障我們應用訪問資料庫時的穩定性。

考慮到熱點商品引發的熱點流量還會將我們的 Redis 快取擊穿，在微服務訪問快取的視角上，我們可以藉助 MSE 快取治理防擊穿能力，只需配置單個 key 的最大訪問量，MSE 可以自動識別 Rediskey 中的 TopN 訪問熱度的 key，並對這些引數分別進行流控，避免單個熱點訪問過載，影響整體。並且可以針對一些特殊熱點訪問(如極熱門的搶購單品，有單獨容量)配置單獨的流控值。

總結

面對大促不確定的流量，我們需要做好全方位的流量控制與防護能力，確保我們的系統始終工作在預期的範圍之內。首先我們需要有流量的實時監控以及水位診斷分析能力，確保我們知道當前系統所處的一個狀態;在業務的鏈路入口，我們需要做好鏈路入口的容量評估以及峰值流量的限流配置、同時需要開啟熱點隔離能力，防止黑馬商品、黑產刷單等不確定因素造成的穩定性影響;在微服務內部我們需要配置單機流控，針對微服務內部非同步的流量我們可以配置流量平滑能力做到削峰填谷的效果;針對下游依賴的服務以及元件(資料庫、快取等)，我們可以透過慢 SQL 發現以及熔斷、慢呼叫隔離、熱點探測等手段保障穩定性。

大促是一個專案，準備大促的目的是為了將大促時將會面對的許許多多不確定風險轉變成相對確定的事情，只有系統的每一個環節都做好了充足的準備，我們面對大促時才能做到胸有成竹。