柚子快報激活碼778899分享：高可用系統(tǒng)架構(gòu)總結(jié)

http://yzkb.51969.com/

文章目錄

系統(tǒng)設(shè)計的一些原則海恩法則墨菲定律

軟件架構(gòu)中的高可用設(shè)計什么是高可用故障的度量與考核解決高可用問題具體方案

集群化部署負載均衡負載均衡實現(xiàn)內(nèi)部服務(wù)外部服務(wù)數(shù)據(jù)庫

負載均衡算法round-robinip_hashhash key

失敗重試健康檢查TCPHTTP

隔離線程隔離進程隔離集群隔離機房隔離讀寫隔離動靜隔離熱點隔離

限流限流算法漏桶算法令牌桶算法

nginx限流ngx_http_limit_conn_modulengx_http_limit_req_module

Tomcat限流接口限流

降級降級預(yù)案頁面降級頁面片段降級頁面異步請求降級服務(wù)功能降級讀降級寫降級自動降級

熔斷

超時與重試壓測與預(yù)案系統(tǒng)壓測線下壓測線上壓測

系統(tǒng)優(yōu)化應(yīng)急預(yù)案

監(jiān)控指標鏈路追蹤日志

參考文獻

系統(tǒng)設(shè)計的一些原則

海恩法則

事故的發(fā)生是量積累的結(jié)果再好的技術(shù)、在完美的規(guī)章，在實際操作層面也無法取代人自身的素質(zhì)和責任心

墨菲定律

任何事情都沒有表面看起來那么簡單所有事情的發(fā)展都會比你預(yù)計的時間長會出錯的事總會出錯如果你擔心某種情況發(fā)生，那么它更有可能發(fā)生

軟件架構(gòu)中的高可用設(shè)計

什么是高可用

首先我們來了解下如何來定義一個系統(tǒng)可用，業(yè)界常用N個9來定義一個系統(tǒng)的可用情況。比如可用性為99.99%，這個99.99%就是代表的該系統(tǒng)在一年內(nèi)可用的時間為99.99%。那么可用性為99.99%的系統(tǒng)不可用時間呢？一年有365天，一天有24小時，一小時有60分鐘，一分鐘有60秒，那么可用性為99.99%的系統(tǒng)一年內(nèi)不可用時間大致為52.56分鐘(3652460*(1-0.9999))。

高可用就是可用性指標大于等于4個9的系統(tǒng)。

故障的度量與考核

該評定標準一般會有SRE和各個業(yè)務(wù)方的技術(shù)負責人一起協(xié)商輸出統(tǒng)一標準。對于出現(xiàn)各個等級的故障后都會進行總結(jié)，作為年底的技術(shù)輸出。

解決高可用問題具體方案

集群化部署負載均衡熔斷限流降級隔離超時與重試回滾壓測與預(yù)案

集群化部署

由于單點部署的話一旦服務(wù)掛了就直接不可用，所以需要采用集群部署，避免單點故障。

負載均衡

負載均衡實現(xiàn)

內(nèi)部服務(wù)

保證服務(wù)集群可以進行故障轉(zhuǎn)移。當服務(wù)宕機后，負載均衡進行轉(zhuǎn)移，來達到高可用。對于內(nèi)部調(diào)用的服務(wù)，通過RPC提供負載均衡。

外部服務(wù)

對于調(diào)用的外部服務(wù)，需要外部服務(wù)保障自身的高可用部署。同時調(diào)用方需要做重試(對于請求的節(jié)點不可用時切換其他節(jié)點)以及對第三方服務(wù)進行不可用、異常的監(jiān)控。

數(shù)據(jù)庫

對于服務(wù)內(nèi)的數(shù)據(jù)庫需保障高可用部署，以及采用的高可用方案的不適配問題，例如某些高可用方案在進行故障轉(zhuǎn)移時會出現(xiàn)短暫不可用，這種情況也需要考慮進去。最后需要對數(shù)據(jù)庫進行監(jiān)控(異常、慢請求、CPU、磁盤、內(nèi)存、線程池、IO)

負載均衡算法

round-robin

輪詢，默認的負載均衡算法，以輪詢的方式將請求轉(zhuǎn)發(fā)到上游服務(wù)器，配合weight配置可以實現(xiàn)基于權(quán)重的輪詢

ip_hash

