本文主要帶大家了解服務(wù)穩(wěn)定性的重要性和相關(guān)策略。策略大概分兩部分，第一方面從架構(gòu)層面介紹保障服務(wù)穩(wěn)定性的常見(jiàn)策略（限流，降級(jí)，隔離，超時(shí)，重試和集群）。第二個(gè)方面是從流程方面（code review, 壓測(cè)，灰度和監(jiān)控）講解怎么去保證穩(wěn)定性。

演講嘉賓簡(jiǎn)介：
信海龍(花名滄龍)，十余年的互聯(lián)網(wǎng)開(kāi)發(fā)經(jīng)驗(yàn)，2013年加入阿里巴巴，深耕于電商、社區(qū)相關(guān)應(yīng)用開(kāi)發(fā)與架構(gòu)。同時(shí)也是多個(gè)開(kāi)源項(xiàng)目的開(kāi)發(fā)者和維護(hù)者。代表開(kāi)源作品，tclip，基于人臉識(shí)別的圖片裁剪擴(kuò)展。

本次直播視頻精彩回顧，戳這里！
直播回顧：https://yq.aliyun.com/live/965
PPT分享：https://yq.aliyun.com/download/3530
以下內(nèi)容根據(jù)演講嘉賓視頻和PPT分享整理而成。

本次的分享主要圍繞以下三個(gè)方面：

穩(wěn)定性的重要性

保障策略架構(gòu)篇

保障策略流程篇

穩(wěn)定性的重要性

對(duì)很多企業(yè)來(lái)說(shuō)服務(wù)穩(wěn)定性非常重要，首先穩(wěn)定性問(wèn)題會(huì)對(duì)企業(yè)帶來(lái)直接的經(jīng)濟(jì)損失。舉例來(lái)說(shuō)，亞馬遜的“Prime Day”當(dāng)天出現(xiàn)的一個(gè)故障，給亞馬遜帶來(lái)了高達(dá)9900萬(wàn)美元的損失。這一個(gè)故障損失就可能是其它小公司市值的幾倍。所以服務(wù)穩(wěn)定性對(duì)公司影響是特別大的。而對(duì)于個(gè)人來(lái)說(shuō)，服務(wù)不穩(wěn)定性會(huì)影響員工的績(jī)效，甚至影響個(gè)人前程。

保障策略架構(gòu)篇

從架構(gòu)層面保障穩(wěn)定性，常見(jiàn)的策略包括限流，降級(jí)，隔離，超時(shí)，重試和集群等。

1.限流

限流目的
限流的目的主要有兩點(diǎn)，第一點(diǎn)是防止系統(tǒng)高負(fù)荷運(yùn)行，第二點(diǎn)是有效利用服務(wù)器資源。為什么要做限流？假如不封鎖請(qǐng)求，可能會(huì)導(dǎo)致服務(wù)器報(bào)警，如果平時(shí)服務(wù)器只能處理100個(gè)請(qǐng)求，突然多出兩個(gè)請(qǐng)求服務(wù)器或許勉強(qiáng)能夠處理，但突然多了500個(gè)請(qǐng)求的話，后面的400個(gè)請(qǐng)求只處在積壓狀態(tài)，等服務(wù)器處理到第500個(gè)請(qǐng)求的時(shí)候，用戶等待時(shí)間就會(huì)過(guò)長(zhǎng)，而且最后積壓部分的請(qǐng)求可能根本就是無(wú)效的處理，因?yàn)橛脩粼缫蚜魇А?br /> 限流算法
常見(jiàn)限流的算法包括漏桶算法和令牌桶算法。漏桶算法如下圖，圖中的例子有個(gè)小桶，桶下面有個(gè)孔，每流一滴水就可以認(rèn)為是一個(gè)請(qǐng)求進(jìn)去。滴水的速率是一樣的，孔的高度也是固定的。漏桶算法能保證每個(gè)請(qǐng)求的負(fù)載時(shí)長(zhǎng)，即確定每秒能處理的請(qǐng)求數(shù)量。

