可用性

可靠性：系統(tǒng)是否具備無差別的執(zhí)行預(yù)期操作的能力。主要指標：是否通過了所有測試套件。 3+2=6 ?不可靠

可用性：為了執(zhí)行這些操作，系統(tǒng)當前可運行的能力。主要指標：是否能進行響應(yīng)。

測量可用性公式：網(wǎng)站可用性百分比=(該期間的總秒數(shù)－系統(tǒng)宕機的秒數(shù))/該期間的總秒數(shù)

N個9	百分比	每月的故障時間
2個9	99%	432m
3個9	99.9%	43m
4個9	99.99%	4m
5個9	99.999%	26s
6個9	99.9999%	2.6s

什么可能導(dǎo)致低可用性：

資源耗盡　　io&網(wǎng)絡(luò)&內(nèi)存等

預(yù)期之外的壓力變化　　黑客攻擊，突發(fā)事件流量

流動行為的增加　　一次上線協(xié)作的人越來越多，發(fā)生失誤的概率也就越大

外部依賴　　外部的資源是否可用可靠的影響

技術(shù)債務(wù)　　對已知bug未修復(fù)的累計，未知bug的隱患，新需求的合理性問題

提高可用性的五個要點：

?時刻考慮應(yīng)對故障

時刻考慮如何伸縮

緩和風險　　即使服務(wù)和資源無法不可用時，依然確保系統(tǒng)以最好的最完整的狀態(tài)工作

監(jiān)控可用性　　

• 服務(wù)器監(jiān)控
• 配置變化監(jiān)控
• 應(yīng)用程序性能監(jiān)控
• 人為測試
• 報警　　

以可預(yù)期及明確的方式來處理可用性問題

風險管理

風險管理就是在消除風險的成本與風險發(fā)生的成本(緩和風險)之間保持平衡。

風險緩和指的是通過降低風險發(fā)生的可能性或者降低風險發(fā)生時的嚴重性，來降低風險的影響。

風險的重要程度就會風險發(fā)生的嚴重性和可能性兩者之和。為了降低風險，至少需要降低其中之一。?

嚴重性：如果發(fā)生風險，所需付出的代價。

可能性：風險發(fā)生的幾率。?

管理系統(tǒng)風險的基本步驟：

識別風險　　創(chuàng)建系統(tǒng)已知風險列表即風險模型。

消除風險　　找出需要解決的風險，制定解決計劃

風險緩和　　制定緩和計劃降低風險發(fā)生的可能性和嚴重性

定期檢查　　定期檢查風險模型，更新計劃?

