前言
后臺服務(wù)可以劃分為兩類(lèi)，有狀態(tài)和無(wú)狀態(tài)。高可用對于無(wú)狀態(tài)的應用來(lái)說(shuō)是比較簡(jiǎn)單的，無(wú)狀態(tài)的應用，只需要通過(guò) F5 或者任何代理的方式就可以很好的解決。后文描述的主要是針對有狀態(tài)的服務(wù)進(jìn)行分析。服務(wù)端進(jìn)行狀態(tài)維護主要是通過(guò)磁盤(pán)或內存進(jìn)行保存，比如 MySQL 數據庫，redis 等內存數據庫。除了這兩種類(lèi)型的維護方式，還有 jvm 的內存的狀態(tài)維持，但jvm的狀態(tài)生命周期通常很短。
高可用
1、高可用的一些解決方案
高可用，從發(fā)展來(lái)看，大致經(jīng)過(guò)了這幾個(gè)過(guò)程：
在聊異地多活的時(shí)候，還是先看一些其他的方案，這有利于我們理解很多設計的緣由。
冷備
冷備，通過(guò)停止數據庫對外服務(wù)的能力，通過(guò)文件拷貝的方式將數據快速進(jìn)行備份歸檔的操作方式。簡(jiǎn)而言之，冷備，就是復制粘貼，在 linux 上通過(guò) cp 命令就可以很快完成?？梢酝ㄟ^(guò)人為操作，或者定時(shí)腳本進(jìn)行。有如下好處：
以上的好處，對于以前的軟件來(lái)說(shuō)，是很好的方式。但是對于現如今的很多場(chǎng)景，已經(jīng)不好用了，因為：
- 服務(wù)需要停機。n個(gè)9肯定無(wú)法做到了。然后，以前我們的停機冷備是在凌晨沒(méi)有人使用的時(shí)候進(jìn)行，但是現在很多的互聯(lián)網(wǎng)應用已經(jīng)是面向全球了，所以，任何時(shí)候都是有人在使用的。
- 數據丟失。如果不采取措施，那么在完成了數據恢復后，備份時(shí)間點(diǎn)到還原時(shí)間內的數據會(huì )丟失。傳統的做法，是冷備還原以后，通過(guò)數據庫日志手動(dòng)恢復數據。比如通過(guò) redo日志，更甚者，我還曾經(jīng)通過(guò)業(yè)務(wù)日志去手動(dòng)回放請求恢復數據?；謴褪菢O大的體力活，錯誤率高，恢復時(shí)間長(cháng)。
- 冷備是全量備份。全量備份會(huì )造成磁盤(pán)空間浪費，以及容量不足的問(wèn)題，只能通過(guò)將備份拷貝到其他移動(dòng)設備上解決。所以，整個(gè)備份過(guò)程的時(shí)間其實(shí)更長(cháng)了。
- 想象一下每天拷貝幾個(gè)T的數據到移動(dòng)硬盤(pán)上，需要多少移動(dòng)硬盤(pán)和時(shí)間。并且，全量備份是無(wú)法定制化的，比如只備份某一些表，是無(wú)法做到的。
如何權衡冷備的利弊，是每個(gè)業(yè)務(wù)需要考慮的。
雙機熱備
熱備，和冷備比起來(lái)，主要的差別是不用停機，一邊備份一邊提供服務(wù)。但還原的時(shí)候還是需要停機的。由于我們討論的是和存儲相關(guān)的，所以不將共享磁盤(pán)的方式看作雙機熱備。
Active/Standby模式
相當于1主1從，主節點(diǎn)對外提供服務(wù)，從節點(diǎn)作為backup。通過(guò)一些手段將數據從主節點(diǎn)同步到從節點(diǎn)，當故障發(fā)生時(shí)，將從節點(diǎn)設置為工作節點(diǎn)。數據同步的方式可以是偏軟件層面，也可以是偏硬件層面的。偏軟件層面的，比如mysql的master/slave方式，通過(guò)同步binlog的方式；sqlserver的訂閱復制方式。偏硬件層面，通過(guò)扇區和磁盤(pán)的攔截等鏡像技術(shù)，將數據拷貝到另外的磁盤(pán)。偏硬件的方式，也被叫做數據級災備；偏軟件的，被叫做應用級災備。后文談得更多的是應用級災備。
雙機互備
本質(zhì)上還是Active/Standby，只是互為主從而已。雙機互備并不能工作于同一個(gè)業(yè)務(wù)，只是在服務(wù)器角度來(lái)看，更好的壓榨了可用的資源。比如，兩個(gè)業(yè)務(wù)分別有庫A和B，通過(guò)兩個(gè)機器P和Q進(jìn)行部署。那么對于A(yíng)業(yè)務(wù)，P主Q從，對于B業(yè)務(wù)，Q主P從。整體上看起來(lái)是兩個(gè)機器互為主備。這種架構下，讀寫(xiě)分離是很好的，單寫(xiě)多讀，減少沖突又提高了效率。
其他的高可用方案還可以參考各類(lèi)數據庫的多種部署模式，比如mysql的主從、雙主多從、MHA；redis 的主從，哨兵，cluster 等等。
同城雙活
前面講到的幾種方案，基本都是在一個(gè)局域網(wǎng)內進(jìn)行的。業(yè)務(wù)發(fā)展到后面，有了同城多活的方案。和前面比起來(lái)，不信任的粒度從機器轉為了機房。這種方案可以解決某個(gè)IDC機房整體掛掉的情況（停電，斷網(wǎng)等）。
同城雙活其實(shí)和前文提到的雙機熱備沒(méi)有本質(zhì)的區別，只是“距離”更遠了，基本上還是一樣（同城專(zhuān)線(xiàn)網(wǎng)速還是很快的）。雙機熱備提供了災備能力，雙機互備避免了過(guò)多的資源浪費。
在程序代碼的輔助下，有的業(yè)務(wù)還可以做到真正的雙活，即同一個(gè)業(yè)務(wù)，雙主，同時(shí)提供讀寫(xiě)，只要處理好沖突的問(wèn)題即可。需要注意的是，并不是所有的業(yè)務(wù)都能做到。
業(yè)界更多采用的是兩地三中心的做法。遠端的備份機房能更大的提供災備能力，能更好的抵抗地震，恐襲等情況。雙活的機器必須部署到同城，距離更遠的城市作為災備機房。災備機房是不對外提供服務(wù)的，只作為備份使用，發(fā)生故障了才切流量到災備機房；或者是只作為數據備份。原因主要在于：距離太遠，網(wǎng)絡(luò )延遲太大。
如上圖，用戶(hù)流量通過(guò)負載均衡，將服務(wù)A的流量發(fā)送到IDC1，服務(wù)器集A；將服務(wù)B的流量發(fā)送到IDC2，服務(wù)器B；同時(shí)，服務(wù)器集a和b分別從A和B進(jìn)行同城專(zhuān)線(xiàn)的數據同步，并且通過(guò)長(cháng)距離的異地專(zhuān)線(xiàn)往IDC3進(jìn)行同步。當任何一個(gè)IDC當機時(shí)，將所有流量切到同城的另一個(gè)IDC機房，完成了failover。
當城市1發(fā)生大面積故障時(shí)，比如發(fā)生地震導致IDC1和2同時(shí)停止工作，則數據在IDC3得以保全。同時(shí)，如果負載均衡仍然有效，也可以將流量全部轉發(fā)到IDC3中。不過(guò)，此時(shí)IDC3機房的距離非常遠，網(wǎng)絡(luò )延遲變得很?chē)乐?，通常用?hù)的體驗的會(huì )受到嚴重影響的。
上圖是一種基于Master-Slave模式的兩地三中心示意圖。城市1中的兩個(gè)機房作為1主1從，異地機房作為從。也可以采用同城雙主+keepalived+vip的方式，或者M(jìn)HA的方式進(jìn)行failover。但城市2不能（最好不要）被選擇為Master。
3、異地雙活
同城雙活可以應對大部分的災備情況，但是碰到大面積停電，或者自然災害的時(shí)候，服務(wù)依然會(huì )中斷。對上面的兩地三中心進(jìn)行改造，在異地也部署前端入口節點(diǎn)和應用，在城市1停止服務(wù)后將流量切到城市2，可以在降低用戶(hù)體驗的情況下，進(jìn)行降級。但用戶(hù)的體驗下降程度非常大。所以大多數的互聯(lián)網(wǎng)公司采用了異地雙活的方案。上圖是一個(gè)簡(jiǎn)單的異地雙活的示意圖。流量經(jīng)過(guò)LB后分發(fā)到兩個(gè)城市的服務(wù)器集群中，服務(wù)器集群只連接本地的數據庫集群，只有當本地的所有數據庫集群均不能訪(fǎng)問(wèn)，才failover到異地的數據庫集群中。在這種方式下，由于異地網(wǎng)絡(luò )問(wèn)題，雙向同步需要花費更多的時(shí)間。更長(cháng)的同步時(shí)間將會(huì )導致更加嚴重的吞吐量下降，或者出現數據沖突的情況。吞吐量和沖突是兩個(gè)對立的問(wèn)題，你需要在其中進(jìn)行權衡。例如，為了解決沖突，引入分布式鎖/分布式事務(wù)；為了解決達到更高的吞吐量，利用中間狀態(tài)、錯誤重試等手段，達到最終一致性；降低沖突，將數據進(jìn)行恰當的sharding，盡可能在一個(gè)節點(diǎn)中完成整個(gè)事務(wù)。對于一些無(wú)法接受最終一致性的業(yè)務(wù)，餓了么采用的是下圖的方式：
對于個(gè)別一致性要求很高的應用，我們提供了一種強一致的方案（Global Zone），Globa Zone是一種跨機房的讀寫(xiě)分離機制，所有的寫(xiě)操作被定向到一個(gè) Master 機房進(jìn)行，以保證一致性，讀操作可以在每個(gè)機房的 Slave庫執行，也可以 bind 到 Master 機房進(jìn)行，這一切都基于我們的數據庫訪(fǎng)問(wèn)層（DAL）完成，業(yè)務(wù)基本無(wú)感知。——《餓了么異地多活技術(shù)實(shí)現（一）總體介紹》
也就是說(shuō)，在這個(gè)區域是不能進(jìn)行雙活的。采用主從而不是雙寫(xiě)，自然解決了沖突的問(wèn)題。實(shí)際上，異地雙活和異地多活已經(jīng)很像了，雙活的結構更為簡(jiǎn)單，所以在程序架構上不用做過(guò)多的考慮，只需要做傳統的限流，failover等操作即可。但其實(shí)雙活只是一個(gè)臨時(shí)的步驟，最終的目的是切換到多活。因為雙活除了有數據沖突上的問(wèn)題意外，還無(wú)法進(jìn)行橫向擴展。
異地多活
根據異地雙活的思路，我們可以畫(huà)出異地多活的一種示意圖。每個(gè)節點(diǎn)的出度和入度都是4，在這種情況下，任何節點(diǎn)下線(xiàn)都不會(huì )對業(yè)務(wù)有影響。但是，考慮到距離的問(wèn)題，一次寫(xiě)操作將帶來(lái)更大的時(shí)間開(kāi)銷(xiāo)。時(shí)間開(kāi)銷(xiāo)除了影響用戶(hù)體驗以外，還帶來(lái)了更多的數據沖突。在嚴重的數據沖突下，使用分布式鎖的代價(jià)也更大。這將導致系統的復雜度上升，吞吐量下降。所以上圖的方案是無(wú)法使用的。回憶一下我們在解決網(wǎng)狀網(wǎng)絡(luò )拓撲的時(shí)候是怎么優(yōu)化的？引入中間節點(diǎn)，將網(wǎng)狀改為星狀：改造為上圖后，每個(gè)城市下線(xiàn)都不會(huì )對數據造成影響。對于原有請求城市的流量，會(huì )被重新 LoadBalance 到新的節點(diǎn)（最好是LB到最近的城市）。為了解決數據安全的問(wèn)題，我們只需要針對中心節點(diǎn)進(jìn)行處理即可。但是這樣，對于中心城市的要求，比其他城市會(huì )更高。比如恢復速度，備份完整性等，這里暫時(shí)不展開(kāi)。我們先假定中心是完全安全的。如果我們已經(jīng)將異地多活的業(yè)務(wù)部署為上圖的結構，很大程度解決了數據到處同步的問(wèn)題，不過(guò)依然會(huì )存在大量的沖突，沖突的情況可以簡(jiǎn)單認為和雙活差不多。那么還有沒(méi)有更好的方式呢？這里可以關(guān)聯(lián)一下餓了么的 GlobalZone 方案，總體思路就是“去分布式”，也就是說(shuō)將寫(xiě)的業(yè)務(wù)放到一個(gè)節點(diǎn)的（同城）機器上。阿里是這么思考的：實(shí)際上我猜測很多業(yè)務(wù)也是按照上圖去實(shí)現的，比如滴滴打車(chē)業(yè)務(wù)這種，所有的業(yè)務(wù)都是按城市劃分開(kāi)的。用戶(hù)、車(chē)主、目的地，他們的經(jīng)緯度通常都是在同一個(gè)城市的。單個(gè)數據中心并不需要和其他數據中心進(jìn)行數據交互，只有在統計出報表的時(shí)候才需要，但報表是不太注重實(shí)時(shí)性的。那么，在這種情況下，全國的業(yè)務(wù)其實(shí)可以被很好的sharding的。但是對于電商這種復雜的場(chǎng)景和業(yè)務(wù)，按照前文說(shuō)的方式進(jìn)行sharding已經(jīng)無(wú)法滿(mǎn)足需求了。因為業(yè)務(wù)線(xiàn)非常復雜，數據依賴(lài)也非常復雜，每個(gè)數據中心相互進(jìn)行數據同步的情況無(wú)可避免。淘寶的解決方式和我們切分微服務(wù)的方式有點(diǎn)類(lèi)似：注意看圖中的數據同步箭頭。以交易單元為例，屬于交易單元的業(yè)務(wù)數據，將與中心單元進(jìn)行雙向同步；不屬于交易單元的業(yè)務(wù)數據，單向從中心單元同步。中心單元承擔了最復雜的業(yè)務(wù)場(chǎng)景，業(yè)務(wù)單元承擔了相對單一的場(chǎng)景。對于業(yè)務(wù)單元，可以進(jìn)行彈性伸縮和容災；對于中心單元，擴展能力較差，穩定性要求更高?？梢杂鲆?jiàn)，大部分的故障都會(huì )出現在中心單元。按照業(yè)務(wù)進(jìn)行單元切分，已經(jīng)需要對代碼和架構進(jìn)行徹底的改造了（可能這也是為什么阿里要先從雙活再切到多活，歷時(shí)3年）。比如，業(yè)務(wù)拆分，依賴(lài)拆分，網(wǎng)狀改星狀，分布式事務(wù)，緩存失效等。除了對于編碼的要求很高以外，對測試和運維也有非常大的挑戰。如此復雜的情況，如何進(jìn)行自動(dòng)化覆蓋，如何進(jìn)行演練，如何改造流水線(xiàn)。這種級別的災備，不是一般公司敢做的，投入產(chǎn)出也不成正比。不過(guò)還是可以把這種場(chǎng)景當作我們的“假想敵”，去思考我們自己的業(yè)務(wù)，未來(lái)會(huì )怎么發(fā)展，需要做到什么級別的災備。相對而言，餓了么的多活方案可能更適合大多數的企業(yè)。本文只是通過(guò)畫(huà)圖的方式進(jìn)行了簡(jiǎn)單的描述，其實(shí)異地多活是需要很多很強大的基礎能力的。比如，數據傳輸，數據校驗，數據操作層（簡(jiǎn)化客戶(hù)端控制寫(xiě)和同步的過(guò)程）等。
