最近，公有云又出了些大故障，各大群和朋友圈又開始沸沸揚揚，但是整體看下來，聲音無非兩種：
單站點不靠譜，要有容災，出現這種情況就得馬上切，所以回去趕緊建設容災站點;
雞蛋不能放在一個籃子里，單云不靠譜，要多云。所以，多云就要選我們家的xx云，或者我們提供xx多云服務。
我在我的一個討論群里就提出來，第一種聲音是有意識的建設，有這個意識很好，但是把這個事情想得太簡單了。第二種聲音，基本就是不動腦子的瞎BB，原因我下面講。
轉回正題來，既然上篇提到主備模式不靠譜，那到底怎么選?而且整天見各類技術文章，不是雙活，就是多活，不是同城，就是異地，現在又出來個多云，好復雜。
下面我就談談我的理解：
首先，這么多名詞是什么含義，要搞清楚，然后再看適不適合。
先講相對簡單的雙活(簡不簡單，看后面就明白了)，其實就是兩個站點，同時承載業務流量，可以根據用戶ID、地域或者其他業務屬性也決定怎么分擔流量，當一個站點故障時，可以快速(分鐘級)切換到另一個站點，理想情況下，對業務基本是無損或者非常小的。
這里就跟前面講的主備不同了，主備的另一個站點完全是不承載任何流量的。
這里再往深里看一眼，同時承載流量，也要看承載到那一層，也就是流量在統一站點內閉環，所有調用都是本機房內完成，還是只有應用層這樣的無狀態組件雙活，但是數據訪問、異步消息這些有狀態的部件還是回到主站點調用，這兩種模式又是不一樣的。
其實第二種，就比前面講的主備模式要好一些，因為這樣至少可以保證應用層隨時可用，不過真出故障的時候，還是少不了數據層的切換，這個其實是非常耗時的。跟主備模式一樣，基本無法演練，因為代價太高，數據會有損。(如果數據層沒有這么復雜，只有幾個數據庫，那是沒問題問題的，但是分布式的場景下，上百個，幾百個實例切換，這個代價和成本還是很大的。)
所以，再往下推導，如果想要做到有效果的雙活，就必須保證每個站點，都是獨立運行，所有的調用都是本機房調用且閉環，底層做好數據同步即可。
只有做到這個程度，當一個站點發生故障不可用時，就可以從接入層把故障站點的流量切換到另一個站點，雙活的效果也就有了。
不過，做到這個程度，就不是說我們想要做就能做到的，如果您做個類似的架構設計，你會知道這里有三個關鍵的技術點：
第一個，本機房調用
也就是一個分布式請求不能跨機房調來調去，這個是不行的，必須要保證本機房調用閉環。所以從分布式服務的路由策略上，以及服務化框架上，必須得支持這也中調用模式，同理，數據訪問層，以及消息組件也要支持這種特性。
第二個，數據分片和一致性
為什么要做這個事情?我們知道一個系統中數據準確性、完整性和一致性是非常關鍵的，放到雙活這個場景下，最關鍵的就是數據一致性，我們不能允許有同一個記錄兩邊同時在變更，還要雙向同步，比如用戶交易和支付類的數據，同時變更的情況下，我們無法確認哪邊是準確的。
前面提到，兩個站點是同時承載不同的流量的，這就要根據一些業務屬性來分配，比如用戶ID、所屬地域等等策略，這里為的就是能夠在數據層面也要做好隔離，一個站點內只提供固定部分的用戶訪問。
這樣就保證了單站點內同一分片的數據，不會在另外一個站點被變更，后續的同步也可以做到單向。
所以，這里的關鍵，就是數據要做分片，就要用到分布式的數據中間件，要做數據訪問的路由設計，數據要同機房讀寫，還要做數據拆分這樣的工作，技術門檻和工作量也不低。
這兩點如果能夠做到，其實就是我們經常說的“單元化”架構達成了，理論上，我們可以選擇任何一個機房和地域，把系統搭建起來，就可以提供業務訪問了。
但現實是更為復雜的，因為用戶業務系統產生的數據，有可能會被其它系統用到，比如商品庫存這樣的系統，這就要涉及異步消息和數據的同步問題，而數據同步不僅僅是一個技術問題，而是個物理問題，我們接下來講。
第三個，數據同步。
其實單從同步角度而言，目前很多的同步工具和開源產品已經比較完善，所以這里最大的問題，其實不在技術層面，而是在物理層面。
準確點，就是物理距離上的時延問題，這個無論是雙活、多活，還是同城、異地，都繞不開的痛苦問題。
既然要雙活，必然會選擇另一個跟當前機房有一定距離的機房(同城或異地)，而且距離必須得拉開才有意義，如果都在一個園區里面，就沒有任何容災意義了。
距離一旦拉開，物理距離就出來了，即使是專線相連，中間也要經過很多網絡設備，如果是云化的網絡架構下，經過的軟硬設備就更多，還有可能涉及協議轉換，如果中途跨運營商，就更難保障，這樣一來時延肯定是幾倍、十幾倍，甚至是上百倍的上漲，直接從0.x毫秒，上漲到秒級別。
對于同城來說，這個問題還好，但是一旦跨省就完全不可控，特別是機房如果不是自己的，根本無法控制。所以，想大公司自建機房，一定會在這個層面做大量的優化，盡最大可能降低時延。
就以淘寶、天貓為例，按照之前了解的情況，基本也是杭州和上海這兩個城市為主做雙活，再遠時延這個問題就繞不開了。
數據同步及時性為什么這么重要，一個是業務體驗，不能說庫存都沒了，其他用戶看到的還是有貨，這個是不會被接受的。
再就是故障時，如果同步不及時，極有可能造成幾秒鐘內的交易數據丟失，或者不一致，像淘寶這樣每秒4位數訂單量的系統，丟幾秒鐘數據，造成的損失也是巨大的。所以，這里就必須要建設有一整套的數據完整性和一致性保障措施，盡最大程度降低業務損失。
所以，數據同步所依賴的時延問題，其實就已經超出了絕大部分公司所能掌控的范疇，也不是單純靠自身技術能解決的問題，要看天時和地利。
講到這里，我想多活就不用講了，時延這個問題解決不了，多活就是扯淡，至于同城和異地，我想看明白的讀者，也知道怎么選擇了，其實一樣，還是取決于時延。
我們可以得出的幾個結論：
不管怎么選擇容災方案，我們自己的業務系統，從自身架構上，一定要支持單元化，一定要支持數據同步才行，如果這都不支持，講雙活和多活，就是特么的扯淡。所以，打算搞雙活，先從這里下手，當然牽出來就要涉及到分布式，還有很多大量細節技術問題。
一個合理的建設節奏應該是，同城雙活—異地雙活—兩地三中心(同城雙活+異地多活)，因為你要解決的問題的復雜度和難度也是在逐步上升的，不可能一蹴而就。
題目里這些個名詞，不是孤立的，而是從不同維度看到的結論，但是如果你偏離自己的業務場景去看，孤立的去看，就一定會被帶到溝里去，而且不知道該如何下手，所以，一定別偏離你的業務場景，然后把它們聯系起來。
一切都是ROI，為了保證高可用，就一定會有成本，高可用程度越高，成本就一定越高，所以成本投入得到的收益到底劃不劃算，這個只能自家公司自家評判。
現實情況，比我寫的要復雜的多的多，推薦大家看兩個成功案例，一個是畢玄的異地多活數據中心，一個是餓了么異地多活，幾個關鍵字google一下就有了，里面涉及到的場景化的細節對大家理解這件事情的復雜度會有更幫助。
寫的有點多了，關于多云先不寫了，就當問題吧，大家覺得是不是需要多云建設?你怎么看?可以在留言區發表下意見。