風險模型的風險項：模版地址(http://bit.ly/architectbookdl)

風險ID：每個風險的唯一標識。

系統(tǒng)：風險所屬系統(tǒng)或者子系統(tǒng)或者模塊的名稱。

所有人：風險負責人抑或團隊，負責制定風險的緩和計劃和解決計劃。

風險描述：風險的概要描述，便于查看和領(lǐng)會。

標識日期：該風險入模型的日期。

可能性：分高中低。

嚴重性：分高中低。

風險緩和計劃：正在使用的或者已商定的用來降低該風險嚴重性和可能性的措施和策略。

狀態(tài)：該風險當前的狀態(tài)?；钴S，已緩和，正在修復(fù)，已解決等。

ETA：該風險預(yù)估解決日期。

監(jiān)控：是否對該風險進行了監(jiān)控，監(jiān)控方式策略，譬如人為監(jiān)控，每周定位。自動監(jiān)控，日志觸發(fā)。

觸發(fā)計劃：此風險發(fā)生后，是否有計劃處理此風險。時間響應(yīng)文檔，應(yīng)急手冊等。

備注：記錄風險對演化歷史，以便于回溯。

跟蹤ID：需求或者bug ID。

風險模型的作用域：

團隊管理

公司戰(zhàn)略

系統(tǒng)模塊

個人

售后支持

安全威脅

維護風險模型：

風險模型最大挑戰(zhàn)就是人的惰性和模型本身對過時，需定期變換檢查風險模型對人員，可以有碰撞和嶄新對視角。

發(fā)現(xiàn)新風險

刪除舊風險

更新可能性和嚴重性

檢查優(yōu)先級高的風險　　計劃是否生效 ?當前狀態(tài)和頻率

檢查優(yōu)先級低的風險

構(gòu)建低風險系統(tǒng)的常用手段：

冗余　　增強可用性

冪等　　降低出錯的概率

獨立性　　冗余后卻都部署在一個機房就不具備獨立性

安全　　攻擊，誤操作等

自修復(fù)　　集群 主備切換等

運維流程　　保持腳本自動化 ?可追溯 可重現(xiàn) 減少人為的參與　　?

?微服務(wù)

為何要用微服務(wù)：

所有者收益：讓每個服務(wù)都有清晰的所有權(quán)，團隊可以只關(guān)注于他們負責的模塊，以及依賴服務(wù)的api約定。

規(guī)模收益：系統(tǒng)在不同模塊上的伸縮性需求不一樣。

如何決定服務(wù)的邊界：

特定的業(yè)務(wù)需求　　 監(jiān)管 信用卡等業(yè)務(wù)

清晰獨立的團隊所有權(quán)　　負責該功能的團隊是否清晰和獨立，在不同城市不同樓層能否幫助確定服務(wù)邊界

天然的隔離的數(shù)據(jù)　　其管理的數(shù)據(jù)是否天然與其他數(shù)據(jù)相獨立？

共享的能力和數(shù)據(jù)?　　是否需要被其他模塊共享？代辦，消息等。

服務(wù)故障的常見形式和解決方案

級聯(lián)式的服務(wù)故障：一個服務(wù)故障可能導(dǎo)致整個系統(tǒng)發(fā)生嚴重的問題。

對服務(wù)api的響應(yīng)約定：

可預(yù)測的　　返回錯誤提示信息

可理解的　　格式和結(jié)構(gòu)要穩(wěn)定和統(tǒng)一

對當前情形是合理的　　需要的是可刪除的用戶，因為錯誤，不能返回全部用戶，應(yīng)當返回無或者無法返回結(jié)果。

對服務(wù)api的請求約定：

服務(wù)約束　　服務(wù)的能力范圍，入?yún)⒌暮戏ㄐ约s束

QPS　　服務(wù)所能提供的最高并發(fā)請求數(shù)

?服務(wù)故障的應(yīng)對：

優(yōu)雅降級　　不重要的服務(wù)可選擇提供有限的功能，舍棄故障服務(wù)提供的數(shù)據(jù)

優(yōu)雅補償　　搜索銷量前十的服務(wù)故障，可返還最流行的前十的數(shù)據(jù)

盡早失敗　　核心的依賴服務(wù)故障或者輸入?yún)?shù)不合法，自身的服務(wù)在注定會失敗的前提下盡早失敗。?

微服務(wù)的伸縮性(保證兩個失誤的高度，即掛兩個節(jié)點的伸縮性)：

丟失一個節(jié)點　　QPS會不會爆

升級或者重啟一個節(jié)點(輪流部署)　　升級中丟一個節(jié)點QPS會不會爆

數(shù)據(jù)中心的冗余和恢復(fù)　　一個中心可能有多個節(jié)點 ?即也須考慮多個中心的伸縮性 ? 數(shù)據(jù)中心越多每個數(shù)據(jù)中心所需的節(jié)點越少

隱藏的共享故障　　機架停電 ?城市斷電

服務(wù)所有權(quán)的義務(wù)和權(quán)利：

API設(shè)計　　api的設(shè)計實現(xiàn)測試和版本管理工作

服務(wù)開發(fā)　　業(yè)務(wù)邏輯的設(shè)計開發(fā)和測試

數(shù)據(jù)　　數(shù)據(jù)展現(xiàn)，模型，訪問方式以及生命周期

部署　　負責決定服務(wù)是否需要升級以及部署

部署窗口　　決定什么時間可以進行安全部署

產(chǎn)品變更　　負載均衡器的設(shè)置和系統(tǒng)調(diào)優(yōu)

環(huán)境　　管理服務(wù)的生產(chǎn)環(huán)境以及所有環(huán)境

服務(wù)SLA　　討論確定并監(jiān)控SLA，以及保障服務(wù)滿足SLA的相關(guān)工作職責

監(jiān)控　　監(jiān)控SLA IO CPU等

值班/突發(fā)事件響應(yīng)　　確保突發(fā)事件的響應(yīng)速度能滿足之前定的SLA