漏痛算法實(shí)現(xiàn)如下圖，可以設(shè)定桶的高度是5個(gè)，每秒漏兩個(gè)。執(zhí)行效果中前面5次結(jié)果都是true，之后中間一次結(jié)果是false，這說(shuō)明桶已經(jīng)裝滿，之后又漏了兩滴水，因?yàn)閒alse的時(shí)候sleep了一秒，所以下面又有兩個(gè)true出來(lái)。

令牌桶算法
如下圖，令牌桶算法也是有一個(gè)桶，但是桶不漏，桶里面放了一些令牌，每來(lái)一個(gè)請(qǐng)求就在桶里拿一個(gè)令牌，如果沒(méi)有令牌它就可以等待，令牌滿了就不再往里面加令牌。這樣方法基本上也可以達(dá)到一個(gè)限流的目的。令牌桶算法和漏桶算法的一個(gè)顯著區(qū)別是漏桶算法在后端取請(qǐng)求量時(shí)，基本上漏的速率是一樣的，但是令牌桶算法中后端部分可以有突發(fā)請(qǐng)求，如果桶滿了，可以將桶里所有令牌都拿走。

下圖是令牌桶算法lua代碼實(shí)現(xiàn)部分，當(dāng)然讀者還可以使用Nginx，Java腳本或者php腳本來(lái)實(shí)現(xiàn)。

2.降級(jí)

社區(qū)降級(jí)案例
一般情況下，系統(tǒng)上線之后總會(huì)遇到一些不穩(wěn)定情況，比如redis掛掉，甚至后端數(shù)據(jù)庫(kù)My SQL掛掉。當(dāng)出現(xiàn)不穩(wěn)定情況之后，系統(tǒng)如何保證繼續(xù)提供這些服務(wù)。以社區(qū)案例為例，即便是My SQL掛掉，也要能夠保證社區(qū)為用戶提供基本的可讀服務(wù)。其中一個(gè)策略是將一些熱點(diǎn)數(shù)據(jù)，即用戶經(jīng)常瀏覽的信息或者最新的信息緩存起來(lái)，當(dāng)后端服務(wù)不可用的時(shí)候，把這些數(shù)據(jù)展現(xiàn)給用戶。大概流程如下圖，數(shù)據(jù)存儲(chǔ)部分后端會(huì)有一個(gè)腳本去分析Nginx里面的日志，然后去請(qǐng)求Vanish，Vanish再去請(qǐng)求后端，這樣的話Vanish會(huì)有一個(gè)有效期，能夠保證Vanish存進(jìn)去的數(shù)據(jù)都是用戶經(jīng)常訪問(wèn)的一些數(shù)據(jù)。第二步，如何保證后端數(shù)據(jù)庫(kù)掛掉的數(shù)據(jù)時(shí)候能遷過(guò)去？下圖可以看到，Nginx中使用lua腳本進(jìn)行實(shí)現(xiàn)，它會(huì)檢測(cè)后端服務(wù)返回的一些狀態(tài)，使用計(jì)數(shù)器計(jì)算失敗次數(shù)，如果頻繁的達(dá)到一定程度的失敗次數(shù)，就切換到從Vanish獲取數(shù)據(jù)，最后推送給用戶。這樣能保證即便是后端的數(shù)據(jù)庫(kù)掛掉，甚至即便所有的php進(jìn)程都掛掉的時(shí)候，社區(qū)也能給用戶提供一些基本的服務(wù)。

