億級用戶基于微服務的互聯(lián)網(wǎng)系統(tǒng)穩(wěn)定性～

互聯(lián)網(wǎng)系統(tǒng)為大量的C端用戶提供服務，如果隔三差五的出問題宕機，會嚴重影響用戶體驗，甚至導致用戶流失。所以穩(wěn)定性對互聯(lián)網(wǎng)系統(tǒng)非常重要！接下來，我根據(jù)自己的實際經(jīng)驗來聊聊基于微服務的互聯(lián)網(wǎng)系統(tǒng)的穩(wěn)定性。

下面我們從雪崩、隔離、服務降級、突發(fā)流量、緩存、數(shù)據(jù)冗余、熔斷、限流、CDN、數(shù)據(jù)庫、CI、網(wǎng)絡等方面，聊聊如何保證基于微服務的系統(tǒng)穩(wěn)定性。

雪崩效應產(chǎn)生原因，如何避免？

服務化后，服務變多，調用鏈路變長，如果一個調用鏈上某個服務節(jié)點出問題，很可能引發(fā)整個調用鏈路崩潰，也就是所謂的雪崩效應。

舉個例子，詳細理解一下雪崩。如上圖，現(xiàn)在有A，B，C三個服務，A調B，B調C。假如C發(fā)生故障，B方法1調用C方法1的請求不能及時返回，B的線程會發(fā)生阻塞等待。B會在一定時間后因為線程阻塞耗盡線程池所有線程，這時B就會無法響應A的請求。A調用B的請求不能及時返回，A的線程池線程資源也會逐漸被耗盡，最終A也無法對外提供服務。這樣就引發(fā)了連鎖故障，發(fā)生了雪崩?？v向：C故障引發(fā)B故障，B故障引發(fā)A故障，最終發(fā)生連鎖故障。橫向：方法1出問題，導致線程阻塞，進而線程池線程資源耗盡，最終服務內所有方法都無法訪問，這就是“線程池污染”

為了避免雪崩效應，我們可以從兩個方面考慮：

• 在服務間加熔斷。解決服務間縱向連鎖故障問題。比如在A服務加熔斷，當B故障時，開啟熔斷，A調用B的請求不再發(fā)送到B，直接快速返回。這樣就避免了線程等待的問題。當然快速返回什么，fallback方案是什么，也需要根據(jù)具體場景，比如返回默認值或者調用其他備用服務接口。如果你的場景適合異步通信，可以采用消息隊列，這樣也可以有效避免同步調用的線程等待問題。

• 服務內（JVM內）線程隔離。解決橫向線程池污染的問題。為了避免因為一個方法出問題導致線程等待最終引發(fā)線程資源耗盡的問題，我們可以對tomcat，dubbo等的線程池分成多個小線程組，每個線程組服務于不同的類或方法。一個方法出問題，只影響自己不影響其他方法和類。

常用開源熔斷隔離組件：Hystrix，Resilience4j

如何應對突發(fā)流量對服務的巨大壓力？

促銷活動或秒殺時，訪問量往往會猛增數(shù)倍。技術團隊在活動開始前一般都會根據(jù)預估訪問量適當增加節(jié)點，但是假如流量預估少了（實際訪問量遠大于預估的訪問量），系統(tǒng)就可能會被壓垮。所以我們可以在網(wǎng)關層（Zuul，Gateway，Nginx等）做限流，如果訪問量超出系統(tǒng)承載能力，就按照一定策略拋棄超出閾值的訪問請求（也要注意用戶體驗，可以給用戶返回一個友好的頁面提示）。

可以從全局，IP，userID等多維度做限流。限流的兩個主要目的：1，應對突發(fā)流量，避免系統(tǒng)被壓垮（全局限流和IP限流）2，防刷，防止機器人腳本等頻繁調用服務（userID限流和IP限流）

數(shù)據(jù)冗余

