對於異地多活的實踐與思考
瀏覽次數：707
<>一、引
異地多活是近幾年比較熱門的乙個話題，那麼在實際業務中什麼時候需要去做這件事？如何去做？做的時候需要考慮什麼？
<>1、何時去做？
個人感覺取決於以下幾個方面：
* 業務發展
* 基礎設施狀況
* 技術積澱
<>2、如何做？
目前在網上搜尋到的異地多活方案來看，基本都是阿里、餓了麼、京東、微博這些網際網路大廠的實踐，這些大廠的方案有乙個共同點就是：大量的自研元件，來做相關的資料同步，業務切分等等，那麼，對於很多傳統企業或者相對小一些的企業，應該如何來做這件事？
* 其實可以借助公有雲提供的服務
<>3、做的時候，需要注意什麼？
* 真正需要做異地多活的業務有哪些？
* 基礎設施如何？
* 對於不可用時間的容忍程度是多少？
<>二、背景介紹
* 在所有的系統中使用者中心都是核心業務，因為它是進入其它很多業務前提。
* 我們這邊idc不是很穩定，之前發生過幾次機房大規模故障，比如機房網路掛了，整個機房對外不可用了。
以上兩點是我們這次要做使用者中心異地容災的出發點，以便在面對機房級別故障時，保證服務可用性。
<>三、業務梳理
使用者中心從整體來看，對外主要提供：註冊、登陸、查詢使用者資訊等服務。這些服務又有以下幾個特點：
* 登陸的優先順序最高
* 事務性要求低
涉及的公共元件主要有：
* mysql：使用者資料儲存
* redis：authorization code、簡訊驗證碼、賬號鎖定、access token等的儲存
* zookeeper：dubbo依賴
<>四、方案
使用者中心是通過外包的形式進行開發的，目前已上線並交付給另乙個外包商運維，所以在考慮容災一期方案的時候，需要考慮盡量不動**。
<>一、目標
<>1、一期目標
當北京機房出現故障的時候，可以一定時間內把流量切到青島機房這邊，保證使用者中心核心服務的基本可用。
<>2、二期目標
使用者中心通過異地多活，實現高可用(需要集團智慧型dns支援)。
<>二、架構設計
<>1、一期架構
當北京機房發生故障的時候，可以把流量快速切換到青島這邊，以保障使用者中心核心服務可用。
具體方案如下：
通過otter近實時的將北京機房核心業務資料同步到青島機房。
青島機房部署redis、zookeeper等中介軟體。
青島機房部署使用者中心的核心應用(例項正常部署、執行，只是平時不會有訪問)。
具體架構如下：
可以達到的效果：
* 當北京機房出現故障的時候，可以在一定時間內把流量切到青島機房這邊，保證使用者中心核心服務的基本可用，但此時已登入使用者需要重新登入。
存在的缺點：
* 北京機房非故障期間，青島機房的機器，僅做資料庫同步，存在一定的資源浪費。
當北京機房出現故障，流量切換到青島機房後，只能保證登陸這一核心服務的可用。對於註冊等需要修改資料庫的服務，均不支援，如果在此期間訪問這類服務，會發生異常。
<>2、二期架構
二期的目的就是修正一期架構的缺點，通過異地多活，實現高可用。
二期青島機房會替換為阿里雲機房。
具體方案如下：
* 通過阿里雲dts服務實現兩地機房資料庫同步，保證北京、阿里雲資料的近實時一致性。
* 梳理服務優先順序，修改應用**，支援服務降級。
* 當某個機房(阿里雲或者北京)出現故障的時候，通過dns服務把流量切換到另乙個機房。
* 如果兩地部署的時候，沒有冗餘一定硬體資源，則需要實施服務降級。
* 目前集團dns解析，無法提供自動檢測服務是否可用的功能，也就無法自動進行切換。
* 服務可用性，可以通過我們這邊的多點撥測進行監控，當多點撥測不可用的時候，傳送告警通知給相關人員，以便人工介入。
* 多點撥測告警，應該會提供兩類：1、某個撥測點不通的時候 2、所有撥測點均不可用的時候。
* 目前集團dns解析，ttl生效最短時間是10分鐘，無法自定義ttl時間。
具體架構如下：
可以達到的效果：
如果集團dns可以提供，類似阿里云云解析的**監控功能並能靈活設定ttl時間，這時當北京機房或者阿里雲機房出現故障後，就可以在很短的時間(部分服務最大異常時間)內
自動進行流量切換。
名詞解釋
1、什麼是**監控？
* http/https實時探測網域名稱解析記錄，支援自定義埠，實時發現宕機立即告警；
* 全網分布式監控，在中國各個地區模擬使用者端真實請求，監控結果真實可靠；
* 支援宕機暫停、容災切換，最大限度的解決服務中斷對您的業務帶來的損失；
* 容災切換支援a記錄、cname網域名稱，滿足各種場景的容災切換需求；
2、什麼情況會被**監控判斷為宕機並傳送告警通知？
監控結果中，http/https的返回碼大於500的伺服器錯誤情況，才會報警通知。
舉例說明：如果設定了四個探測點 北京聯通、深圳阿里巴巴、上海電信、重慶聯通。
3、雲解析dns「流量管理」
雲解析「流量管理」可以在您設定的每條解析線路下，根據權重比例輪詢返回解析結果。當線路下的ip宕機時可以通過監控自動發現，並將宕機ip從當前線路下摘除，直到監控ip正常時會恢復解析。同時，當一條解析線路下的所有ip都宕機時，可以切換至其他正常線路。最大程度保證您的**服務高可用，減小損失。
4、部分服務最大異常時間
比如北京機房出現異常，這時**到阿里雲機房的流量是可以正常訪問，只有**到北京機房的流量是異常的。
這時如果使用**監控或者類似服務，進行監控，並設定撥測間隔為1分鐘，ttl生效時間為1秒，那麼最多有60+1秒部分服務異常時間，之後dns會自動把北京機房的ip自動踢掉，流量全部切到阿里雲。
此處只是以阿里云云解析示例，只要能提供類似的服務均可。
* 如果集團dns無法提供類似阿里云云解析的**監控及靈活設定ttl時間的功能，則部分服務最大異常時間還是取決於dns修改ip時間+dns ttl時間
<>三、補充
1、一期、二期方案的實現均強依賴於集團的dns服務
2、使用者中心通過ip暴露的服務，一但出現機房級別的故障，一期、二期方案均無法保證該部分服務可用。
3、其實除了dns這種方案，還有一種方案就是用類似f5這種裝置，作跨機房負載，但必須是gslb，而且兩端必須是相同的裝置。
<>五、小結
對於，非一線網際網路大廠的公司而言，是實現異地容災的時候，借助公有雲是很有必要的，比如：
* 資料跨機房同步，可以使用阿里雲的dts(data transmission service)
服務，目前dts支援關係型資料庫、nosql、大資料(olap)等資料來源間的資料傳輸。 它是一種集資料遷移、資料訂閱及資料實時同步於一體的資料傳輸服務。
* 跨機房分布式資料庫，可以使用oceanbase
。金融環境下通常對資料可靠性有更高的要求，oceanbase每一次事務提交，對應日誌總是會在多個資料中心實時同步，並持久化。即使是資料中心級別的災難發生，總是可以在其他的資料中心恢復每一筆已經完成的交易，實現了真正金融級別的可靠性要求。
* 異地多活由於各個公司的業務、基礎設施及要解決的問題皆不盡相同，所以選擇適合自己的就好。
oceanbase文章推薦：
* oceanbase 架構
* oceanbase 選舉
mysql異地多活方案 聊聊多活
隨著業務量的增加，一次大區故障可能影響幾億人的使用，所以公司對於故障的容忍率越來越低。對了避免出現由於由於乙個機房入口光纜被挖斷或者機房停電導致服務不可用，所以很多公司做了多活。多活目前分 1.同城 異地多活 2.單元化部署 還有一種單元化的概念，把使用者按照id或者地理圍欄分段，每個段內的使用者資...
mysql異地多活方案 資料庫異地多活解決方案
異地多活指分布在異地的多個站點同時對外提供服務的業務場景。異地多活是高可用架構設計的一種，與傳統的災備設計的最主要區別在於 多活 即所有站點都是同時在對外提供服務的。以乙個簡單的業務單元的it系統為例，整個it系統的異地多活方案如下圖所示。整個方案將各站點分為 分流量層 應用層和資料層。單元封閉 應...
異地多活（異地雙活）實踐經驗
異地多活 異地雙活 是最近業界討論比較多的話題，特別是前一陣子支付寶機房光纖故障和攜程網資料庫丟失之後，更加喚起了技術人員們對異地容災的考慮。而異地多活比異地容災更高一級，因為異地容災僅僅是乙個冷備的概念，而異地多活卻是指有兩個或者多個可以同時對外服務的節點，任意乙個點掛了，也可以迅速切換到其他節點...