異地多活高可用架構設計

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

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

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

何時去做?

個人感覺取決于以下幾個方面:

  • 業務發展
  • 基礎設施狀況
  • 技術積淀

如何做?

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

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

做的時候,需要注意什么?

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

業務背景

  • 在所有的系統中用戶中心都是核心業務,因為它是進入其它很多業務前提。
  • 我們這邊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解析,無法提供自動檢測服務是否可用的功能,也就無法自動進行切換。
      • 服務可用性,可以通過我們這邊的多點撥測進行監控,當多點撥測不可用的時候,發送告警通知給相關人員,以便人工介入。
      • 多點撥測告警,應該會提供兩類:1、某個撥測點不通的時候 2、所有撥測點均不可用的時候。
    • 目前集團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自動踢掉,流量全部切到阿里云。

原文 

https://juejin.im/post/5d931601f265da5b62533ca3

本站部分文章源于互聯網,本著傳播知識、有益學習和研究的目的進行的轉載,為網友免費提供。如有著作權人或出版方提出異議,本站將立即刪除。如果您對文章轉載有任何疑問請告之我們,以便我們及時糾正。

PS:推薦一個微信公眾號: askHarries 或者qq群:474807195,里面會分享一些資深架構師錄制的視頻錄像:有Spring,MyBatis,Netty源碼分析,高并發、高性能、分布式、微服務架構的原理,JVM性能優化這些成為架構師必備的知識體系。還能領取免費的學習資源,目前受益良多

轉載請注明原文出處:Harries Blog? » 異地多活高可用架構設計

贊 (0)
分享到:更多 ()

評論 0

  • 昵稱 (必填)
  • 郵箱 (必填)
  • 網址
手机彩票计划软件超稳