790
同城雙機房架構剖析
2017運維/DevOps在線技術峰會上，阿裏雲應用運維專家誇父帶來題為“同城容災架構剖析”的演講。本文主要從部署目標和要求開始談起，接著著重對架構進行分析，然後又重點對任務分解進行說明，並對單雙機房的部署進行了對比，最後分享了容災演練方式。一起來了解下吧。
以下是精彩內容整理：
近幾個月，運維事件頻發。從“爐石數據被刪”到“MongoDB遭黑客勒索”，從“Gitlab數據庫被誤刪”到某家公司漏洞被組合攻擊。這些事件，無一不在呐喊——做好運維工作的重要性。然而，從傳統IT部署到雲，人肉運維已經是過去式，雲上運維該怎麼開展？尤其是雲2.0時代，運維已經向全局化、流程化和精細化模式轉變。與此同時，人工智能的發展，“威脅論”也隨之襲來——運維是不是快要無用武之地了？如何去做更智能的活，當下很多運維人在不斷思考和探尋答案。
從曆史來看，單機房出現網絡級故障、電源級故障都時有發生，阿裏雲在北京、香港機房等都出現過故障，從業界來看，對於機房級別，類似於雲上engine級別的容災是非常有必要的，下麵我們來具體了解下我們的業務係統是怎樣做雙機容災的。
目標&要求
我們的目標就是在一個機房出現斷網或斷電的情況下，能夠在5～30分鍾完成從A機房切換到B機房。最初當A機房單獨部署時，我們要把所有應用從A機房完全copy一份部署到B機房，從架構層麵看，要將所有流量放到最前麵機房級入口上，所以我們將所有前端的流量，包括open API流量、頁麵級的流量等全部切到統一接入，統一接入就是tengine proxy，並且我們在域名層TTL和HTTPDNS都做了設置，全網的更新時間不能超過5分鍾；還有很多中間件的部分，包括HSF開啟本機房優先、dubbo實現三機房部署和tair實施雙機房單集群等20多個中間件；另外，內部代理走VIPSERVER，開啟本機房優先策略；還有數據層雙機房主備模式。
我們到底要做什麼呢？
首先設立目標，5～30分鍾完成切換，從應用層來說，我們要實現雙機房部署，從流量層來說，我們需要從兩邊機房引入流量，這是一個雙活的概念，不是一主一備。
架構設計
我們將所有流量全部向上提了一層，接統一接入層的http應用。最初的架構並不是這樣的，是按照一個頻道一個頻道接入的，按1：1的模式，這樣的架構的好處是互不影響，任何一組機器掛掉，隻影響一個模塊對外提供的服務，但做雙機容災采用這種方案的話，複雜度太高，所以我們接入統一接入層。
針對接入統一接入的http應用，統一接入層有分流策略，天然支持應用多機房部署。流量進入統一接入後，通過VIPserver進行分流，VIPserver自帶健康檢查，當應用或者網絡出現問題，自動切斷流量。
我們還有很大部分是RPC類型的應用，類似今天注冊中心、注冊發現的這種，不像前端流量直接打進來，其實是注冊到注冊中心，由注冊中心告訴服務注冊者或消費者真正的服務在哪裏，我們認為它並不適合統一接入，流量大且對時間要求高，所以我們單獨對這組機器做了兩個VIP，分在兩三個機房，對dubbo注冊中心域名dubbo.aliyun-inc.com進行ADNS智能解析，當機房出現故障，ADNS會自動踢掉有問題的VIP。
在做規則時，架構分為三層，包括web應用層、中間件層和數據庫層。我們選取兩個比較有代表性的中間件來講：
從事實角度來講，TAIR的改造量是最大的，TAIR有雙機房單集群模式、雙機房雙集群模式，應用隻在一個機房時，有些用雙機房雙集群模式，有一些用雙機房單集群，經過技術判斷和排查，發現當使用雙機房部署時，可以用雙機房雙集群，但涉及代碼改造量會非常大，因為需要保證兩個集群數據的一致性，而雙機房單集群也有缺陷，比如A機房出現斷網斷數據情況下，TAIR數據裏是有50%數據要丟失，意味著選擇雙機房單集群就要忍受數據丟失，如果對數據要求非常高，必須選擇雙機房雙集群，如果業務對數據一致性要求較高，但對於數據的丟失可以忍受，那就可以用選擇雙機房單集群。
MTAQE3也比較有數據，MTAQE3其實是一個隊列，隊列服務是不允許數據丟失的，所以MTAQE3是在兩個機房各設置了兩個機器，全部都是master，相當於消息寫入時隨機寫入一個master到某個機房，如果全部都是雙master結構也有弊端，就是沒有備份，數據有可能在機器故障時丟失，對於我們的應用來說對於該場景的忍受度還可以，這也是基於業務來確定的，如果消息丟失可以重寫，雙master是被允許的。如果當有一條消息寫入到A機房，恰好有B機房的應用讀A機房讀到一半，A機房斷網了，這時消息就會丟失，相當於消費了一半，比如ECS的生產，場景是非常複雜的，取一條消息比如磁盤是多少、cpu是多少，鎖定消息後，它是串行的，後麵還要燒IP、OS和各種場景，它是要將這條消息取走消費一遍再塞回去，這是一個事務流的場景，可能會斷掉，斷掉後會有補償機製，最終結合業務場景和開發人員溝通，確定雙master架構，保證消息隊列能夠平穩正常運行。
任務分解
我們對整個項目進行任務分解，首先是係統梳理，到底有哪些係統需要做雙機容災；其次是資源申請，包括服務器申請、人的申請等；接著是項目運作，還要做風險評估，怎樣去規避風險；從A機房將所有應用向B機房複製時，勢必要有很強大的工具支撐，光靠人力來支撐是無法完成的；所有事情做完後，通過容災演練來驗證項目是否達到預期目標，如果沒有，進行改進。
任務分解，在整個官網係統有上千個應用，幾千台服務器，這麼多係統肯定是要分級別的，具體如下：
- L1級別是最高的，比如官網首頁、售賣係統、管控係統和生產係統等一些核心業務必須要完成雙機房部署的；
- L2比如後台係統、CRM、工單和雲台等作為支撐係統，優先級次之，並不直接對用戶提供服務，但對於我們來說是非常重要的，對於客戶來說也是非常重要的；
- L3比如像雲服、容器服務、編排服務和增值服務等，更多的是由開發同學自己維護和部署，這部分也是需要做的，但是我們需要提供工具，提供谘詢和服務；
- L4比如像域名、備案和信安，這些都是強綁定的，暫時沒有辦法做，帶後麵所有都完成後，這部分也會做掉，也會對用戶直接提供服務，比如域名買了需要備案等。
隻要涉及到用戶的需求，我們一定會做，嚴格以用戶的需求為需求，所以任務分解是非常重要的一步，所以我們要分階段去做：
1. 資源申請：我們要申請服務器資源，成立聯合項目組，申請中間件及DBA團隊支持；
2. 項目運作：建立項目組釘釘群同步改造進度，以項目周報的方式向所有老板及相關同學同步進度，以雙周會的形式推進疑難問題解決及風險評估；
3. 工具支撐：開發了專門的工具平台用戶應用快速擴容，開發專門的工具用戶快速測試等；
4. 容災演練：製定機房級的斷網用以驗證同城容災的結果是否符合架構設計並發現隱藏問題。
上圖為我們開發出的專門的一鍵擴容工具，將應用填進去，將分組取出來，確定擴容機房，以線上一台模板機作為擴容對象，完全克隆模板機上的所有應用環境配置，可以實現機房級別的快速擴容，極大的提高了效率。後續我們可能會使用自定義鏡像去做，將線上一台機器打成自定義鏡像，新的機器用自定義鏡像開啟就好。
架構對比圖
圖中左側為單機房時架構，可以從架構中很清楚的看到，用戶進來的最前端有兩層，第一層是web層，包括首頁、賬號、售賣頁和支付、控製台等，第二層是open API網關，進來後經過登錄和權限校驗向下釣，是一個非常簡化的官網架構圖。
圖中右側為雙機房架構，看起來很簡單，像是將單機房架構複製了一份，但是簡單的背後還是有很多事情要做的，中間件須橫跨兩個機房，要求A機房斷掉後，所有中間件要正常提供服務，所有的應用也能正常提供服務，流量最主要的切換在最上麵一層，比如A機房斷網後，我們需要把放在A機房統一接入和openAPI的流量全部切到B機房，為此我們專門做了一鍵切換工具，我們需要檢測在什麼情況下需要啟動切換，這是一個複雜的判斷過程。
容災演練
我們要製定演練的方式，具體如下：
- 斷網方式：將機房A內網全部通過ACL隔離
- 斷網效果：被斷網的服務器和其他機房無法進行通信，和本機房通信不受影響，和外圍通信（運營商）不受影響
- 流量切換：所有WEB類及Openapi類操作直接通過IDNS智能判斷將機房A流量切到機房B
- DB切換：DB采用RDS的proxy實現自動主從切換
- 業務驗證：待DB及流量切換完成後采用自動化測試或工具真實售賣、生產及管控進行業務驗證
圖中A機房連接B機房的路被斷掉了，中間件一半的機器被下線了，我們要求所有的中間件集群化，允許一半機器在A機房一半在B機房，不論哪個機房斷電都不能影響整個機器的服務，後續我們考慮將ZK去除掉，因為ZK必須是三機房。容災演練是一個長期的過程，從架構的演進來講，我們後麵更希望做異地容災，這是更高層的容災機製。
最後更新：2017-04-24 21:32:59