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

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

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

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

服務(wù)化后，服務(wù)變多，調(diào)用鏈路變長，如果一個(gè)調(diào)用鏈上某個(gè)服務(wù)節(jié)點(diǎn)出問題，很可能引發(fā)整個(gè)調(diào)用鏈路崩潰，也就是所謂的雪崩效應(yīng)。

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

為了避免雪崩效應(yīng)，我們可以從兩個(gè)方面考慮：

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

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

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

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

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

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

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

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

服務(wù)降級

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

緩存要注意什么？

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

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

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

關(guān)于隔離的考慮

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

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

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

   

慢查詢和大結(jié)果集問題

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

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

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

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

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

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

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

CI測試&性能測試

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

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

監(jiān)控

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

CDN

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

避免單點(diǎn)問題

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

網(wǎng)絡(luò)帶寬

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

安全

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

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

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

OK，就分享到這。