根據(jù)客戶IP進行負載均衡，享同的IP將負載均衡到同一個upstream server

upstream backend{

ip_hash;

server 192.168.1.101:8080 weight=1;

server 192.168.1.102:8080 weight=2;

}

hash key

對某一個key進行哈?；蛘呤褂靡恢滦怨Ｋ惴ㄟM行負載均衡。

Hash算法存在的問題是，若添加或者刪除一臺服務(wù)器的時候，會導致很多key被重新負載均衡到不同的服務(wù)器，而引起后端的問題。

若是使用一致性哈希算法，當添加/刪除一臺服務(wù)器時，只有少數(shù)key將被重新負載均衡到不同的服務(wù)器。

失敗重試

upstream backend{

server 192.168.1.101:8080 max_fails=2 fail_timeout=10s weight=1;

server 192.168.1.102:8080 max_fails=2 fail_timeout=10s weight=2;

}

若是fail_timeout秒內(nèi)失敗了max_fails次，則認為上游服務(wù)器不可用|不存活，將摘掉上游服務(wù)器，fail_timeout秒之后會再次將服務(wù)器加入到存活列表進行重試。

健康檢查

時刻關(guān)注服務(wù)的健康狀態(tài)，若是服務(wù)不可用了，將會把請求轉(zhuǎn)發(fā)到其他存活的服務(wù)上，以提高可用性。

Nginx可以集成nginx_upstream_check_module模塊來進行主動健康檢查。支持TCP心跳和HTTP心跳。

TCP

upstream backend{

server 192.168.1.101:8080 weight=1;

server 192.168.1.102:8080 weight=2;

check interval=3000 rise=1 fall=3 timeout=2000 type=tcp;

}

interval： 檢測間隔時間，此處配置了每隔3s檢測一次。fall： 檢測失敗多少次后，上游服務(wù)器被標識為不存活。rise： 檢測成功多少次后，上游服務(wù)器被標識為存活，并可以處理請求。

HTTP

upstream backend{

server 192.168.1.101:8080 weight=1;

server 192.168.1.102:8080 weight=2;

check interval=3000 rise=1 fall=3 timeout=2000 type=tcp;

check_http_send ”HEAD /status HTTP/1.0\r\n\r\n“

check_http_expect_alive http_2xx http_3xx;

}

check_http_send： 即檢查時發(fā)的HTTP請求內(nèi)容。check_http_expect_alive： 當上游服務(wù)器返回匹配的響應(yīng)狀態(tài)碼時，則認為上游服務(wù)器存活。 請勿將檢查時間設(shè)置過短，以防心跳檢查包過多影響上游服

所以我們可以看到某些廠在自己的容器平臺上會有 【健康檢查】的功能就是根據(jù)nginx來做的改造。需要用戶配置健康檢查的path、頻率、首次探測等待時間、每次探測超時時間、端口、探測失敗閾值。

隔離

線程隔離

線程隔離指的是線程池隔離，一個請求出現(xiàn)問題不會影響到其他線程池。

進程隔離

把項目拆分成一個一個的子項目，互相物理隔離(部署在不同的機器上)。

集群隔離

將集群隔離開，使互相不影響。

機房隔離

分不同的機房進行部署，杭州機房；北京機房；上海機房，因為可能出現(xiàn)某機房網(wǎng)絡(luò)問題，這樣可以防止某機房出現(xiàn)網(wǎng)絡(luò)問題導致整個系統(tǒng)無法使用。

讀寫隔離

互聯(lián)網(wǎng)項目中大多是讀多寫少，讀寫分離，擴展讀的能力，提高性能，提高可用性。常見的mysql讀寫分離就是這個原理。 但是在使用讀寫分離時還要考慮數(shù)據(jù)的延遲問題，事務(wù)失效問題。

動靜隔離

將靜態(tài)資源放入nginx,CDN，從而達到動靜隔離，防止頁面加載大量靜態(tài)資源。

熱點隔離

將熱點業(yè)務(wù)獨立成系統(tǒng)或服務(wù)進行隔離，如秒殺，搶購。 讀熱點一般使用多級緩存。同時需要考慮緩存與數(shù)據(jù)庫一致性問題。 寫熱點一般使用緩存加消息隊列的方式。同時需要考慮數(shù)據(jù)延時問題是否會對業(yè)務(wù)有影響。

限流