降級(jí)目的
降級(jí)的目的比較簡(jiǎn)單，第一個(gè)是保障服務(wù)器基本可用，第二個(gè)是保障服務(wù)的核心服務(wù)可用。降級(jí)是怎么一個(gè)思路呢？一般降級(jí)的每個(gè)策略都是針對(duì)一個(gè)場(chǎng)景，預(yù)想特定場(chǎng)景下需要要解決什么問(wèn)題；然后再梳理在這個(gè)場(chǎng)景下需要保留哪些核心基本服務(wù)；最后才選定技術(shù)方案，系統(tǒng)化的進(jìn)行實(shí)現(xiàn)。簡(jiǎn)單講就是先確定需要達(dá)到什么目的，再去了解是什么樣的情況，最后制定策略或者計(jì)劃。比如，系統(tǒng)會(huì)調(diào)用第三方服務(wù)，而第三方服務(wù)有可能掛掉，這是一種典型的場(chǎng)景。再比如，系統(tǒng)本身調(diào)用推薦服務(wù)，但是推薦服務(wù)也會(huì)掛掉，這種場(chǎng)景下不能夠因?yàn)闆](méi)有推薦數(shù)據(jù)就不顯示數(shù)據(jù)，還是需要展示一些數(shù)據(jù)，這是一種基本的核心服務(wù)。每年的雙11或者一些大型活動(dòng)中基本都會(huì)存在降級(jí)。降級(jí)不僅僅是存在于資源故障場(chǎng)景下，資源不夠用時(shí)也可能會(huì)需要降級(jí)，因?yàn)橘Y源不夠用需要關(guān)注重點(diǎn)。如大促活動(dòng)中，需要先保證交易服務(wù)正常運(yùn)行，其它消耗資源的服務(wù)（如對(duì)賬）可以后續(xù)再去處理。

3.超時(shí)

超時(shí)案例
社區(qū)對(duì)外提供接口服務(wù)，對(duì)方的反饋是接口服務(wù)較慢。接口部分流程是查一段數(shù)據(jù)，然后將數(shù)據(jù)反映過(guò)去，其問(wèn)題點(diǎn)在于系統(tǒng)中超時(shí)時(shí)間設(shè)置過(guò)長(zhǎng)。比如調(diào)用Memcache，但是Memcache已經(jīng)掛掉，由于超時(shí)設(shè)置過(guò)長(zhǎng)，數(shù)據(jù)需要等到超時(shí)時(shí)間結(jié)束以后再返回，導(dǎo)致接口一直在等待。那如何設(shè)置超時(shí)時(shí)間才合理？要注意超時(shí)時(shí)間并不是固定的值，而是需要針對(duì)整個(gè)業(yè)務(wù)，根據(jù)特定場(chǎng)景設(shè)置超時(shí)時(shí)間值。

如何設(shè)置超時(shí)時(shí)間
大體的思路如下圖。第一步，識(shí)別業(yè)務(wù)需要的服務(wù)響應(yīng)時(shí)間。比如，需要100毫秒去響應(yīng)數(shù)據(jù)，之后統(tǒng)計(jì)業(yè)務(wù)里面可能需要調(diào)多少服務(wù)。第二步，統(tǒng)計(jì)服務(wù)日常的響應(yīng)時(shí)間。第三步，分清主次，即分出哪些是核心服務(wù)。因?yàn)楹诵姆?wù)一旦失敗，整個(gè)鏈路便不可用，所以可以對(duì)核心服務(wù)的時(shí)間設(shè)置的寬松一些。如果一些服務(wù)調(diào)不通，但又不影響整個(gè)鏈路，可以對(duì)它的時(shí)間設(shè)置的相對(duì)嚴(yán)格。

設(shè)置完超時(shí)之后需要驗(yàn)證，借助模擬手段封端口（如下圖），模擬故障，然后檢查數(shù)據(jù)返回時(shí)間是否在指定的時(shí)間內(nèi)。

4.隔離

