想要多活又心疼錢？咋不瞧瞧青云的真正多活呢？

來源：DOIT 作者：朱朋博

太陽每天照常升起，如果哪天太陽也出了故障，跟往常不一樣了，那絕對是世界級大新聞，首先得慶幸這樣的事情通常只會出現在科幻電影里。

Github是程序員的世界里類似的存在。2015年的統計數字顯示，Github托管了5700萬個代碼倉庫，有2800萬個用戶活躍在Github上，Github的用戶對故障不陌生，每次Github出故障都能引起一番熱議。最近一次故障中，Github的中斷持續了24小時，用戶無法提交代碼更新，也沒辦法從Github下載最新版本的代碼，正常的工作節奏完全被打亂了。

“星軌”可能是中國互聯網服務商創造的新名詞，說是新浪微博衡量服務器抗壓能力的新單位，一星軌表示一個一線明星出軌給新浪微博所帶來的流量，據說微博的服務器現在能同時抗擊8星軌，類似的描述常見于描述樓梯的抗八級地震一樣。不久前的“官宣”事件又一次突破了新浪微博服務器的承重，服務部分中斷了，廣大網友把官宣玩壞了，也順帶把新浪微博的技術人員又嚇了一跳。

說了這么多，就只是想說，故障，宕機什么的，離我們普通人真的很近，這些上了新聞的只是其中一少部分，更多故障宕機之類的事件廣大網友根本察覺不到，系統就被修復到能對外服務了，這類專門應對故障宕機的系統常見的就有多活系統。

多活系統通常是為了增強系統的可靠性、業務的連續性，使用業務運行不受故障/災難影響。

Github也搭建了多活系統，結果多活系統出了故障。Github的兩個機房的網絡出現中斷，服務發生切換中由于多活系統考慮不全，導致系統發生腦裂，兩個機房的數據不一致。為了保證用戶數據的一致性不得不停服，24小時之后數據才得以恢復。青云QingCloud運營副總裁林源向筆者介紹說。

故障之后多活系統就開始發揮作用了，評價多活水平的是RTO和RPO。RTO是指業務恢復時間，就好比玩游戲時卡的時候到恢復的時間段，游戲時最常見的應該是網絡故障。RPO表示故障丟失的數據量，剛才完成的操作系統給丟了，比如你買了裝備，一轉眼故障后裝備沒了錢也沒了，也可能是你擊殺了別的玩家，一眨眼回來顯示你輸了。

玩游戲還好，要是偶爾銀行故障的RTO、RPO的水平低了，也來這么一回，那事情可就大了。

雙活雖然好，但是貴，建造也麻煩，好在不是誰都需要雙活，比如你手里的手機偶爾莫名重啟一下，那沒啥事兒。

要是雙十一的時候，明明零點搶到了特價iPhoneX MAX，一眨眼，錢也付了，訂單丟了，店家說看不見，你說你付了錢，那不得哭啊。要是雙十一的時候，下單的按鈕始終點不了，錢一直付不了，每秒幾十萬、幾百萬、幾千萬訂單額的商家不得哭暈在廁所嗎？

要是銀行的大型機也莫名其妙的重啟了，那叫超級大事故，經濟秩序可能就亂掉了。銀行、保險、重型制造、電力等涉及國計民生的業務系統如果出現不可恢復的故障，那后果真實不堪設想。所以，這些場景要求數據不能丟。

林源介紹說，像銀行的IT架構都需要符合銀監會的規定，需要有兩地三中心。所謂兩地三中心，兩地是指兩個城市，三中心是指三個數據中心。同城的數據中心相互間是雙活系統，異地的一個數據中心則主要負責備份，以此保障數據的安全性，業務的連續性。

兩地三中心固然好，缺點就是貴。

前期投入在兩個城市建三個數據中心，貴！三個機房的軟硬設備，連接設備，貴！業務上線后，需要很多專門的運維人員，貴！