報告　　向外部發(fā)送內(nèi)部報告，以及服務(wù)的運行健康報告。

服務(wù)分級：

1級服務(wù)　　如果某個服務(wù)出現(xiàn)故障會導(dǎo)致用戶或者公司業(yè)務(wù)產(chǎn)生重大損失。 登錄服務(wù)，權(quán)限服務(wù)，訂單處理服務(wù)。

2級服務(wù)　　如果某個服務(wù)發(fā)生故障，會導(dǎo)致用戶體驗顯著受到影響，但是不會導(dǎo)致無法使用你的系統(tǒng)。 搜索服務(wù)，訂單結(jié)算服務(wù)。?

3級服務(wù)　　對用戶造成較小的不易注意到的影響，對系統(tǒng)造成有限的影響。用戶頭像服務(wù)，推薦服務(wù)，每日提醒服務(wù)。

4級服務(wù)　　即使失敗也不會對用戶體驗造成任何嚴重的影響，也不會對業(yè)務(wù)和資金方有任何影響。 銷售報告服務(wù)，郵件發(fā)送服務(wù)。

使用服務(wù)分級：SLA服務(wù)等級協(xié)議

期望　　對這個級數(shù)的服務(wù)的期望，可成為溝通語言的一部分，描述用戶對系統(tǒng)的期待(外部SLA)，服務(wù)調(diào)用方對服務(wù)提供方的要求(內(nèi)部SLA)

• 調(diào)用延遲
• 流量QPS
• 運行時長 ?一段時間的可用性
• 錯誤率

響應(yīng)性　　對這個級數(shù)的服務(wù)的響應(yīng)性要求

• 問題的嚴重性
• 出現(xiàn)問題的服務(wù)級別

依賴?　　依賴的梳理歸類

• 關(guān)鍵依賴 ? 你的服務(wù)級別高于依賴服務(wù)的級別 ?自身服務(wù)在關(guān)鍵依賴故障時需仍然盡力提供功能
• 非關(guān)鍵依賴 ?你的服務(wù)級別低于依賴服務(wù)的級別 ?可以忽略你依賴的此服務(wù)的故障，因為此服務(wù)的可用性和響應(yīng)性比你高。

ps:

排名SLA，tp90>20ms(前置條件相同的QPS下)

tp90：(抽樣總數(shù)*10%) ?需要排除的樣本數(shù)量 ? ?排除掉這么多的耗時最高的響應(yīng)樣本

20ms：取剩下的樣本中耗時最高的響應(yīng)時間

云服務(wù)?

區(qū)域：云資源相連形成的一大片地區(qū)成為區(qū)域，表示一個特定的地理區(qū)域。描述和記錄了云資源的地理拓撲多樣性，網(wǎng)絡(luò)拓撲多樣性。

可用區(qū)：一個區(qū)域包含多個可用區(qū)，表示一個區(qū)域指定部分的云資源。

數(shù)據(jù)中心：一個可用區(qū)包含多個數(shù)據(jù)中心。一個用來放置系統(tǒng)資源(例如服務(wù)器)的指定樓層，建筑物或者建筑群。

云資源分配：

基于固定額度的資源分配，指定實例的數(shù)量，服務(wù)器的大小等。

• 根據(jù)業(yè)務(wù)特性，實際場景或者當前資源的使用情況調(diào)整分配。
• 預(yù)留容量，固定100臺的使用量，其他100臺的使用按小時計費。

基于使用量的分配，可按存儲和傳輸?shù)臄?shù)據(jù)量來計費。

各種基于云服務(wù)的應(yīng)用程序運行環(huán)境：

云服務(wù)器　　比較基礎(chǔ)的服務(wù)器技術(shù)

計算分片　　與服務(wù)器獨立的計算環(huán)境中以托管的方式運行應(yīng)用程序。 譬如google app engine

動態(tài)容器　　動態(tài)分配資源，在不同服務(wù)器中遷移容器。包裝了完整的服務(wù)器功能，提供了快速啟動停止服務(wù)以及遷移服務(wù)到新系統(tǒng)的能力。 譬如docker

微計算　　體積小，高度可擴展，基于事件驅(qū)動的運行環(huán)境。 譬如aws lambda。

?

?

?

?

?

?

?

總結(jié)

以上是生活随笔為你收集整理的可伸缩架构-面向增长应用的高可用的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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