限流主要是針對有突發(fā)流量的場景，如秒殺、搶購。若是不做限流，當突發(fā)大流量，服務(wù)可能會被沖垮。

限流算法

漏桶算法

漏桶算法思路很簡單，水（請求）先進入到漏桶里，漏桶以一定的速度出水，當水流入速度過大會直接溢出，可以看出漏桶算法能強行限制數(shù)據(jù)的傳輸速率。

令牌桶算法

令牌桶算法的原理是系統(tǒng)會以一個恒定的速度往桶里放入令牌，而如果請求需要被處理，則需要先從桶里獲取一個令牌，當桶里沒有令牌可取時，則拒絕服務(wù)。

nginx限流

Nginx接入層限流可以使用Nginx自帶的兩個模塊：

連接數(shù)限流模塊ngx_http_limit_conn_module 漏桶算法實現(xiàn)的請求限流模塊ngx_http_limit_req_module

ngx_http_limit_conn_module

針對某個key對應(yīng)的總的網(wǎng)絡(luò)連接數(shù)進行限流

可以按照IP來限制IP維度的總連接數(shù)，或者按照服務(wù)域名來限制某個域名的總連接數(shù)。

http{

limit_conn_zone $binary_remote_addr zone=addr:10m;

limit_conn_log_level error;

limit_conn_status 503;

...

server{

location /limit{

limit_conn addr 1;

}

}

...

}

limit_conn： 要配置存放key和計數(shù)器的共享內(nèi)存區(qū)域和指定key的最大連接數(shù)。此處指定的最大連接數(shù)是1，表示Nginx最多同時并發(fā)處理1個連接。 limit_conn_zone： 用來配置限流key及存放key對應(yīng)信息的共享內(nèi)存區(qū)域大小。此處的key是binaryremoteaddr”，表示IP地址，也可以使用binary_remote_addr”，表示IP地址，也可以使用binaryr?emotea?ddr”，表示IP地址，也可以使用server_name作為key來限制域名級別的最大連接數(shù)。 limit_conn_status： 配置被限流后返回的狀態(tài)碼，默認返回503。 limit_conn_log_level： 配置記錄被限流后的日志級別，默認error級別。

ngx_http_limit_req_module

漏桶算法實現(xiàn)，用于對指定key對應(yīng)的請求進行限流，比如，按照IP維度限制請求速率。配置示例如下

limit_conn_log_level error;

limit_conn_status 503;

...

server{

location /limit{

limit_req zone=one burst=5 nodelay;

}

}

limit_req： 配置限流區(qū)域、桶容量（突發(fā)容量，默認為0）、是否延遲模式（默認延遲）。 limit_req_zone： 配置限流key、存放key對應(yīng)信息的共享內(nèi)存區(qū)域大小、固定請求速率。此處指定的key是“$binary_remote_addr”，表示IP地址。固定請求速率使用rate參數(shù)配置，支持10r/s和60r/m，即每秒10個請求和每分鐘60個請求。不過，最終都會轉(zhuǎn)換為每秒的固定請求速率（10r/s為每100毫秒處理一個請求，60r/m為每1000毫秒處理一個請求）。 limit_conn_status： 配置被限流后返回的狀態(tài)碼，默認返回503。 limit_conn_log_level： 配置記錄被限流后的日志級別，默認級別為error。

Tomcat限流

對于一個應(yīng)用系統(tǒng)來說，一定會有極限并發(fā)/請求數(shù)，即總有一個TPS/QPS閾值，如果超了閾值，則系統(tǒng)就會不響應(yīng)用戶請求或響應(yīng)得非常慢，因此我們最好進行過載保護，以防止大量請求涌入擊垮系統(tǒng)。對于這些參數(shù)的配置需要經(jīng)過壓力測試后才能得出一個較好的數(shù)據(jù)，并且每次有重大功能上線時還需要再次壓測看是否需要調(diào)整參數(shù)。這不是一件簡單的事情。

connectionTimeout="20000"

redirectPort="8443" maxThreads="800" maxConnections="2000" acceptCount="1000"/>

acceptCount：等待隊列，如果Tomcat的線程都忙于響應(yīng)，新來的連接會進入隊列排隊，如果超出排隊大小，則拒絕連接；默認值為100 maxConnections：可以創(chuàng)建的瞬時最大連接數(shù)，超出的會排隊等待； maxThreads：Tomcat能啟動用來處理請求的最大線程數(shù)，即同時處理的任務(wù)個數(shù)，默認值為200，如果請求處理量一直遠遠大于最大線程數(shù)，則會引起響應(yīng)變慢甚至會僵死。