隔離案例
下2013年左右，手機(jī)客戶端開(kāi)始逐漸升級(jí)起來(lái)，很多項(xiàng)目既有PC端也有客戶端，所以同一個(gè)服務(wù)即要為PC端又要為客戶端提供API接口。一旦遇到大型活動(dòng)或者需要手機(jī)推送，服務(wù)會(huì)遇到不穩(wěn)定情況，服務(wù)的不穩(wěn)定會(huì)導(dǎo)致PC端也受影響，所以需要將服務(wù)進(jìn)行物理隔離，從原先耦合到一塊的服務(wù)器分到不同的機(jī)器組。隔離目的非常簡(jiǎn)單，要限制住不穩(wěn)定因素導(dǎo)致的風(fēng)險(xiǎn)，停止傳播。
隔離形式
隔離的常見(jiàn)形式包括幾種。第一是秒殺場(chǎng)景，秒殺場(chǎng)景一個(gè)高并發(fā)的場(chǎng)景，可能帶來(lái)的問(wèn)題也比較多，在高并發(fā)場(chǎng)景下秒殺的時(shí)候，需要和一些正常的業(yè)務(wù)區(qū)分開(kāi)來(lái)，不建議一臺(tái)機(jī)器既提供秒殺也提供進(jìn)程服務(wù)。另外，秒殺的時(shí)候會(huì)產(chǎn)生熱點(diǎn)數(shù)據(jù)，如售賣數(shù)據(jù)。數(shù)據(jù)庫(kù)更新比較頻繁，從數(shù)據(jù)庫(kù)層面也可以進(jìn)行隔離，將熱點(diǎn)部分和正常服務(wù)部分從資源上隔離。第二個(gè)場(chǎng)景是慢SQL隔離，一個(gè)資源隔離。一條慢SQL會(huì)導(dǎo)致整個(gè)服務(wù)不穩(wěn)定。每請(qǐng)求一次線程，慢SQL會(huì)一直耗著當(dāng)前線程，所以資源占用非常大。第三個(gè)場(chǎng)景是機(jī)房隔離。一般大公司都會(huì)做多機(jī)房部署，其目的就是確保穩(wěn)定性。確保穩(wěn)定性時(shí)不要做跨機(jī)房調(diào)用，否則耦合度會(huì)比較高，假如A調(diào)B，B掛掉，A服務(wù)也會(huì)受影響。一般確保穩(wěn)定性都是做本機(jī)房的調(diào)用。而且本機(jī)房的調(diào)用性能也比較快。最后一個(gè)場(chǎng)景是進(jìn)程隔離，因?yàn)檫M(jìn)程比線程更加穩(wěn)定。

5.集群

對(duì)小公司而言，一臺(tái)機(jī)器就提供一個(gè)服務(wù)，如果機(jī)器掛掉服務(wù)恢復(fù)就會(huì)成為一個(gè)問(wèn)題。一般解決方法是做一個(gè)集群，從原來(lái)的一臺(tái)機(jī)器提供服務(wù)變?yōu)榭梢杂枚嗯_(tái)機(jī)器提供服務(wù)。集群的目的是為了解決單點(diǎn)的問(wèn)題。集群的形式主要有主備，即同時(shí)只有一臺(tái)機(jī)器提供整個(gè)服務(wù)，可以有一臺(tái)或者多臺(tái)提供備份，備份不僅要包含代碼層面，整個(gè)服務(wù)運(yùn)行所依賴的資源都要有備份。另外一個(gè)形式是主從。主是提供一個(gè)完整的服務(wù)，從是提供部分的服務(wù)。還有一種是多主，多主指的是每一臺(tái)機(jī)器的決策是對(duì)等的，都會(huì)對(duì)外提供一些服務(wù)。隨著集群形式的不同，對(duì)代碼編寫的并發(fā)性上有一定要求。主備只需要考慮單機(jī)的并發(fā)控制，主從是考慮同時(shí)提供服務(wù)的部分。比如加鎖，主備上只要加一個(gè)本地的技能鎖就可以，主從或者多主則需要加分布式鎖。

保證策略流程篇

保證穩(wěn)定性策略的流程方面上分為下圖中四個(gè)點(diǎn)，code review, 壓測(cè)，灰度和監(jiān)控。

1.Code review

code review目的是在項(xiàng)目上線前及時(shí)發(fā)現(xiàn)一些問(wèn)題。經(jīng)驗(yàn)比較豐富的人可以將經(jīng)驗(yàn)進(jìn)行分享。code review基本經(jīng)過(guò)三個(gè)階段。第一個(gè)階段是頭腦風(fēng)暴式，一群開(kāi)發(fā)人員圍著代碼做code review，雖然時(shí)間成本較高，效果也不太理想，但是這種方式也有好處，在前期可以將大家的意見(jiàn)進(jìn)行整理，制定code review的規(guī)范。第二種code review形式是演講式，專家事先把代碼做一下review，整理一些點(diǎn)，然后進(jìn)行分享。演講式可以按照輪崗制，相對(duì)頭腦風(fēng)暴式大大節(jié)約了時(shí)間。目前常見(jiàn)的code review 形式是結(jié)對(duì)式，由一個(gè)或者兩個(gè)專家結(jié)對(duì)，相互review，時(shí)間上比較靈活，也不需要占據(jù)會(huì)議室資源。

