在硅谷一線大廠所維護的系統(tǒng)服務(wù)中，我們經(jīng)呈堵瘢可以看見SLA這樣的承諾凡伊。
例如，在谷歌的云計算服務(wù)平臺Google Cloud Platform中窒舟，他們會寫著“99.9% Availability”這樣的承諾系忙。那什么是“99.9% Availability”呢？
要理解這個承諾是什么意思惠豺，首先银还，你需要了解到底什么是SLA？
SLA（Service-Level Agreement）洁墙，也就是服務(wù)等級協(xié)議蛹疯，指的是系統(tǒng)服務(wù)提供者（Provider）對客戶（Customer）的一個服務(wù)承諾。這是衡量一個大型分布式系統(tǒng)是否“健康”的常見方法热监。
在開發(fā)設(shè)計系統(tǒng)服務(wù)的時候捺弦，無論面對的客戶是公司外部的個人、商業(yè)用戶孝扛，還是公司內(nèi)的不同業(yè)務(wù)部門羹呵，我們都應(yīng)該對自己所設(shè)計的系統(tǒng)服務(wù)有一個定義好的SLA。
因為SLA是一種服務(wù)承諾疗琉，所以指標可以多種多樣冈欢。根據(jù)我的實踐經(jīng)驗，給你介紹最常見的四個SLA指標盈简，可用性凑耻、準確性、系統(tǒng)容量和延遲柠贤。
1. 可用性（Availabilty）
可用性指的是系統(tǒng)服務(wù)能正常運行所占的時間百分比香浩。
如果我們搭建了一個擁有“100％可用性”的系統(tǒng)服務(wù)，那就意味著這個系統(tǒng)在任何時候都能正常運行臼勉。是不是很完美邻吭？但真要實現(xiàn)這樣的目標其實非常困難，并且成本也會很高宴霸。
我們知道囱晴，即便是大名鼎鼎的亞馬遜AWS云計算服務(wù)這樣大型的、對用戶來說極為關(guān)鍵的系統(tǒng)瓢谢，也不能承諾100％的可用性畸写，它的系統(tǒng)服務(wù)從推出到現(xiàn)在，也有過服務(wù)中斷（Service Outage）的時候氓扛。
對于許多系統(tǒng)而言枯芬，四個9的可用性（99.99％ Availability，或每年約50分鐘的系統(tǒng)中斷時間）即可以被認為是高可用性（High availability）。
說到這里千所，我來為你揭開一開始所提到的“99.9% Availability”的真實含義狂魔。
“99.9% Availability”指的是一天當中系統(tǒng)服務(wù)將會有大約86秒的服務(wù)間斷期。服務(wù)間斷也許是因為系統(tǒng)維護淫痰，也有可能是因為系統(tǒng)在更新升級系統(tǒng)服務(wù)最楷。
86秒這個數(shù)字是怎么算出來的呢？
99.9%意味著有0.1%的可能性系統(tǒng)服務(wù)會被中斷黑界，而一天中有24小時 × 60分鐘 × 60秒管嬉，也就是有(24 × 60 × 60 × 0.001) = 86.4秒的可能系統(tǒng)服務(wù)被中斷了皂林。而上面所說的四個9的高可用性服務(wù)就是承諾可以將一天當中的服務(wù)中斷時間縮短到只有(24 × 60 × 60 × 0.0001) = 8.64秒朗鸠。
2. 準確性（Accuracy）
準確性指的是我們所設(shè)計的系統(tǒng)服務(wù)中，是否允許某些數(shù)據(jù)是不準確的或者是丟失了的础倍。如果允許這樣的情況發(fā)生烛占，用戶可以接受的概率（百分比）是多少？
這該怎么衡量呢沟启？不同的系統(tǒng)平臺可能會用不同的指標去定義準確性忆家。很多時候，系統(tǒng)架構(gòu)會以錯誤率（Error Rate）來定義這一項SLA德迹。
怎么計算錯誤率呢芽卿？可以用導致系統(tǒng)產(chǎn)生內(nèi)部錯誤（Internal Error）的有效請求數(shù)，除以這期間的有效請求總數(shù)胳搞。
例如卸例，我們在一分鐘內(nèi)發(fā)送100個有效請求到系統(tǒng)中，其中有5個請求導致系統(tǒng)返回內(nèi)部錯誤肌毅，那我們可以說這一分鐘系統(tǒng)的錯誤率是 5 / 100 = 5%筷转。
下面，我想帶你看看硅谷一線公司所搭建的架構(gòu)平臺的準確性SLA悬而。
Google Cloud Platform的SLA中呜舒，有著這樣的準確性定義：每個月系統(tǒng)的錯誤率超過5%的時間要少于0.1%，以每分鐘為單位來計算笨奠。
而亞馬遜AWS云計算平臺有著稍微不一樣的準確性定義：以每5分鐘為單位袭蝗，錯誤率不會超過0.1%。
你看般婆，我們可以用錯誤率來定義準確性呻袭，但具體該如何評估系統(tǒng)的準確性呢？一般來說腺兴，我們可以采用性能測試（Performance Test）或者是查看系統(tǒng)日志（Log）兩種方法來評估左电。
具體的做法我會在后面展開講解，今天你先理解這項指標就可以了。
3. 系統(tǒng)容量（Capacity）
在數(shù)據(jù)處理中篓足，系統(tǒng)容量通常指的是系統(tǒng)能夠支持的預期負載量是多少段誊，一般會以每秒的請求數(shù)為單位來表示。
我們常痴煌希可以看見连舍，某個系統(tǒng)的架構(gòu)可以處理的QPS （Queries Per Second）是多少又或者RPS（Requests Per Second）是多少。這里的QPS或者是RPS就是指系統(tǒng)每秒可以響應(yīng)多少請求數(shù)涩哟。
我們來看看之前Twitter發(fā)布的一項數(shù)據(jù)索赏，Twitter系統(tǒng)可以響應(yīng)30萬的QPS來讀取Twitter Timelines。這里Twitter系統(tǒng)給出的就是他們對于系統(tǒng)容量（Capacity）的SLA贴彼。
你可能會問潜腻，我要怎么給自己設(shè)計的系統(tǒng)架構(gòu)定義出準確的QPS呢？以我的經(jīng)驗看器仗，可以有下面這幾種方式融涣。
第一種，是使用限流（Throttling）的方式精钮。
如果你是使用Java語言進行編程的威鹿，就可以使用Google Guava庫中的RateLimiter類來定義每秒最多發(fā)送多少請求到后臺處理。
假設(shè)我們在每臺服務(wù)器都定義了一個每秒最多處理1000個請求的RateLimiter轨香，而我們有N臺服務(wù)器忽你，在最理想的情況下，我們的QPS可以達到1000 * N臂容。
這里要注意的雷區(qū)是科雳，這個請求數(shù)并不是設(shè)置得越多越好。因為每臺服務(wù)器的內(nèi)存有限策橘，過多的請求堆積在服務(wù)器中有可能會導致內(nèi)存溢出（Out-Of-Memory）的異常發(fā)生炸渡，也就是所有請求所需要占用的內(nèi)存超過了服務(wù)器能提供的內(nèi)存，從而讓整個服務(wù)器崩潰丽已。
第二種蚌堵，是在系統(tǒng)交付前進行性能測試（Performance Test）。
我們可以使用像Apache JMeter又或是LoadRunner這類型的工具對系統(tǒng)進行性能測試沛婴。這類工具可以測試出系統(tǒng)在峰值狀態(tài)下可以應(yīng)對的QPS是多少吼畏。
當然了，這里也是有雷區(qū)的嘁灯。
有的開發(fā)者可能使用同一類型的請求參數(shù)泻蚊，導致后臺服務(wù)器在多數(shù)情況下命中緩存（Cache Hit）。這個時候得到的QPS可能并不是真實的QPS丑婿。
打個比方性雄，服務(wù)器處理請求的正常流程需要查詢后臺數(shù)據(jù)庫没卸，得到數(shù)據(jù)庫結(jié)果后再返回給用戶，這個過程平均需要1秒秒旋。在第一次拿到數(shù)據(jù)庫結(jié)果后约计，這個數(shù)據(jù)就會被保存在緩存中，而如果后續(xù)的請求都使用同一類型的參數(shù)迁筛，導致結(jié)果不需要從數(shù)據(jù)庫得到煤蚌，而是直接從緩存中得到，這個過程我們假設(shè)只需要0.1秒细卧。那這樣尉桩，我們所計算出來的QPS就會比正常的高出10倍。所以在生成請求的時候贪庙，要格外注意這一點蜘犁。
第三種，是分析系統(tǒng)在實際使用時產(chǎn)生的日志（Log）插勤。
系統(tǒng)上線使用后沽瘦，我們可以得到日志文件革骨。一般的日志文件會記錄每個時刻產(chǎn)生的請求农尖。我們可以通過系統(tǒng)每天在最繁忙時刻所接收到的請求數(shù)，來計算出系統(tǒng)可以承載的QPS良哲。
不過盛卡，這種方法不一定可以得到系統(tǒng)可以承載的最大QPS。
在這里打個比喻筑凫，一家可以容納上百桌客人的餐館剛開業(yè)滑沧，因為客流量還比較小，在每天最繁忙的時候只接待了10桌客人巍实。那我們可以說這家餐館最多只能接待10桌客人嗎滓技？不可以。
同樣的棚潦，以分析系統(tǒng)日志的方法計算出來的QPS并不一定是服務(wù)器能夠承載的最大QPS令漂。想要得到系統(tǒng)能承受的最大QPS，更多的是性能測試和日志分析相結(jié)合的手段丸边。
- 延遲（Latency）
延遲指的是系統(tǒng)在收到用戶的請求到響應(yīng)這個請求之間的時間間隔叠必。
在定義延遲的SLA時，我們常趁媒眩看到系統(tǒng)的SLA會有p95或者是p99這樣的延遲聲明纬朝。這里的p指的是percentile，也就是百分位的意思骄呼。如果說一個系統(tǒng)的p95 延遲是1秒的話共苛，那就表示在100個請求里面有95個請求的響應(yīng)時間會少于1秒判没，而剩下的5個請求響應(yīng)時間會大于1秒。
下面我們用一個具體的例子來說明延遲這項指標在SLA中的重要性隅茎。
假設(shè)哆致，我們已經(jīng)設(shè)計好了一個社交軟件的系統(tǒng)架構(gòu)。這個社交軟件在接收到用戶的請求之后患膛，需要讀取數(shù)據(jù)庫中的內(nèi)容返回給用戶摊阀。
為了降低系統(tǒng)的延遲，我們會將數(shù)據(jù)庫中內(nèi)容放進緩存（Cache）中踪蹬，以此來減少數(shù)據(jù)庫的讀取時間胞此。在系統(tǒng)運行了一段時間后，我們得到了一些緩存命中率（Cache Hit Ratio）的信息跃捣。有90%的請求命中了緩存漱牵，而剩下的10%的請求則需要重新從數(shù)據(jù)庫中讀取內(nèi)容。
這時服務(wù)器所給我們的p95或者p99延遲恰恰就衡量了系統(tǒng)的最長時間疚漆，也就是從數(shù)據(jù)庫中讀取內(nèi)容的時間酣胀。作為一個優(yōu)秀架構(gòu)師，你可以通過改進緩存策略從而提高緩存命中率娶聘，也可以通過優(yōu)化數(shù)據(jù)庫的Schema或者索引（Index）來降低p95或p99 延遲闻镶。
總而言之，當p95或者p99過高時丸升，總會有5%或者1%的用戶抱怨產(chǎn)品的用戶體驗太差铆农，這都是我們要通過優(yōu)化系統(tǒng)來避免的。