在核心鏈路上，服務可以冗余它依賴的服務的數(shù)據(jù)，依賴的服務故障時，服務盡量做到自保。比如訂單服務依賴庫存服務。我們可以在訂單服務冗余庫存數(shù)據(jù)（注意控制合理的安全庫存，防超賣）。下單減庫存時，如果庫存服務掛了，我們可以直接從訂單服務取庫存?？梢越Y合熔斷一起使用，作為熔斷的Fallback（后備）方案。

服務降級

可能很多人都聽過服務降級，但是又不知道降級是怎么回事。實際上，上面說的熔斷，限流，數(shù)據(jù)冗余，都屬于服務降級的范疇。還有手動降級的例子，比如大促期間我們會關掉第三方物流接口，頁面上也關掉物流查詢功能，避免拖垮自己的服務。這種降級的例子很多。不管什么降級方式，目的都是讓系統(tǒng)可用性更高，容錯能力更強，更穩(wěn)定。

緩存要注意什么？

1. 緩存穿透。對于數(shù)據(jù)庫中根本不存在的值，請求緩存時要在緩存記錄一個空值，避免每次請求都打到數(shù)據(jù)庫

2. 緩存雪崩。在某一時間緩存數(shù)據(jù)集中失效，導致大量請求穿透到數(shù)據(jù)庫，將數(shù)據(jù)庫壓垮。可以在初始化數(shù)據(jù)時，差異化各個key的緩存失效時間，失效時間 = 一個較大的固定值 + 較小的隨機值

3. 緩存熱點。有些熱點數(shù)據(jù)訪問量會特別大，單個緩存節(jié)點（例如Redis）無法支撐這么大的訪問量。如果是讀請求訪問量大，可以考慮讀寫分離，一主多從的方案，用從節(jié)點分攤讀流量；如果是寫請求訪問量大，可以采用集群分片方案，用分片分攤寫流量。以秒殺扣減庫存為例，假如秒殺庫存是100，可以分成5片，每片存20個庫存。

關于隔離的考慮

1. 部署隔離：我們經(jīng)常會遇到秒殺業(yè)務和日常業(yè)務依賴同一個服務，以及C端服務和內部運營系統(tǒng)依賴同一個服務的情況，比如說都依賴訂單服務。而秒殺系統(tǒng)的瞬間訪問量很高，可能會對服務帶來巨大的壓力，甚至壓垮服務。內部運營系統(tǒng)也經(jīng)常有批量數(shù)據(jù)導出的操作，同樣會給服務帶來一定的壓力。這些都是不穩(wěn)定因素。所以我們可以將這些共同依賴的服務分組部署，不同的分組服務于不同的業(yè)務，避免相互干擾。

2. 數(shù)據(jù)隔離：極端情況下還需要緩存隔離，數(shù)據(jù)庫隔離。以秒殺為例，庫存和訂單的緩存（Redis）和數(shù)據(jù)庫需要單獨部署！數(shù)據(jù)隔離后，秒殺訂單和日常訂單不在相同的數(shù)據(jù)庫，之后的訂單查詢怎么展示？可以采用相應的數(shù)據(jù)同步策略。比如，在創(chuàng)建秒殺訂單后發(fā)消息到消息隊列，日常訂單服務收到消息后將訂單寫入日常訂單庫。注意，要考慮數(shù)據(jù)的一致性，可以使用事務型消息。

3. 業(yè)務隔離：還是以秒殺為例。從業(yè)務上把秒殺和日常的售賣區(qū)分開來，把秒殺做為營銷活動，要參與秒殺的商品需要提前報名參加活動，這樣我們就能提前知道哪些商家哪些商品要參與秒殺，可以根據(jù)提報的商品提前生成商品詳情靜態(tài)頁面并上傳到CDN預熱，提報的商品庫存也需要提前預熱，可以將商品庫存在活動開始前預熱到Redis，避免秒殺開始后大量訪問穿透到數(shù)據(jù)庫。

   

慢查詢和大結果集問題

數(shù)據(jù)庫層面主要考慮慢查詢和大結果集問題：

1. 慢查詢是系統(tǒng)故障的罪魁禍首，如何避免慢查詢，也是我們必須思考的問題。我們的做法是所有新加和修改的sql語句都要經(jīng)過DBA審核，并且做好線上慢查詢監(jiān)控。