2.壓測(cè)

壓測(cè)目的
壓測(cè)的目的，第一是保證系統(tǒng)穩(wěn)定性。在高并發(fā)的時(shí)候，檢測(cè)系統(tǒng)是否穩(wěn)定，因?yàn)橐恍﹩?wèn)題在流量比較低的時(shí)候發(fā)現(xiàn)不了，只有在高并發(fā)的時(shí)候才能發(fā)現(xiàn)這個(gè)問(wèn)題。第二是檢測(cè)性能的抗壓能力，檢查系統(tǒng)能承受多大的QPS。
壓測(cè)關(guān)注點(diǎn)
首先，壓測(cè)機(jī)器和被壓測(cè)服務(wù)在同一網(wǎng)段，盡量避免因?yàn)榫W(wǎng)絡(luò)原因?qū)е聣簻y(cè)的結(jié)果不準(zhǔn)確。第二點(diǎn)是關(guān)注服務(wù)器的負(fù)載，注意不要把服務(wù)器壓到100%，服務(wù)器快要崩的時(shí)候，得到的值意義不大。應(yīng)該是服務(wù)器負(fù)載達(dá)到60%~70%的時(shí)候，看QPS是多少。另外，壓測(cè)并發(fā)數(shù)據(jù)是逐步遞增的過(guò)程，到一個(gè)點(diǎn)的時(shí)候，并發(fā)數(shù)據(jù)越多代表QPS越低。最后，根據(jù)測(cè)試環(huán)境的壓測(cè)結(jié)果估算線上的承載能力。估算的公式是線上QPS = 單機(jī)QPS?機(jī)器數(shù)?0.7。后面會(huì)乘以一個(gè)系數(shù)（0.7）是因?yàn)榫€上put上去的時(shí)候總會(huì)存在一些損耗。

全鏈路壓測(cè)
但有一些測(cè)試在測(cè)試環(huán)境下無(wú)法實(shí)現(xiàn)壓測(cè)，所以現(xiàn)在發(fā)展成了全鏈路壓測(cè)。全鏈路壓測(cè)大概分成三個(gè)核心關(guān)注點(diǎn)。第一個(gè)是數(shù)據(jù)模型的構(gòu)造。全鏈路壓測(cè)是模擬線上真正的數(shù)據(jù)模型，比如說(shuō)訪問(wèn)詳情頁(yè)的人數(shù)，下單的人數(shù)，人數(shù)比例，登陸人數(shù)等等參數(shù)，盡量按照真實(shí)數(shù)據(jù)模擬，構(gòu)建仿真模型，這樣才能真正的發(fā)現(xiàn)線上的一些問(wèn)題。注意全鏈路壓測(cè)不是在測(cè)試環(huán)境下實(shí)現(xiàn)，而是在線上壓測(cè)。第二個(gè)是壓測(cè)工具構(gòu)建?？梢允墙柚_(kāi)源的壓測(cè)工具，阿里自建了壓測(cè)平臺(tái)，根據(jù)數(shù)據(jù)模型提升流量。第三點(diǎn)是流量的隔離。對(duì)流量增加標(biāo)識(shí)，保證不影響線上的數(shù)據(jù)，將全鏈路測(cè)試流量放到測(cè)試的存儲(chǔ)中。比如生成一個(gè)訂單order表，同時(shí)也會(huì)生成一個(gè)影子表test_order。如果發(fā)現(xiàn)是來(lái)自于全鏈路壓測(cè)的流量，就把這個(gè)數(shù)據(jù)寫到影子表test_order里面，這樣能夠保證存儲(chǔ)。無(wú)論是緩存還是數(shù)據(jù)庫(kù)存儲(chǔ)都能夠進(jìn)行流量隔離。

3.灰度