接口限流

接口的限流主要是針對些核心、QPS高的接口進行限流，限制某個接口的請求頻率，以此來保護整個服務(wù)不被壓垮。可以設(shè)置每個實例接口的QPS也可以設(shè)置所有實例總和的QPS。

降級

當訪問量劇增、服務(wù)出現(xiàn)問題（如響應(yīng)時間長或不響應(yīng)）或非核心服務(wù)影響到核心流程的性能時，仍然需要保證服務(wù)還是可用的，即使是有損服務(wù)。系統(tǒng)可以根據(jù)一些關(guān)鍵數(shù)據(jù)進行自動降級，也可以配置開關(guān)實現(xiàn)人工降級。降級的最終目的是保證核心服務(wù)可用，即使是有損的。

降級預(yù)案

在降級前需要對系統(tǒng)進行梳理，判斷系統(tǒng)是否可以丟卒保帥，從而整理出哪些可以降級，哪些不能降級。

一般： 比如，有些服務(wù)偶爾因為網(wǎng)絡(luò)抖動或者服務(wù)正在上線而超時，可以自動降級。 警告： 有些服務(wù)在一段時間內(nèi)成功率有波動（如在95~100%之間），可以自動降級或人工降級，并發(fā)送告警。 錯誤： 比如，可用率低于90%，或者數(shù)據(jù)庫連接池用完了，或者訪問量突然猛增到系統(tǒng)能承受的最大閾值，此時，可以根據(jù)情況自動降級或者人工降級。 嚴重錯誤： 比如，因為特殊原因數(shù)據(jù)出現(xiàn)錯誤，此時，需要緊急人工降級。

降級按照是否自動化可分為：自動開關(guān)降級和人工開關(guān)降級。 降級按照功能可分為：讀服務(wù)降級和寫服務(wù)降級。 降級按照處于的系統(tǒng)層次可分為：多級降級。

降級的功能點主要從服務(wù)器端鏈路考慮，即根據(jù)用戶訪問的服務(wù)調(diào)用鏈路來梳理哪里需要降級。

頁面降級

在大型促銷或者搶購活動時，某些頁面占用了一些稀缺服務(wù)資源，在緊急情況下可以對其整個降級。

頁面片段降級

比如，商品詳情頁中的商家部分因為數(shù)據(jù)錯誤，此時，需要對其進行降級。

頁面異步請求降級

比如，商品詳情頁上有推薦信息/配送至等異步加載的請求，如果這些信息響應(yīng)慢或者后端服務(wù)有問題，則可以進行降級。

服務(wù)功能降級

比如，渲染商品詳情頁時，需要調(diào)用一些不太重要的服務(wù)（相關(guān)分類、熱銷榜等），而這些服務(wù)在異常情況下直接不獲取，即降級即可。

讀降級

比如，多級緩存模式，如果后端服務(wù)有問題，則可以降級為只讀緩存，這種方式適用于對讀一致性要求不高的場景。

寫降級

比如，秒殺搶購，我們可以只進行Cache的更新，然后異步扣減庫存到DB，保證最終一致性即可，此時可以將DB降級為Cache。

自動降級

當服務(wù)中錯誤出現(xiàn)次數(shù)到達閥值（99.99%）,對服務(wù)進行降級，發(fā)出警告。

熔斷

熔斷機制也是很重要的。 熔斷機制說的是系統(tǒng)自動收集所依賴服務(wù)的資源使用情況和性能指標，當所依賴的服務(wù)不可用或者調(diào)用失敗次數(shù)達到某個閾值的時候就迅速失敗，讓當前系統(tǒng)立即切換依賴其他備用服務(wù)。 比較常用的是流量控制和熔斷降級框架是 Netflix 的 Hystrix 和 alibaba 的 Sentinel。

超時與重試

