異地多活高可用架構設計

如何構建應用的異地多活?git

概要

隨着業務的快速發展,對於不少公司來講,構建於單地域的技術體系架構,會面臨諸以下面的多種問題:基礎設施的有限性限制了業務的可擴展性;機房、城市級別的故障災害,影響服務的可持續性。github

爲解決遇到的這些問題,公司能夠選擇構建異地多活架構,在同城/異地構建多個單元(業務中心)。各個業務單元能夠分佈在不一樣的地域,從而有效解決了單地域部署帶來的基礎設施的擴展限制、服務可持續性。數據庫

異地多活是近幾年比較熱門的一個話題,那麼在實際業務中何時須要去作這件事?如何去作?作的時候須要考慮什麼?服務器

什麼時候去作?

我的感受取決於如下幾個方面:微信

  • 業務發展
  • 基礎設施情況
  • 技術積澱

如何作?

目前在網上搜索到的異地多活方案來看,基本都是阿里、餓了麼、京東、微博這些互聯網大廠的實踐,這些大廠的方案有一個共同點就是:大量的自研組件,來作相關的數據同步,業務切分等等,那麼,對於不少傳統企業或者相對小一些的企業,應該如何來作這件事?網絡

  • 根據業務特性藉助合適的公有云服務

作的時候,須要注意什麼?

  • 真正須要作異地多活的業務有哪些?
  • 基礎設施如何?
  • 對於不可用時間的容忍程度是多少?

業務背景

  • 在全部的系統中用戶中心都是核心業務,由於它是進入其它不少業務前提。
  • 咱們這邊IDC不是很穩定,以前發生過幾回機房大規模故障,好比機房網絡掛了,整個機房對外不可用了。

以上兩點是咱們此次要作用戶中心異地容災的出發點,以便在面對機房級別故障時,保證服務可用性。架構

業務梳理

用戶中心從總體來看,對外主要提供:註冊、登錄、查詢用戶信息等服務。這些服務又有如下幾個特色:併發

  • 登錄的優先級最高
  • 事務性要求低

涉及的公共組件主要有:運維

  • MySQL:用戶數據存儲
  • Redis:Authorization Code、短信驗證碼、帳號鎖定、access token等的存儲
  • Zookeeper:Dubbo依賴

方案

用戶中心是經過外包的形式進行開發的,目前已上線並交付給另外一個外包商運維,因此在考慮容災一期方案的時候,須要考慮儘可能不動代碼。分佈式

目標

一期目標

當北京機房出現故障的時候,能夠必定時間內把流量切到青島機房這邊,保證用戶中心核心服務的基本可用。

二期目標

用戶中心經過異地多活,實現高可用(須要集團智能DNS支持)。

架構設計

一期架構

當北京機房發生故障的時候,能夠把流量快速切換到青島這邊,以保障用戶中心核心服務可用。

具體方案以下:

  • 經過otter近實時的將北京機房核心業務數據同步到青島機房。
  • 青島機房部署Redis、ZooKeeper等中間件。
  • 青島機房部署用戶中心的核心應用(實例正常部署、運行,只是平時不會有訪問)。

具體架構以下:

能夠達到的效果:

  • 當北京機房出現故障的時候,能夠在必定時間內把流量切到青島機房這邊,保證用戶中心核心服務的基本可用,但此時已登陸用戶須要從新登陸。
  • 必定時間:取決於DNS修改ip時間+DNS TTL時間,目前來看TTL是10分鐘,人工修改ip應該很快,因此必定時間是10~20分鐘。

存在的缺點:

  • 北京機房非故障期間,青島機房的機器,僅作數據庫同步,存在必定的資源浪費。
  • 當北京機房出現故障,流量切換到青島機房後,只能保證登錄這一核心服務的可用。對於註冊等須要修改數據庫的服務,均不支持,若是在此期間訪問這類服務,會發生異常。

二期架構

二期的目的就是修正一期架構的缺點,經過異地多活,實現高可用。

二期青島機房會替換爲阿里雲機房。