林源介紹說，建這么一套復雜的系統下來至少得一兩年，時間就是金錢企業絕對。青云在構建北京大區、廣東大區和上海大區的時候，每個區域、每個城市至少需要一年時間，就這還算快的。

通常所說的多活是指業務的多活，業務的多活是最終要求。他需要數據中心網絡互通、數據安全、負載遷移等層面層層遞進，底層任意一個環節出現問題，整套多活系統可能會崩潰。

GitHub多活系統也是煞費苦心，GitHub投入巨大，在兩個數據中心間買了100G光纖做互聯，做了非常充足的準備，結果還是出了問題。服務于技術人的網站也出現技術問題，聽起來挺諷刺的，其實這也正說明了多活系統的復雜性。

從技術上來講，多活的實施很難，從需求上來看，多活的需求很普遍。于是，公有云便開始提供共性的多活服務，青云就有這樣的多活服務。

青云的多活服務有基礎架構、基礎設施和分布式應用三個層次組成。

其中，基礎設施是指數據中心本身，指的是青云在北京，上海和廣東建立的數據中心，一個地區的數據中心算一個Region，一個Region有多個可用區，比如北京有北京3B,北京3D，北京3C這樣三個可用區。3個可用區之間的距離（30-50公里之間）可以滿足銀監會對銀行數據中心的要求，另外，機房之間還需要有高速低延遲帶寬支持。

在基礎設施之上的是IaaS基礎架構，IaaS層的多活服務一般都指的構建于多個數據中心之間的負載均衡服務，負載均衡器將接收到的負載分發到多個數據中心，任何單個數據中心故障都沒什么影響。另外，多活系統的網絡也很麻煩，沒關系，青云自己的數據中心已經做好了。

多活系統最上一層的是分布式應用。其實這里說是應用不是特別合適，應用一般都是用戶自己開發的，而青云所提供的通常來說是數據庫（如果非要說數據庫也是應用也可以），數據庫很難，分布式數據庫更難，有了分布式數據庫之后數據庫的多活就方便多了，將數據庫分布在不同的可用區就能提供很好的多活數據庫服務。青云的平臺上支持自研的分布式數據庫MySQL Plus，另外也支持MongoDB。

有了這三層服務之后，用戶在青云的平臺上，只要選擇了三個可用區之一，使用了負載均衡器，然后部署了分布式數據庫，然后部署自己的分布式應用之后就算構建了自己的多活服務。這套系統下來，即使是初創公司也能享受到高大上的多活服務，對青云這樣的云服務商來說，也沒有太多額外的成本，因為這服務是通用的。

所以，對于選用公有云多活服務的用戶來說，額外的成本并不明顯，遠遠低于自己搭建的多活服務。

搭建多活系統，這是公有云的天然優勢之一，所以很多公有云服務商都有多活服務，不過，與一些友商相比，青云的多活的服務能力更全面一些。（見下圖）

最近，AWS發布了混合云的產品方案Outposts，讓AWS云平臺連接到企業數據中心內部，讓用戶在本地也享受到跟云端一樣的服務體驗。這一思想和類似的描述在恰好正式青云的宣傳描述，青云自一開始就比較重視企業用戶本地的使用體驗，公有云和私有云兩條腿走路，筆者也認為這是青云能實現較快盈利的一個重要原因。

正因為如此，青云的多活不僅可以用在公有云，也用在企業混合云環境，照顧了許多企業用戶的實際需求，也能為企業用戶搭建多活方案。

無論如何，我們是看到，云服務商提供的多活有明顯優勢，成本上，實施門檻上都大大降低，用戶不會因為使用多活服務而承擔太多額外成本。理論上不存在絕對不出問題的架構，但多活架構可以把風險降低再降低，相信未來，會有更多不那么關鍵，但是對服務體驗有要求的企業也都會主動尋找云的多活服務。