鄭昀 創建於2018/3/23 最后更新於2018/3/24
關鍵詞：異地多活，擴容，容災，地域，分布式架構，單元格，分片
提綱：
-
為什么異地多活？擴容，容災，地域優先
-
異地多活是什么場景？
-
什么樣的神操作？
異地多活（multi-idc-live）是楊海波主設計、劉勤紅主導的項目，3月21日在線下環境測試通過，3月23日面向全員做了場景和接入講解，張振坤做了雲小盒收銀和退款演示。
一.WHY
有人會問，為什么要做異地多活？阿里雲還能掛掉？！
雲縱現階段做異地多活，主要有三個目的。
第一，擴容。
擴容有兩種辦法。
第一種，單IDC架構。
應用分層（Web層，緩存層，中心層，中間件層，存儲層），每一層可伸縮，比如訂單中心可以橫向加節點，10個不夠，加到20個。這也是我們自2011年以來的七年里所實踐的擴容模式。
隨着業務量爆發，這個模式的缺點會愈來愈凸顯。節點不可能無限制地增加下去。流量入口的負載均衡節點將成為瓶頸（Nginx、SLB、F5……）。服務可能出現雪崩，一損俱損，連累其他的用戶和商戶，連累其他的業務。
舉個例子，我們做團購商城的時候，全國有很多薅羊毛的團購代理，比如團購導航公司或淘寶店主，就會注冊很多代購帳號，囤積大量的代金券，他們的用戶把錢付給他們，他們通過代購帳號購買各大團購公司的團購商品。這些大帳號登錄之后，就會隨機卡住用戶中心、訂單中心、優惠券中心等集群的線程，拖慢他們所在的數據庫分片節點處理能力，最后所有人都感知到服務變得超慢。
第二種，多IDC架構。
將業務封閉在一個個邏輯單元內，然后在多地部署多個這樣的邏輯單元，滿足了業務對容量和容災的需求。這也是我們正要前往的領域，單元格部署方式。
所以，十萬個商戶，兩個單元格搞定，一百萬商戶，二十個單元格，妥妥的，互不影響，業務隔離。
問題來了。
這二十個單元格都放在一個機房里，有何不妥？
首先，大家總覺得擴容不就是，有錢任性，說加節點就加了嘛。
可惜。並不是說有光就有光。
自建IDC機房，機櫃空余容量是有限的，並不是你今天說要幾個機櫃就能租給你幾個機櫃。沒有機櫃，你買的機器擱哪兒。
阿里雲，擴容節點多的話，也需要提前通知客服，有點像你去銀行兌換外幣，得預約！
其次，要考慮容災。
第二，容災。
分布式系統的維護者總會反復問自己：
我們的系統什么情況下會掛？假如機房掛了怎么辦？假如一個城市停電了怎么辦（洪水，海嘯，地震，滑坡，……）？業務高峰期怎么降低災難影響？
所以，很多互聯網公司都會在多個城市同時支撐商戶和用戶交易，並且能做到在一個城市所有機房癱瘓的情況下，能夠在幾分鍾內恢復（或者繼續新的）所有的交易。
小朋友會問，機房真的會掛嗎？
請先閱讀一下我寫的《經歷不可抗力是一種什么體驗》，了解一下什么是 too young too naive。
然后我們再來回顧一下：
A，2017年1月，公有雲 UCloud 公司正在開年會，結果在他們北京B可用區的數據中心外3公里處，架空光纜線桿因卡車撞倒導致光纜斷裂，工程師在年會現場緊急處理，如下圖所示：
B，2015年6月21日上午9點到10點之間，一些使用阿里雲香港數據中心的用戶發現服務出了問題，此后阿里雲公告稱由於運營商電力問題造成香港機房故障。因為供電系統故障導致數據中心大樓整體斷電，並觸發消防報警。根據當地的消防規定，必須徹底排查隱患並完全消除后，才能獲准進場做電力搶修。直至當晚21點22分機房正式恢復穩定供電，阿里雲立即執行既定預案逐項恢復服務，21點32分安全防護服務恢復正常，各項服務陸續恢復，截至23點39分全部服務恢復。
C，2015年9月1日，阿里雲官方發布致歉公告，稱“因雲盾安騎士server組件的惡意文件查殺功能升級觸發了bug，導致部分服務器的少量可執行文件被誤隔離”，但造成影響無法估量。
D，2016年7月6日，上午10點22分，阿里雲華北2地域可用區A由於網絡設備出現異常，導致部分產品訪問受到影響。故障持續約1小時。
E，2016年10月11日，下午16點40分，阿里雲華東一區部分服務器故障，導致網絡上部分網站無法運行。
災難，總是在你意料之外。
所以對於技術高級干部來說，必須回答這個問題：如果單機房物理不可訪問，你怎么辦？
第三，地域優先訪問。
隨着商戶覆蓋越來越廣，對交易延時的要求也越來越高，我們肯定是希望北方商戶優先訪問北方機房，南方商戶優先訪問南方機房。
這天然就是多IDC架構分片模式的需求。
所以，目標很明確了。
在災難還沒有降臨之前，在商戶還在可控范圍之內的時候，我們必須悍然先行進入異地多活的領域。
放心，我們一定會遭遇引入異地多活而帶來的各種技術故障……
二.HOW
聽起來很玄幻，那么異地多活到底是什么場景？
假定我們有阿里雲北京機房和上海機房，分片（即單元格）有四個：BJ-01，BJ-02，SH-01，SH-02。
那么，異地多活有這樣的四個場景：
場景一，將某個商戶從分片 BJ-01 划撥到 BJ-02。
證明我們控制的最小粒度是商戶。
場景二，北京機房可用，但 BJ-01 分片出現問題，將 BJ-01 上的商戶整體切換到 BJ-02 上。
場景三，北京機房不可用。摘除北京機房所有流量，將北京機房的所有商戶整體切換到上海機房的分片SH-02。
這里面有一個擴容步驟。即，一鍵點擊，就能將上海機房 SH-02 分片擴容，避免被打垮。
這一切不影響原有SH-01上的商戶，災難影響范圍越小越好。
場景四，北京機房災后恢復。將商戶切換回北京機房。
三.WHAT
一鍵搞定，聽起來很奇幻，怎么操作呢？
¯\_(ツ)_/¯
略。
至此，異地多活講解完畢，切換過程相當地魔幻，彈指一揮間，流量就切了，容就擴了，商戶無感知，該收銀收銀，小盒子工作無礙。
-EOF-
語錄若干：
1，
問：文章中講到的問題都是大公司的，對小團隊來說，什么時候應該開始建立自己的基礎研發體系？
支付寶侯振宇答：研發體系的建立可以分為規划和實施兩個階段。規划的話，從一開始就應該有所規划。在前期人力不夠的情況下，不用強行追求打造自己的框架和工具，可以用開源的。但應該始終把開源的東西拿到自己的體系中，清楚地知道它在自己體系中的角色，也清晰地知道自己用了它的什么特性，未來還需要補充什么。什么時候開始實施其實有一個象征性的標准，也是我們前面在無序的力量中提到的——出現了不同環節的分工時。有的團隊業務擴張太快，人力一直不夠，那么建議按五分之一到三分之一的比例來抽出人力打造基礎設施。磨刀不誤砍柴工，何況投資得到的回報是電鋸呢。
2，
@玉伯：
帶團隊的這幾年，越來越篤定 Leader 最重要的三件事情是：內心有相信並讓人相信、讓事情發生（make things happen）、保持謙卑與善良。
3，
@蔡學慵：
面試技術人員，其實很困難，因為技術人員常常不擅長表達。有時候你要挖掘半天，才能挖出他的能力，才知道其實他是個能力很好的人。所以技術面試的時間可能要長一點。
4，
@梁斌：
創業是一個99死1生的事情，是一個不斷否定自己，糾正自己，升華自己的痛苦過程。 曾經和某著名運動員會談，我問她頂級高手怎樣達到？她告訴我一句話，久久難忘。“沒有明顯弱點，但需要有一手絕活”。創業失敗者大多是都是某一個短板不斷積累問題導致崩潰的，所以要補短板，同時要配置核心競爭力。
5，
@工程師日常：
為啥你感覺工程師木訥響應慢？