具體方案以下:

  • 經過阿里雲DTS服務實現兩地機房數據庫同步,保證北京、阿里雲數據的近實時一致性。
  • 北京、阿里雲兩地機房均提供在線服務,提升資源利用率。
  • 梳理服務優先級,修改應用代碼,支持服務降級。
  • 當某個機房(阿里雲或者北京)出現故障的時候,經過DNS服務把流量切換到另外一個機房。
    • 若是兩地部署的時候,沒有冗餘必定硬件資源,則須要實施服務降級。
    • 目前集團DNS解析,沒法提供自動檢測服務是否可用的功能,也就沒法自動進行切換。
      • 服務可用性,能夠經過咱們這邊的多點撥測進行監控,當多點撥測不可用的時候,發送告警通知給相關人員,以便人工介入。
      • 多點撥測告警,應該會提供兩類:一、某個撥測點不通的時候 二、全部撥測點均不可用的時候。
    • 目前集團DNS解析,TTL生效最短期是10分鐘,沒法自定義TTL時間。

具體架構以下:

能夠達到的效果:

  • 若是集團DNS能夠提供,相似阿里云云解析的網站監控功能並能靈活設置TTL時間,這時當北京機房或者阿里雲機房出現故障後,就能夠在很短的時間(部分服務最大異常時間)內自動進行流量切換。

此處只是以阿里云云解析示例,只要能提供相似的服務都可。

  • 若是集團DNS沒法提供相似阿里云云解析的網站監控及靈活設置TTL時間的功能,則部分服務最大異常時間仍是取決於DNS修改ip時間+DNS TTL時間。

名詞解釋

什麼是網站監控?

HTTP/HTTPS實時探測域名解析記錄,支持自定義端口,實時發現宕機當即告警; 全網分佈式監控,在中國各個地區模擬用戶端真實請求,監控結果然實可靠; 支持宕機暫停、容災切換,最大限度的解決服務中斷對您的業務帶來的損失; 容災切換支持A記錄、CNAME域名,知足各類場景的容災切換需求;

什麼狀況會被網站監控判斷爲宕機併發送告警通知?

監控結果中,HTTP/HTTPS的返回碼大於500的服務器錯誤狀況,纔會報警通知。 舉例說明:若是設置了四個探測點 北京聯通、深圳阿里巴巴、上海電信、重慶聯通。 場景一:四個探測點中50%的監控點沒法收到您服務器的響應,或50%的監控點收到返回碼大於等於500時,纔會判斷您的網站爲宕機狀況。 場景二:四個探測點中有50%以上的探測點探測您的網站返回碼是小於500的狀況,則不會判斷您的網站爲宕機。

雲解析DNS「流量管理」

雲解析「流量管理」能夠在您設置的每條解析線路下,根據權重比例輪詢返回解析結果。當線路下的IP宕機時能夠經過監控自動發現,並將宕機IP從當前線路下摘除,直到監控IP正常時會恢復解析。同時,當一條解析線路下的全部IP都宕機時,能夠切換至其餘正常線路。最大程度保證您的網站服務高可用,減少損失。

部分服務最大異常時間

好比北京機房出現異常,這時轉發到阿里雲機房的流量是能夠正常訪問,只有轉發到北京機房的流量是異常的。

這時若是使用網站監控或者相似服務,進行監控,並設置撥測間隔爲1分鐘,TTL生效時間爲1秒,那麼最多有60+1秒部分服務異常時間,以後DNS會自動把北京機房的ip自動踢掉,流量所有切到阿里雲。

補充

  1. 一期、二期方案的實現均強依賴於集團的DNS服務

  2. 用戶中心經過ip暴露的服務,一但出現機房級別的故障,一期、二期方案均沒法保證該部分服務可用。

  3. 其實除了DNS這種方案,還有一種方案就是用相似F5這種設備,做跨機房負載,但必須是gslb,並且兩端必須是相同的設備。

小結

對於,非一線互聯網大廠的公司而言,是實現異地容災的時候,藉助公有云是頗有必要的,好比:

  • 數據跨機房同步,可使用阿里雲的DTS(Data Transmission Service) 服務,目前DTS支持關係型數據庫、NoSQL、大數據(OLAP)等數據源間的數據傳輸。 它是一種集數據遷移、數據訂閱及數據實時同步於一體的數據傳輸服務。

  • 跨機房分佈式數據庫,可使用OceanBase。金融環境下一般對數據可靠性有更高的要求,OceanBase每一次事務提交,對應日誌老是會在多個數據中心實時同步,並持久化。即便是數據中心級別的災難發生,老是能夠在其餘的數據中心恢復每一筆已經完成的交易,實現了真正金融級別的可靠性要求。
  • 異地多活因爲各個公司的業務、基礎設施及要解決的問題皆不盡相同,因此選擇適合本身的就好。
  • 或者直接使用雲數據庫RDS MySQL 版

我的微信公衆號:

我的github:

github.com/jiankunking

我的博客:

jiankunking.com

相關文章
相關標籤/搜索