建站
咨詢
售后
建站咨詢
新聞中心
今天我們來聊一下互聯(lián)網(wǎng)三高(高并發(fā)、高性能、高可用)中的高可用，看完本文相信能解開你關(guān)于高可用設(shè)計的大部分困惑
站在用戶的角度思考問題，與客戶深入溝通，找到蕪湖縣網(wǎng)站設(shè)計與蕪湖縣網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：網(wǎng)站建設(shè)、成都網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名注冊、網(wǎng)絡(luò)空間、企業(yè)郵箱。業(yè)務(wù)覆蓋蕪湖縣地區(qū)。
前言
高可用(High availability，即 HA)的主要目的是為了保障「業(yè)務(wù)的連續(xù)性」，即在用戶眼里，業(yè)務(wù)永遠(yuǎn)是正常(或者說基本正常)對外提供服務(wù)的。高可用主要是針對架構(gòu)而言，那么要做好高可用，就要首先設(shè)計好架構(gòu)，第一步我們一般會采用分層的思想將一個龐大的 IT 系統(tǒng)拆分成為應(yīng)用層，中間件，數(shù)據(jù)存儲層等獨立的層，每一層再拆分成為更細(xì)粒度的組件，第二步就是讓每個組件對外提供服務(wù)，畢竟每個組件都不是孤立存在的，都需要互相協(xié)作，對外提供服務(wù)才有意義。
要保證架構(gòu)的高可用，就要保證架構(gòu)中所有組件以及其對外暴露服務(wù)都要做高可用設(shè)計，任何一個組件或其服務(wù)沒做高可用，都意味著系統(tǒng)存在風(fēng)險。
那么這么多組件該怎么做高可用設(shè)計呢，其實任何組件要做高可用，都離不開「冗余」和「自動故障轉(zhuǎn)移」，眾所周知單點是高可用的大敵，所以組件一般是以集群(至少兩臺機器)的形式存在的，這樣只要某臺機器出現(xiàn)問題，集群中的其他機器就可以隨時頂替，這就是「冗余」。簡單計算一下，假設(shè)一臺機器的可用性為 90%，則兩臺機器組成的集群可用性為 1-0.1*0.1 = 99%，所以顯然冗余的機器越多，可用性越高。
但光有冗余還不夠，如果機器出現(xiàn)問題，需要人工切換的話也是費時費力，而且容易出錯，所以我們還需要借助第三方工具(即仲裁者)的力量來實現(xiàn)「自動」的故障轉(zhuǎn)移，以達(dá)到實現(xiàn)近實時的故障轉(zhuǎn)移的目的，近實時的故障轉(zhuǎn)移才是高可用的主要意義
怎樣的系統(tǒng)可以稱之為高可用呢，業(yè)界一般用幾個九來衡量系統(tǒng)的可用性，如下
|
可用性級別 |
系統(tǒng)可用性% |
宕機時間/年 |
宕機時間/月 |
宕機時間/周 |
宕機時間/天 |
|
不可用 |
90% |
36.5 天 |
73 小時 |
16.8 小時 |
144 分鐘 |
|
基本可用 |
99% |
87.6 小時 |
7.3 小時 |
1.68 小時 |
14.4 分鐘 |
|
較高可用 |
99.9% |
8.76 小時 |
43.8 分鐘 |
10.1 分鐘 |
1.44 分鐘 |
|
高可用 |
99.99% |
52.56 分鐘 |
4.38 分鐘 |
1.01 秒 |
8.64 秒 |
|
極高可用 |
99.999% |
5.26 分鐘 |
26.28 秒 |
6.06 秒 |
0.86 秒 |
一般實現(xiàn)兩個 9 很簡單，畢竟每天宕機 14 分鐘已經(jīng)嚴(yán)重影響業(yè)務(wù)了，這樣的公司遲早歇菜，大廠一般要求 4 個 9，其他要求嚴(yán)苛的業(yè)務(wù)要達(dá)到五個九以上，比如如果因為一個電腦的故障導(dǎo)致所有列車停駛，那么就會有數(shù)以萬計的人正常生活受到阻礙，這種情況就要求五個九以上
接下來我們就來一起看看架構(gòu)中的各個組件如何借助「冗余」和「自動故障轉(zhuǎn)移」來實現(xiàn)高可用。
互聯(lián)網(wǎng)架構(gòu)剖析
目前多數(shù)互聯(lián)網(wǎng)都會采用微服務(wù)架構(gòu)，常見架構(gòu)如下:
可以看到架構(gòu)主要分以下幾層
- 接入層：主要由 F5 硬件或 LVS 軟件來承載所有的流量入口
- 反向代理層：Nginx，主要負(fù)責(zé)根據(jù) url 來分發(fā)流量，限流等
- 網(wǎng)關(guān)：主要負(fù)責(zé)流控，風(fēng)控，協(xié)議轉(zhuǎn)換等
- 站點層：主要負(fù)責(zé)調(diào)用會員，促銷等基本服務(wù)來裝配 json 等數(shù)據(jù)并返回給客戶端
- 基礎(chǔ) service：其實與站點層都屬于微服務(wù)，是平級關(guān)系，只不過基礎(chǔ) service 屬于基礎(chǔ)設(shè)施，能被上層的各個業(yè)務(wù)層 server 調(diào)用而已
- 存儲層：也就是 DB，如 MySQL，Oracle 等，一般由基礎(chǔ) service 調(diào)用返回給站點層
- 中間件：ZK，ES，Redis，MQ 等，主要起到加速訪問數(shù)據(jù)等功能，在下文中我們會簡單介紹下各個組件的作用
如前所述，要實現(xiàn)整體架構(gòu)的高可用，必須要實現(xiàn)每一層組件的高可用，接下來我們就來分別看一下每一層的組件都是如何實現(xiàn)高可用的
接入層&反向代理層
這兩層的高可用都和 keepalived 有關(guān)，所以我們結(jié)合起來一起看
對外，兩個 LVS 以主備的形式對外提供服務(wù)，注意只有 master 在工作(即此時的 VIP 在 master 上生效)，另外一個 backup 在 master 宕機之后會接管 master 的工作，那么 backup 怎么知道 master 是否正常呢，答案是通過 keepalived，在主備機器上都裝上 keepalived 軟件，啟動后就會通過心跳檢測彼此的健康狀況，一旦 master 宕機，keepalived 會檢測到，從而 backup 自動轉(zhuǎn)成 master 對外提供服務(wù)，此時 VIP 地址(即圖中的 115.204.94.139)即在 backup 上生效，也就是我們常說的「IP漂移」，通過這樣的方式即解決了 LVS 的高可用。
keepalived 的心跳檢測主要通過發(fā)送 ICMP 報文，或者利用 TCP 的端口連接和掃描檢測來檢測的，同樣的，它也可以用來檢測 Nginx 暴露的端口，這樣的話如果某些 Nginx 不正常 Keepalived 也能檢測到并將其從 LVS 能轉(zhuǎn)發(fā)的服務(wù)列表中剔出。
借用 keepalived 這個第三方工具，同時實現(xiàn)了 LVS 和 Nginx 的高可用，同時在出現(xiàn)故障時也可以將宕機情況發(fā)送到對應(yīng)開發(fā)人員的郵箱以讓他們及時收到通知處理，確實很方便，Keepalived 應(yīng)用廣泛，下文我們會看到它也可以用在 MySQL 上來實現(xiàn) MySQL 的高可用。
微服務(wù)
接下來我們再來看一下「網(wǎng)關(guān)」，「站點層」,「基礎(chǔ)服務(wù)層」，這三者一般就是我們所說的微服務(wù)架構(gòu)組件，當(dāng)然這些微服務(wù)組件還需要通過一些 RPC 框架如 Dubbo 來支撐才能通信，所以微服務(wù)要實現(xiàn)高可用，就意味著 dubbo 這些 RPC 框架也要提供支撐微服務(wù)高可用的能力，我們就以 dubbo 為例來看下它是如何實現(xiàn)高可用的
我們先來簡單地看下 dubbo 的基本架構(gòu)
思路也很簡單，首先是 Provider(服務(wù)提供者)向 Registry(注冊中心，如 ZK 或 Nacos 等)注冊服務(wù)，然后 Consumer(服務(wù)消費者)向注冊中心訂閱和拉取 Provider 服務(wù)列表，獲取服務(wù)列表后，Consumer 就可以根據(jù)其負(fù)載均衡策略選擇其中一個 Provider 來向其發(fā)出請求，當(dāng)其中某個 Provider 不可用(下線或者因為 GC 阻塞等)時，會被注冊中心及時監(jiān)聽(通過心跳機制)到，也會及時推送給 Consumer，這樣 Consumer 就能將其從可用的 Provider 列表中剔除，也就實現(xiàn)了故障的自動轉(zhuǎn)移，不難看出，注冊中心就起到了類似 keepalived 的作用
中間件
我們再來看下這些中間件如 ZK，Redis 等是如何實現(xiàn)高可用的呢
ZK
上一節(jié)微服務(wù)中我們提到了注冊中心，那我們就以 ZK(ZooKeeper)為例來看看它的高可用是如何實現(xiàn)的，先來看下它的整體架構(gòu)圖如下
Zookeeper 中的主要角色如下
- Leader: 即領(lǐng)導(dǎo)者，在集群中只有一個 Leader，主要承擔(dān)了以下的功能
事務(wù)請求的唯一調(diào)度和處理者，保證集群事務(wù)處理的順序性，所有 Follower 的寫請求都會轉(zhuǎn)給 Leader 執(zhí)行，用來保證事務(wù)的一致性
集群內(nèi)部各服務(wù)器的調(diào)度者：處理好事務(wù)請求后，會將數(shù)據(jù)廣播同步到各個 Follower，統(tǒng)計 Follower 寫入成功的數(shù)量，超過半數(shù) Follower 寫入成功，Leader 就會認(rèn)為寫請求提交成功，通知所有的 Follower commit 這個寫操作，保證事后哪怕是集群崩潰恢復(fù)或者重啟，這個寫操作也不會丟失。
- Follower:
處理客戶端非事務(wù)請求、轉(zhuǎn)發(fā)事務(wù)請求給 leader 服務(wù)器
參與事物請求 Proposal 的投票(需要半數(shù)以上服務(wù)器通過才能通知 leader commit 數(shù)據(jù); Leader 發(fā)起的提案，要求 Follower 投票)
參與 Leader 選舉的投票
畫外音：Zookeeper 3.0 之后新增了一種 Observer 的角色，不過與此處討論的 ZK 高可用關(guān)系不是很大，為了簡化問題，所以省略
可以看到由于只有一個 Leader，很顯然，此 Leader 存在單點隱患，那么 ZK 是怎么解決此問題的呢，首先 Follower 與 Leader 會用心跳機制保持連接，如果 Leader 出現(xiàn)問題了(宕機或者因為 FullGC 等原因無法響應(yīng))，F(xiàn)ollower 就無法感知到 Leader 的心跳，就會認(rèn)為 Leader 出問題了，于是它們就會發(fā)起投票選舉，最終在多個 Follower 中選出一個 Leader 來(這里主要用到了 Zookeeper Atomic Broadcast，即 ZAB 協(xié)議，它是為 ZK 專門設(shè)計的一種支持崩潰恢復(fù)的一致性協(xié)議)，選舉的細(xì)節(jié)不是本文重點，就不在此詳述了。
除了 ZAB 協(xié)議，業(yè)界上常用的還有 Paxos，Raft 等協(xié)議算法，也可以用在 Leader 選舉上，也就是是在分布式架構(gòu)中，這些協(xié)議算法承擔(dān)了“第三者”也就是仲裁者的作用，以承擔(dān)故障的自動轉(zhuǎn)移
Redis
Redis 的高可用需要根據(jù)它的部署模式來看看，主要分為「主從模式」和「Cluster 分片模式」兩種
主從模式
先來看一下主從模式，架構(gòu)如下
主從模式
主從模式即一主多從(一個或者多個從節(jié)點)，其中主節(jié)點主要負(fù)責(zé)讀和寫，然后會將數(shù)據(jù)同步到多個從節(jié)點上，Client 也可以對多個從節(jié)點發(fā)起讀請求，這樣可以減輕主節(jié)點的壓力，但和 ZK 一樣，由于只有一個主節(jié)點，存在單點隱患，所以必須引入第三方仲裁者的機制來判定主節(jié)點是否宕機以及在判定主節(jié)點宕機后快速選出某個從節(jié)點來充當(dāng)主節(jié)點的角色，這個第三方仲裁者在 Redis 中我們一般稱其為「哨兵」(sentinel)，當(dāng)然哨兵進(jìn)程本身也有可能掛掉，所以為了安全起見，需要部署多個哨兵(即哨兵集群)
哨兵集群
這些哨兵通過 gossip(流言) 協(xié)議來接收關(guān)于主服務(wù)器是否下線的信息，并在判定主節(jié)點宕機后使用 Raft 協(xié)議來選舉出新的主節(jié)點
Cluster 分片集群
主從模式看似完美，但存在以下幾個問題
主節(jié)點寫的壓力難以降低：因為只有一個主節(jié)點能接收寫請求，如果在高并發(fā)的情況下，寫請求如果很高的話可能會把主節(jié)點的網(wǎng)卡打滿，造成主節(jié)點對外無法服務(wù)
主節(jié)點的存儲能力受到單機存儲容量的限制：因為不管是主節(jié)點還是從節(jié)點，存儲的都是全量緩存數(shù)據(jù)，那么隨著業(yè)務(wù)量的增長，緩存數(shù)據(jù)很可能直線上升，直到達(dá)到存儲瓶頸
同步風(fēng)暴：因為數(shù)據(jù)都是從 master 同步到 slave 的，如果有多個從節(jié)點的話，master 節(jié)點的壓力會很大
為了解決主從模式的以上問題，分片集群應(yīng)運而生，所謂分片集群即將數(shù)據(jù)分片，每一個分片數(shù)據(jù)由相應(yīng)的主節(jié)點負(fù)責(zé)讀寫，這樣的話就有多個主節(jié)點來分擔(dān)寫的壓力，并且每個節(jié)點只存儲部分?jǐn)?shù)據(jù)，也就解決了單機存儲瓶頸的問題，但需要注意的是每個主節(jié)點都存在單點問題，所以需要針對每個主節(jié)點做高可用，整體架構(gòu)如下
原理也很簡單，在 Proxy 收到 client 執(zhí)行的 redis 的讀寫命令后，首先會對 key 進(jìn)行計算得出一個值，如果這個值落在相應(yīng) master 負(fù)責(zé)的數(shù)值范圍(一般將每個數(shù)字稱為槽，Redis 一共有 16384 個槽)之內(nèi)，那就把這條 redis 命令發(fā)給對應(yīng)的 master 去執(zhí)行，可以看到每個 master 節(jié)點只負(fù)責(zé)處理一部分的 redis 數(shù)據(jù)，同時為了避免每個 master 的單點問題，也為其配備了多個從節(jié)點以組成集群，當(dāng)主節(jié)點宕機時，集群會通過 Raft 算法來從從節(jié)點中選舉出一個主節(jié)點
ES
再來看一下 ES 是如何實現(xiàn)高可用的，在 ES 中，數(shù)據(jù)是以分片(Shard)的形式存在的，如下圖所示，一個節(jié)點中索引數(shù)據(jù)共分為三個分片存儲
但只有一個節(jié)點的話，顯然存在和 Redis 的主從架構(gòu)一樣的單點問題，這個節(jié)點掛了，ES 也就掛了，所以顯然需要創(chuàng)建多個節(jié)點
一旦創(chuàng)建了多個節(jié)點，分片(圖中 P 為主分片，R 為副本分片)的優(yōu)勢就體現(xiàn)出來了，可以將分片數(shù)據(jù)分布式存儲到其它節(jié)點上，極大提升了數(shù)據(jù)的水平擴展能力，同時每個節(jié)點都能承擔(dān)讀寫請求，采用負(fù)載均衡的形式避免了單點的讀寫壓力
ES 的寫機制與 Redis 和 MySQL 的主從架構(gòu)有些差別(后兩者的寫都是直接向 master 節(jié)點發(fā)起寫請求，而 ES 則不是)，所以這里稍微解釋一下 ES 的工作原理
首先說下節(jié)點的工作機制，節(jié)點(Node)分為主節(jié)點(Master Node)和從結(jié)點(Slave Node)，主節(jié)點的主要職責(zé)是負(fù)責(zé)集群層面的相關(guān)操作，管理集群變更，如創(chuàng)建或刪除索引，跟蹤哪些節(jié)點是集群的一部分，并決定哪些分片分配給相關(guān)的節(jié)點，主節(jié)點也只有一個，一般通過類 Bully 算法來選舉出來，如果主節(jié)點不可用了，則其他從節(jié)點也可以通過此算法來選舉以實現(xiàn)集群的高可用，任何節(jié)點都可以接收讀寫請求以達(dá)到負(fù)載均衡的目的
再說一下分片的工作原理，分片分為主分片(Primary Shard，即圖中 P0，P1，P2)和副本分片(Replica Shard，即圖中 R0，R1，R2)，主分片負(fù)責(zé)數(shù)據(jù)的寫操作，所以雖然任何節(jié)點可以接收讀寫請求，但如果此節(jié)點接收的是寫請求并且沒有寫數(shù)據(jù)所在的主分片話，此節(jié)點會將寫請求調(diào)度到主分片所在的節(jié)點上，寫入主分片后，主分片再把數(shù)據(jù)復(fù)制到其他節(jié)點的副本分片上，以有兩個副本的集群為例，寫操作如下
MQ
ES 利用數(shù)據(jù)分片來提升高可用和水平擴展能力的思想也應(yīng)用在其他組件的架構(gòu)設(shè)計上，我們以 MQ 中的 Kafka 為例再來看下數(shù)據(jù)分片的應(yīng)用
Kafka 高可用設(shè)計》
如上是 Kafka 集群，可以看到每個 Topic 的 Partition 都分布式存儲在其它消息服務(wù)器上，這樣一旦某個 Partition 不可用，可以從 follower 中選舉出 leader 繼續(xù)服務(wù)，不過與 ES 中的數(shù)據(jù)分片不同的是，follower Partition 屬于冷備，也就是說在正常情況下不會對外服務(wù)，只有在 leader 掛掉之后從 follower 中選舉出 leader 后它才能對外提供服務(wù)
存儲層
接下來我們再來看一下最后一層，存儲層(DB)，這里我們以 MySQL 為例來簡單地討論一下其高可用設(shè)計，其實大家如果看完了以上的高可用設(shè)計，會發(fā)現(xiàn) MySQL 的高可用也不過如此，思想都是類似的，與 Redis 類似，它也分主從和分片(即我們常說的分庫分表)兩種架構(gòu)
主從的話與 LVS 類似，一般使用 keepalived 的形式來實現(xiàn)高可用，如下所示
如果 master 宕機了，Keepalived 也會及時發(fā)現(xiàn)，于是從庫會升級主庫，并且 VIP 也會“漂移”到原從庫上生效，所以說大家在工程配置的 MySQL 地址一般是 VIP 以保證高可用
數(shù)據(jù)量大了之后就要分庫分表了，于是就有了多主，就像 Redis 的分片集群一樣，需要針對每個主配備多個從，如下
之前有讀者問分庫分表之后為啥還要做主從，現(xiàn)在我想大家應(yīng)該都明白了，不是為了解決讀寫性能問題，主要是為了實現(xiàn)高可用
總結(jié)
看完了架構(gòu)層面的高可用設(shè)計，相信大家對高可用的核心思想「冗余」和「自動故障轉(zhuǎn)移」會有更深刻的體會，觀察以上架構(gòu)中的組件你會發(fā)現(xiàn)冗余的主要原因是因為只有一主，為什么不能有多主呢，也不是不可以，但這樣在分布式系統(tǒng)下要保證數(shù)據(jù)的一致性是非常困難的，尤其是節(jié)點多了的話，數(shù)據(jù)之間的同步更是一大難題，所以多數(shù)組件采用一主的形式，然后再在主和多從之間同步，多數(shù)組件之所以選擇一主本質(zhì)上是技術(shù)上的 tradeoff
那么做好每個組件的高可用之后是否整個架構(gòu)就真的可用了呢，非也，這只能說邁出了第一步，在生產(chǎn)上還有很多突發(fā)情況會讓我們的系統(tǒng)面臨挑戰(zhàn)，比如
- 瞬時流量問題：比如我們可能會面臨秒殺帶來的瞬時流量激增導(dǎo)致系統(tǒng)的承載能力被壓垮，這種情況可能影響日常交易等核心鏈路，所以需要做到系統(tǒng)之間的隔離，如單獨為秒殺部署一套獨立的集群
- 安全問題：比如 DDOS 攻擊，爬蟲頻繁請求甚至刪庫跑路等導(dǎo)致系統(tǒng)拒絕服務(wù)
- 代碼問題：比如代碼 bug 引起內(nèi)存泄露導(dǎo)致 FullGC 導(dǎo)致系統(tǒng)無法響應(yīng)等
- 部署問題：在發(fā)布過程中如果貿(mào)然中止當(dāng)前正在運行的服務(wù)也是不行的，需要做到優(yōu)雅停機，平滑發(fā)布
- 第三方問題：比如我們之前的服務(wù)依賴第三方系統(tǒng)，第三方可能出問題導(dǎo)致影響我們的核心業(yè)務(wù)
- 不可抗力：如機房斷電，所以需要做好容災(zāi)，異地多活，之前我司業(yè)務(wù)就由于機房故障導(dǎo)致服務(wù)四小時不可用，損失慘重
所以除了做好架構(gòu)的高可用之外，我們還需要在做好系統(tǒng)隔離，限流，熔斷，風(fēng)控，降級，對關(guān)鍵操作限制操作人權(quán)限等措施以保證系統(tǒng)的可用。
這里特別提一下降級，這是為了保證系統(tǒng)可用性采取的常用的措施，簡單舉幾個例子
- 我們之前對接過一個第三方資金方由于自身原因借款功能出了問題導(dǎo)致無法借款，這種情況為了避免引起用戶恐慌，于是我們在用戶申請第三方借款的時候返回了一個類似「為了提升你的額度，資金方正在系統(tǒng)升級」這樣的文案，避免了客訴
- 在流媒體領(lǐng)域，當(dāng)用戶觀看直播出現(xiàn)嚴(yán)重卡頓時，很多企業(yè)的第一選擇不是查 log 排查問題，而是為用戶自動降碼率。因為比起畫質(zhì)降低，卡得看不了顯然會讓用戶更痛苦
- 雙十一零點高峰期，我們把用戶的注冊登錄等非核心功能給停掉了，以保證下單等核心流程的順利
另外我們最好能做到事前防御，在系統(tǒng)出問題前把它扼殺在搖籃里，所以我們需要做單元測試，做全鏈路壓測等來發(fā)現(xiàn)問題，還需要針對 CPU，線程數(shù)等做好監(jiān)控，當(dāng)其達(dá)到我們設(shè)定的域值時就觸發(fā)告警以讓我們及時發(fā)現(xiàn)修復(fù)問題(我司之前就碰到過一個類似的生產(chǎn)事故復(fù)盤大家可以看一下)，此外在做好單元測試的前提下，依然有可能因為代碼的潛在 bug 引起線上問題，所以我們需要在關(guān)鍵時間(比如雙十一期間)封網(wǎng)(也就是不讓發(fā)布代碼)
此外我們還需要在出事后能快速定位問題，快速回滾，這就需要記錄每一次的發(fā)布時間，發(fā)布人等，這里的發(fā)布不僅包括工程的發(fā)布，還包括配置中心等的發(fā)布
畫外音：上圖是我司的發(fā)布記錄，可以看到有代碼變更，回滾等，這樣如果發(fā)現(xiàn)有問題的話可以一鍵回滾
最后我們以一張圖來總結(jié)一下高可用的常見手段
網(wǎng)站名稱：你管這破玩意兒叫高可用
文章來源：http://fisionsoft.com.cn/article/cdehpdo.html