一旦用戶請求超過某個時間的得不到響應(yīng)，就拋出異常。這個是非常重要的，很多線上系統(tǒng)故障都是因為沒有進行超時設(shè)置或者超時設(shè)置的方式不對導致的。我們在讀取第三方服務(wù)的時候，尤其適合設(shè)置超時和重試機制。如果不進行超時設(shè)置可能會導致請求響應(yīng)速度慢，甚至導致請求堆積進而讓系統(tǒng)無法在處理請求。重試的次數(shù)一般設(shè)為 3 次，再多次的重試沒有好處，反而會加重服務(wù)器壓力（部分場景使用失敗重試機制會不太適合，因為可能產(chǎn)生重復(fù)請求，而服務(wù)端又沒做冪等處理就會產(chǎn)生臟數(shù)據(jù)）。常見的重試如下：

代理層超時與重試： nginx web容器超時與重試 中間件|服務(wù)間超時與重試 數(shù)據(jù)庫連接超時與重試 nosql超時與重試 業(yè)務(wù)超時與重試 前端瀏覽器ajax請求超時與重試

壓測與預(yù)案

系統(tǒng)壓測

壓測一般指性能壓力測試，用來評估系統(tǒng)的穩(wěn)定性和性能，通過壓測數(shù)據(jù)進行系統(tǒng)容量評估，從而決定是否需要進行擴容或縮容。

線下壓測

通過如JMeter、Apache ab壓測系統(tǒng)的某個接口（如查詢庫存接口）或者某個組件（如數(shù)據(jù)庫連接池），然后進行調(diào)優(yōu)（如調(diào)整JVM參數(shù)、優(yōu)化代碼），實現(xiàn)單個接口或組件的性能最優(yōu)。

線下壓測的環(huán)境（比如，服務(wù)器、網(wǎng)絡(luò)、數(shù)據(jù)量等）和線上的完全不一樣，仿真度不高，很難進行全鏈路壓測，適合組件級的壓測，數(shù)據(jù)只能作為參考。

線上壓測

線上壓測的方式非常多，按讀寫分為讀壓測、寫壓測和混合壓測，按數(shù)據(jù)仿真度分為仿真壓測和引流壓測，按是否給用戶提供服務(wù)分為隔離集群壓測和線上集群壓測。

讀壓測是壓測系統(tǒng)的讀流量，比如，壓測商品價格服務(wù)。寫壓測是壓測系統(tǒng)的寫流量，比如下單。寫壓測時，要注意把壓測寫的數(shù)據(jù)和真實數(shù)據(jù)分離，在壓測完成后，刪除壓測數(shù)據(jù)。只進行讀或?qū)憠簻y有時是不能發(fā)現(xiàn)系統(tǒng)瓶頸的，因為有時讀和寫是會相互影響的，因此，這種情況下要進行混合壓測。

仿真壓測是通過模擬請求進行系統(tǒng)壓測，模擬請求的數(shù)據(jù)可以是使用程序構(gòu)造、人工構(gòu)造（如提前準備一些用戶和商品），或者使用Nginx訪問日志，如果壓測的數(shù)據(jù)量有限，則會形成請求熱點。而更好的方式可以考慮引流壓測，比如使用TCPCopy復(fù)制；也可以考慮使用流量拷貝來拷貝線上流量，然后測試環(huán)境構(gòu)造出和線上一樣的環(huán)境(硬件、數(shù)據(jù)、示例等)，最后將拷貝的流量來對測試環(huán)境進行壓測，這是個很復(fù)雜的事，需要單獨的壓測平臺來支持。

系統(tǒng)優(yōu)化

拿到壓測報告后，接下來會分析報告，然后進行一些有針對性的優(yōu)化，如硬件升級、系統(tǒng)擴容、參數(shù)調(diào)優(yōu)、代碼優(yōu)化（如代碼同步改異步）、架構(gòu)優(yōu)化（如加緩存、讀寫分離、歷史數(shù)據(jù)歸檔）等。

不要直接復(fù)用別人的案列，一定要根據(jù)壓測結(jié)果合理調(diào)整自己的案例。

在進行系統(tǒng)優(yōu)化時，要進行代碼走查，發(fā)現(xiàn)不合理的參數(shù)配置，如超時時間、降級策略、緩存時間等。在系統(tǒng)壓測中進行慢查詢排查，包括Redis、MySQL等，通過優(yōu)化查詢解決慢查詢問題。

在應(yīng)用系統(tǒng)擴容方面，可以根據(jù)去年流量、與運營業(yè)務(wù)方溝通促銷力度、最近一段時間的流量來評估出是否需要進行擴容，需要擴容多少倍，比如，預(yù)計GMV增長100%，那么可以考慮擴容2~3倍容量。

