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

http://yzkb.51969.com/

文章目錄

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

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

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

負(fù)載均衡算法round-robinip_hashhash key

失敗重試健康檢查T(mén)CPHTTP

隔離線程隔離進(jìn)程隔離集群隔離機(jī)房隔離讀寫(xiě)隔離動(dòng)靜隔離熱點(diǎn)隔離

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

nginx限流ngx_http_limit_conn_modulengx_http_limit_req_module

Tomcat限流接口限流

降級(jí)降級(jí)預(yù)案頁(yè)面降級(jí)頁(yè)面片段降級(jí)頁(yè)面異步請(qǐng)求降級(jí)服務(wù)功能降級(jí)讀降級(jí)寫(xiě)降級(jí)自動(dòng)降級(jí)

熔斷

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

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

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

參考文獻(xiàn)

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

海恩法則

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

墨菲定律

任何事情都沒(méi)有表面看起來(lái)那么簡(jiǎn)單所有事情的發(fā)展都會(huì)比你預(yù)計(jì)的時(shí)間長(zhǎng)會(huì)出錯(cuò)的事總會(huì)出錯(cuò)如果你擔(dān)心某種情況發(fā)生，那么它更有可能發(fā)生

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

什么是高可用

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

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

故障的度量與考核

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

解決高可用問(wèn)題具體方案

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

集群化部署

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

負(fù)載均衡

負(fù)載均衡實(shí)現(xiàn)

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

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

外部服務(wù)

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

數(shù)據(jù)庫(kù)

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

負(fù)載均衡算法

round-robin

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

ip_hash

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

upstream backend{

ip_hash;

server 192.168.1.101:8080 weight=1;

server 192.168.1.102:8080 weight=2;

}

hash key

對(duì)某一個(gè)key進(jìn)行哈?；蛘呤褂靡恢滦怨Ｋ惴ㄟM(jìn)行負(fù)載均衡。

Hash算法存在的問(wèn)題是，若添加或者刪除一臺(tái)服務(wù)器的時(shí)候，會(huì)導(dǎo)致很多key被重新負(fù)載均衡到不同的服務(wù)器，而引起后端的問(wèn)題。

若是使用一致性哈希算法，當(dāng)添加/刪除一臺(tái)服務(wù)器時(shí)，只有少數(shù)key將被重新負(fù)載均衡到不同的服務(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次，則認(rèn)為上游服務(wù)器不可用|不存活，將摘掉上游服務(wù)器，fail_timeout秒之后會(huì)再次將服務(wù)器加入到存活列表進(jìn)行重試。

健康檢查

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

Nginx可以集成nginx_upstream_check_module模塊來(lái)進(jìn)行主動(dòng)健康檢查。支持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： 檢測(cè)間隔時(shí)間，此處配置了每隔3s檢測(cè)一次。fall： 檢測(cè)失敗多少次后，上游服務(wù)器被標(biāo)識(shí)為不存活。rise： 檢測(cè)成功多少次后，上游服務(wù)器被標(biāo)識(shí)為存活，并可以處理請(qǐng)求。

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

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

隔離

線程隔離

線程隔離指的是線程池隔離，一個(gè)請(qǐng)求出現(xiàn)問(wèn)題不會(huì)影響到其他線程池。

進(jìn)程隔離

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

集群隔離

將集群隔離開(kāi)，使互相不影響。

機(jī)房隔離

分不同的機(jī)房進(jìn)行部署，杭州機(jī)房；北京機(jī)房；上海機(jī)房，因?yàn)榭赡艹霈F(xiàn)某機(jī)房網(wǎng)絡(luò)問(wèn)題，這樣可以防止某機(jī)房出現(xiàn)網(wǎng)絡(luò)問(wèn)題導(dǎo)致整個(gè)系統(tǒng)無(wú)法使用。

讀寫(xiě)隔離

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

動(dòng)靜隔離

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

熱點(diǎn)隔離

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

限流

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

限流算法

漏桶算法

漏桶算法思路很簡(jiǎn)單，水（請(qǐng)求）先進(jìn)入到漏桶里，漏桶以一定的速度出水，當(dāng)水流入速度過(guò)大會(huì)直接溢出，可以看出漏桶算法能強(qiáng)行限制數(shù)據(jù)的傳輸速率。

令牌桶算法

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

nginx限流

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

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

ngx_http_limit_conn_module

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