2. 大結果集問題。如果用mybatis，某些字段傳了空值或者忘傳了，if 判斷為假，就漏掉了相關條件，很有可能導致大結果集產(chǎn)生。為了避免大結果集，我們除了做好必傳參數(shù)校驗，還可以加一個攔截器，來限制所有結果集的條數(shù)，比如一個SQL最多查100條。

系統(tǒng)問題快速定位！

服務化后，一次請求會跨多個服務，追蹤問題也會變麻煩。這時就需要能夠追蹤整個調用鏈路的工具，協(xié)助我們排查問題。常見的開源全鏈路監(jiān)控工具有（pinpoint，skywaking，cat等），以Pinpoint為例簡單介紹一下：

Pinpoint基于JAVA，利用字節(jié)碼增強技術，對服務零侵入，以traceID串聯(lián)各個服務，已Plugin的方式支持不同API和中間件的監(jiān)控，靈活方便。

上圖是一個請求的調用棧，我們可以清晰看到一次請求調用了哪些服務和方法以及各個環(huán)節(jié)的耗時，以及發(fā)生在哪個節(jié)點。如果發(fā)生錯誤，會顯示為紅色，錯誤原因也會直接顯示出來。這樣通過APM系統(tǒng)我們就能輕松定位線上性能問題和錯誤了！

CI測試&性能測試

CI測試，持續(xù)集成測試，在我們每次提交代碼到發(fā)布分支前自動構建項目并執(zhí)行所有測試用例，如果有測試用例執(zhí)行失敗，拒絕將代碼合并到發(fā)布分支，本次集成失敗。CI測試可以保證上線質量，適用于用例不會經(jīng)常變化的穩(wěn)定業(yè)務。

性能測試，為了保證上線性能，所有用戶側功能需要進行性能測試。上線前要保證性能測試通過。而且要定期做全鏈路壓測，有性能問題可以及時發(fā)現(xiàn)。

監(jiān)控

我們需要一套完善的監(jiān)控系統(tǒng)，系統(tǒng)出問題時能夠快速告警，最好是系統(tǒng)出問題前能提前預警。包括系統(tǒng)監(jiān)控（CPU，內存，網(wǎng)絡IO，帶寬等監(jiān)控），數(shù)據(jù)庫監(jiān)控（QPS，TPS，慢查詢，大結果集等監(jiān)控），緩存中間件監(jiān)控（如Redis），JVM監(jiān)控（堆內存，GC，線程等監(jiān)控），全鏈路監(jiān)控（pinpoint，skywaking，cat等），各種接口監(jiān)控（QPS，TPS等）

CDN

可以充分利用CDN。除了提高用戶訪問速度之外，頁面靜態(tài)化之后存放到CDN，用CDN扛流量，可以大幅減少系統(tǒng)（源站）的訪問壓力。同時也減少了網(wǎng)站帶寬壓力。對系統(tǒng)穩(wěn)定性非常有好處。

避免單點問題

除了服務要多點部署外，網(wǎng)關，數(shù)據(jù)庫，緩存也要避免單點問題，至少要有一個Backup，而且要可以自動發(fā)現(xiàn)上線節(jié)點和自動摘除下線和故障節(jié)點。

網(wǎng)絡帶寬

避免帶寬成為瓶頸，促銷和秒殺開始前提前申請帶寬。不光要考慮外網(wǎng)帶寬，還要考慮內網(wǎng)帶寬，有些舊服務器網(wǎng)口是千兆網(wǎng)口，訪問量高時很可能會打滿。

安全

1. 可以在網(wǎng)關層上面再加一層防火墻或者高防服務，來防御DDos，CC等分布式網(wǎng)絡攻擊。

2. 機器人腳本防刷，前面已經(jīng)提到過，可以在網(wǎng)關層對下單等接口按userID限流。

此外，一套完善的灰度發(fā)布系統(tǒng)，可以讓上線更加平滑，避免上線大面積故障。DevOps工具，CI，CD對系統(tǒng)穩(wěn)定性也有很大意義。

OK，就分享到這。