應(yīng)急預(yù)案

在系統(tǒng)壓測之后會發(fā)現(xiàn)一些系統(tǒng)瓶頸，在系統(tǒng)優(yōu)化之后會提升系統(tǒng)吞吐量并降低響應(yīng)時間，容災(zāi)之后的系統(tǒng)可用性得以保障，但還是會存在一些風險，如網(wǎng)絡(luò)抖動、某臺機器負載過高、某個服務(wù)變慢、數(shù)據(jù)庫Load值過高等，為了防止因為這些問題而出現(xiàn)系統(tǒng)雪崩，需要針對這些情況制定應(yīng)急預(yù)案，從而在出現(xiàn)突發(fā)情況時，有相應(yīng)的措施來解決掉這些問題。

應(yīng)急預(yù)案可按照如下幾步進行：首先進行系統(tǒng)分級，然后進行全鏈路分析、配置監(jiān)控報警，最后制定應(yīng)急預(yù)案。

監(jiān)控

首先這部分不屬于高可用系統(tǒng)架構(gòu)的部分，它應(yīng)該是監(jiān)控體系的一部分，而之所以放在這里主要還是因為軟件的生命周期中維護的時間更長，所以在系統(tǒng)前期的架構(gòu)設(shè)計中還是要考慮開發(fā)、維護中的監(jiān)控。同時這里對于監(jiān)控不會介紹很多，只會基于監(jiān)控的三大數(shù)據(jù)進行簡單概括。

從上面的步驟我們知道如果沒有監(jiān)控，那么系統(tǒng)維護人員面對系統(tǒng)就像個瞎子一樣，不知道系統(tǒng)的情況。即使前期做了再完備的設(shè)計、開發(fā)人員的技術(shù)水平多高，但是在軟件的維護過程中依然會存在問題 。所以詳細、全面、合理的監(jiān)控是必不可少的。它可以幫助維護人員知道異常的出現(xiàn)，可以幫助維護人員知道系統(tǒng)的變化。一個全面、完善的監(jiān)控體系是業(yè)務(wù)保障的關(guān)鍵。

沒有什么系統(tǒng)的一步到位的，所以更加需要有監(jiān)控來幫助系統(tǒng)完善自身的問題。

指標

我們需要對系統(tǒng)的業(yè)務(wù)、性能進行指標暴露、采集、監(jiān)控。我們可以根據(jù)指標變化分析出系統(tǒng)某個東西的變化情況，同時可以根據(jù)指標值發(fā)出告警。

指標大體可以分為容器(tomcat)、中間件、數(shù)據(jù)庫、http、池(數(shù)據(jù)庫連接池、http連接池)等，每項指標又可以有QPS、響應(yīng)時間、異常率、慢請求率等。這些都是些基礎(chǔ)的指標數(shù)據(jù)，在系統(tǒng)的不斷維護、迭代中會增加更多的指標數(shù)據(jù)以及報表展示。這是一個不斷優(yōu)化的過程。

鏈路追蹤

鏈路追蹤主要用來分析一個執(zhí)行過程的耗時以及具體性能問題出現(xiàn)在哪個地方。同時鏈路ID(這塊需要鏈路追蹤系統(tǒng)進行改造兼容)也可以作為串聯(lián)日志的中間層來把日志和鏈路進行串聯(lián)。由于鏈路的數(shù)據(jù)非常的完整，所以鏈路數(shù)據(jù)是非常有價值的數(shù)據(jù)，可以進行鏈路分析來幫助業(yè)務(wù)更加輕松的維護系統(tǒng)。

日志

日志作為開發(fā)人員常用的排查問題數(shù)據(jù)存在一個非常難受的點就是無法將一個執(zhí)行的全部日志一次性查出來，所以可以在日志中添加traceId來把日志數(shù)據(jù)進行串聯(lián)。好的、完善的日志是排查問題的關(guān)鍵。所以日志的重構(gòu)存在于軟件維護的整個過程。日志的級別設(shè)置非常關(guān)鍵，因為我們經(jīng)常會對日志進行分析，將error級別的日志進行告警通知相應(yīng)服務(wù)的維護人員。

參考文獻

高可用設(shè)計原則

柚子快報激活碼778899分享：高可用系統(tǒng)架構(gòu)總結(jié)

http://yzkb.51969.com/

相關(guān)文章