灰度目的是小范圍試錯(cuò)，盡量發(fā)現(xiàn)問(wèn)題。灰度的策略大概有以下幾種，第一個(gè)策略是只讓某一個(gè)地區(qū)的人先訪問(wèn)最新的特性，遇到問(wèn)題的話用戶及時(shí)反饋，問(wèn)題也只會(huì)影響特定地區(qū)。另外一個(gè)策略是基于用戶屬性，如一個(gè)推薦系統(tǒng)，請(qǐng)求過(guò)來(lái)的時(shí)候能區(qū)分新老用戶，它對(duì)新老用戶的推薦的策略可能是不一樣的，從而來(lái)驗(yàn)證策略的準(zhǔn)確性和有效性。第三種策略是基于數(shù)據(jù)，從一批用戶中選取幾個(gè)用戶進(jìn)行處理。比如，對(duì)供應(yīng)鏈的供應(yīng)商的數(shù)據(jù)做處理，但是一般情況下不敢保證代碼上線之后100%沒(méi)問(wèn)題。這時(shí)先選擇一個(gè)供應(yīng)商處理，驗(yàn)證數(shù)據(jù)，確保沒(méi)問(wèn)題再全量處理所有的供應(yīng)商。最后是基于平臺(tái)，一般都發(fā)生在客戶端場(chǎng)景下。客戶端與服務(wù)端不同，服務(wù)端一般是針對(duì)這個(gè)平臺(tái)，先指揮這個(gè)平臺(tái)先發(fā)布新版本，反饋不錯(cuò)再推到整個(gè)全面平臺(tái)。對(duì)于客戶端的灰度技術(shù)的實(shí)現(xiàn)如下圖，給客戶端集中一個(gè)Cookie，請(qǐng)求到了之后在Nginx中去檢查Cookie，根據(jù)不同的Cookie把情趣轉(zhuǎn)到不同的組。比如組A有新特性，組B是老版本，根據(jù)不同的Cookie轉(zhuǎn)到不同組，保證只有一部分人可以看到新的特性。

4.監(jiān)控

監(jiān)控注意點(diǎn)
監(jiān)控的目的是可以自動(dòng)化及時(shí)發(fā)現(xiàn)問(wèn)題。監(jiān)控需要注意幾點(diǎn)問(wèn)題，第一是全方面監(jiān)控，系統(tǒng)和服務(wù)全部都要監(jiān)控。第二是報(bào)警分級(jí)，監(jiān)控報(bào)警的系數(shù)設(shè)置的要合理。最后一點(diǎn)是在真實(shí)環(huán)境下做數(shù)據(jù)收集。比如，A和B服務(wù)器，只在B服務(wù)器做監(jiān)控。如果A服務(wù)器My SQL數(shù)據(jù)庫(kù)網(wǎng)絡(luò)出問(wèn)題后，因?yàn)樵诒O(jiān)控上B服務(wù)器是正常的，監(jiān)控不會(huì)報(bào)警。所以要在應(yīng)用服務(wù)器上做監(jiān)控才會(huì)報(bào)警具體哪臺(tái)機(jī)器哪個(gè)服務(wù)出現(xiàn)故障等信息。

自研監(jiān)控系統(tǒng)
下圖是阿里自研的監(jiān)控系統(tǒng)。首先確定對(duì)哪些指標(biāo)進(jìn)行監(jiān)控。將整個(gè)指標(biāo)的數(shù)據(jù)繪制出來(lái)，查看指標(biāo)數(shù)據(jù)波動(dòng)。一旦遇到問(wèn)題，可以很方便的進(jìn)行對(duì)比。另外要確定影響，將所有相關(guān)的指標(biāo)聚合起來(lái)。比如供應(yīng)商的團(tuán)隊(duì)操控系統(tǒng)經(jīng)常會(huì)發(fā)生倉(cāng)庫(kù)操作卡頓，有很多因素都會(huì)導(dǎo)致卡頓，如PC端調(diào)用其它接口較慢，服務(wù)器load比較高等。倉(cāng)庫(kù)人員無(wú)法關(guān)注具體的細(xì)節(jié)，他們?cè)谟绊懡缑娌榭粗笜?biāo)影響值，一眼就可以知道是哪項(xiàng)指標(biāo)不合格導(dǎo)致的卡頓。之后對(duì)造成的影響進(jìn)行相應(yīng)的處理，目前一般的行為有效報(bào)警或短信報(bào)警。?

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的阿里云栖开发者沙龙PHP技术专场-聊聊服务稳定性保障这些事的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。