可以按照IP來(lái)限制IP維度的總連接數(shù)，或者按照服務(wù)域名來(lái)限制某個(gè)域名的總連接數(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和計(jì)數(shù)器的共享內(nèi)存區(qū)域和指定key的最大連接數(shù)。此處指定的最大連接數(shù)是1，表示Nginx最多同時(shí)并發(fā)處理1個(gè)連接。 limit_conn_zone： 用來(lái)配置限流key及存放key對(duì)應(yīng)信息的共享內(nèi)存區(qū)域大小。此處的key是binaryremoteaddr”，表示IP地址，也可以使用binary_remote_addr”，表示IP地址，也可以使用binaryr?emotea?ddr”，表示IP地址，也可以使用server_name作為key來(lái)限制域名級(jí)別的最大連接數(shù)。 limit_conn_status： 配置被限流后返回的狀態(tài)碼，默認(rèn)返回503。 limit_conn_log_level： 配置記錄被限流后的日志級(jí)別，默認(rèn)error級(jí)別。

ngx_http_limit_req_module

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

limit_conn_log_level error;

limit_conn_status 503;

...

server{

location /limit{

limit_req zone=one burst=5 nodelay;

}

}

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

Tomcat限流

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

connectionTimeout="20000"

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

acceptCount：等待隊(duì)列，如果Tomcat的線程都忙于響應(yīng)，新來(lái)的連接會(huì)進(jìn)入隊(duì)列排隊(duì)，如果超出排隊(duì)大小，則拒絕連接；默認(rèn)值為100 maxConnections：可以創(chuàng)建的瞬時(shí)最大連接數(shù)，超出的會(huì)排隊(duì)等待； maxThreads：Tomcat能啟動(dòng)用來(lái)處理請(qǐng)求的最大線程數(shù)，即同時(shí)處理的任務(wù)個(gè)數(shù)，默認(rèn)值為200，如果請(qǐng)求處理量一直遠(yuǎn)遠(yuǎn)大于最大線程數(shù)，則會(huì)引起響應(yīng)變慢甚至?xí)┧馈?/p>

接口限流

接口的限流主要是針對(duì)些核心、QPS高的接口進(jìn)行限流，限制某個(gè)接口的請(qǐng)求頻率，以此來(lái)保護(hù)整個(gè)服務(wù)不被壓垮?？梢栽O(shè)置每個(gè)實(shí)例接口的QPS也可以設(shè)置所有實(shí)例總和的QPS。

降級(jí)

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

降級(jí)預(yù)案

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

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

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

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

頁(yè)面降級(jí)

在大型促銷(xiāo)或者搶購(gòu)活動(dòng)時(shí)，某些頁(yè)面占用了一些稀缺服務(wù)資源，在緊急情況下可以對(duì)其整個(gè)降級(jí)。

頁(yè)面片段降級(jí)

比如，商品詳情頁(yè)中的商家部分因?yàn)閿?shù)據(jù)錯(cuò)誤，此時(shí)，需要對(duì)其進(jìn)行降級(jí)。

頁(yè)面異步請(qǐng)求降級(jí)

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

服務(wù)功能降級(jí)

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

讀降級(jí)

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

寫(xiě)降級(jí)

比如，秒殺搶購(gòu)，我們可以只進(jìn)行Cache的更新，然后異步扣減庫(kù)存到DB，保證最終一致性即可，此時(shí)可以將DB降級(jí)為Cache。

自動(dòng)降級(jí)

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

熔斷

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

超時(shí)與重試

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

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

壓測(cè)與預(yù)案

系統(tǒng)壓測(cè)

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

線下壓測(cè)

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

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

線上壓測(cè)

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

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

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

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

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

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

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

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

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

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

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

監(jiān)控

首先這部分不屬于高可用系統(tǒng)架構(gòu)的部分，它應(yīng)該是監(jiān)控體系的一部分，而之所以放在這里主要還是因?yàn)檐浖纳芷谥芯S護(hù)的時(shí)間更長(zhǎng)，所以在系統(tǒng)前期的架構(gòu)設(shè)計(jì)中還是要考慮開(kāi)發(fā)、維護(hù)中的監(jiān)控。同時(shí)這里對(duì)于監(jiān)控不會(huì)介紹很多，只會(huì)基于監(jiān)控的三大數(shù)據(jù)進(jìn)行簡(jiǎn)單概括。

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

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

指標(biāo)

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

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

鏈路追蹤

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

日志

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

參考文獻(xiàn)

高可用設(shè)計(jì)原則

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

http://yzkb.51969.com/

相關(guān)文章