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