概要

隨著業(yè)務(wù)的快速發(fā)展，對于很多公司來說，構(gòu)建于單地域的技術(shù)體系架構(gòu)，會面臨諸如下面的多種問題：基礎(chǔ)設(shè)施的有限性限制了業(yè)務(wù)的可擴展性；機房、城市級別的故障災(zāi)害，影響服務(wù)的可持續(xù)性。

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

異地多活是近幾年比較熱門的一個話題，那么在實際業(yè)務(wù)中什么時候需要去做這件事？如何去做？做的時候需要考慮什么？

何時去做？

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

業(yè)務(wù)發(fā)展
基礎(chǔ)設(shè)施狀況
技術(shù)積淀

如何做？

目前在網(wǎng)上搜索到的異地多活方案來看，基本都是阿里、餓了么、京東、微博這些互聯(lián)網(wǎng)大廠的實踐，這些大廠的方案有一個共同點就是：大量的自研組件，來做相關(guān)的數(shù)據(jù)同步，業(yè)務(wù)切分等等，那么，對于很多傳統(tǒng)企業(yè)或者相對小一些的企業(yè)，應(yīng)該如何來做這件事？

根據(jù)業(yè)務(wù)特性借助合適的公有云服務(wù)

做的時候，需要注意什么？

真正需要做異地多活的業(yè)務(wù)有哪些？
基礎(chǔ)設(shè)施如何？
對于不可用時間的容忍程度是多少？

業(yè)務(wù)背景

在所有的系統(tǒng)中用戶中心都是核心業(yè)務(wù)，因為它是進(jìn)入其它很多業(yè)務(wù)前提。
我們這邊IDC不是很穩(wěn)定，之前發(fā)生過幾次機房大規(guī)模故障，比如機房網(wǎng)絡(luò)掛了，整個機房對外不可用了。

以上兩點是我們這次要做用戶中心異地容災(zāi)的出發(fā)點，以便在面對機房級別故障時，保證服務(wù)可用性。

業(yè)務(wù)梳理

用戶中心從整體來看，對外主要提供：注冊、登陸、查詢用戶信息等服務(wù)。這些服務(wù)又有以下幾個特點：

登陸的優(yōu)先級最高
事務(wù)性要求低

涉及的公共組件主要有：

MySQL：用戶數(shù)據(jù)存儲
redis：Authorization Code、短信驗證碼、賬號鎖定、access token等的存儲
Zookeeper：Dubbo依賴

方案

用戶中心是通過外包的形式進(jìn)行開發(fā)的，目前已上線并交付給另一個外包商運維，所以在考慮容災(zāi)一期方案的時候，需要考慮盡量不動代碼。

目標(biāo)

一期目標(biāo)

當(dāng)北京機房出現(xiàn)故障的時候，可以一定時間內(nèi)把流量切到青島機房這邊，保證用戶中心核心服務(wù)的基本可用。

二期目標(biāo)

用戶中心通過異地多活，實現(xiàn)高可用（需要集團(tuán)智能DNS支持）。

架構(gòu)設(shè)計

一期架構(gòu)

當(dāng)北京機房發(fā)生故障的時候，可以把流量快速切換到青島這邊，以保障用戶中心核心服務(wù)可用。

具體方案如下：

通過otter近實時的將北京機房核心業(yè)務(wù)數(shù)據(jù)同步到青島機房。
青島機房部署Redis、ZooKeeper等中間件。
青島機房部署用戶中心的核心應(yīng)用（實例正常部署、運行，只是平時不會有訪問）。

具體架構(gòu)如下：

可以達(dá)到的效果：

當(dāng)北京機房出現(xiàn)故障的時候，可以在一定時間內(nèi)把流量切到青島機房這邊，保證用戶中心核心服務(wù)的基本可用，但此時已登錄用戶需要重新登錄。
一定時間：取決于DNS修改ip時間+DNS TTL時間，目前來看TTL是10分鐘，人工修改ip應(yīng)該很快，所以一定時間是10~20分鐘。

存在的缺點：

北京機房非故障期間，青島機房的機器，僅做數(shù)據(jù)庫同步，存在一定的資源浪費。
當(dāng)北京機房出現(xiàn)故障，流量切換到青島機房后，只能保證登陸這一核心服務(wù)的可用。對于注冊等需要修改數(shù)據(jù)庫的服務(wù)，均不支持，如果在此期間訪問這類服務(wù)，會發(fā)生異常。

二期架構(gòu)

二期的目的就是修正一期架構(gòu)的缺點，通過異地多活，實現(xiàn)高可用。

二期青島機房會替換為阿里云機房。

具體方案如下：

通過阿里云DTS服務(wù)實現(xiàn)兩地機房數(shù)據(jù)庫同步，保證北京、阿里云數(shù)據(jù)的近實時一致性。
北京、阿里云兩地機房均提供在線服務(wù)，提高資源利用率。
梳理服務(wù)優(yōu)先級，修改應(yīng)用代碼，支持服務(wù)降級。
當(dāng)某個機房（阿里云或者北京）出現(xiàn)故障的時候，通過DNS服務(wù)把流量切換到另一個機房。
如果兩地部署的時候，沒有冗余一定硬件資源，則需要實施服務(wù)降級。
目前集團(tuán)DNS解析，無法提供自動檢測服務(wù)是否可用的功能，也就無法自動進(jìn)行切換。
服務(wù)可用性，可以通過我們這邊的多點撥測進(jìn)行監(jiān)控，當(dāng)多點撥測不可用的時候，發(fā)送告警通知給相關(guān)人員，以便人工介入。
多點撥測告警，應(yīng)該會提供兩類：1、某個撥測點不通的時候 2、所有撥測點均不可用的時候。
目前集團(tuán)DNS解析，TTL生效最短時間是10分鐘，無法自定義TTL時間。

具體架構(gòu)如下：

可以達(dá)到的效果：

如果集團(tuán)DNS可以提供，類似阿里云云解析的網(wǎng)站監(jiān)控功能并能靈活設(shè)置TTL時間，這時當(dāng)北京機房或者阿里云機房出現(xiàn)故障后，就可以在很短的時間（部分服務(wù)最大異常時間）內(nèi)自動進(jìn)行流量切換。

此處只是以阿里云云解析示例，只要能提供類似的服務(wù)均可。

如果集團(tuán)DNS無法提供類似阿里云云解析的網(wǎng)站監(jiān)控及靈活設(shè)置TTL時間的功能，則部分服務(wù)最大異常時間還是取決于DNS修改ip時間+DNS TTL時間。

名詞解釋

什么是網(wǎng)站監(jiān)控？

HTTP/HTTPS實時探測域名解析記錄，支持自定義端口，實時發(fā)現(xiàn)宕機立即告警；

全網(wǎng)分布式監(jiān)控，在中國各個地區(qū)模擬用戶端真實請求，監(jiān)控結(jié)果真實可靠；

支持宕機暫停、容災(zāi)切換，最大限度的解決服務(wù)中斷對您的業(yè)務(wù)帶來的損失；

容災(zāi)切換支持A記錄、CNAME域名，滿足各種場景的容災(zāi)切換需求；

什么情況會被網(wǎng)站監(jiān)控判斷為宕機并發(fā)送告警通知？

監(jiān)控結(jié)果中，HTTP/HTTPS的返回碼大于500的服務(wù)器錯誤情況，才會報警通知。

舉例說明：如果設(shè)置了四個探測點北京聯(lián)通、深圳阿里巴巴、上海電信、重慶聯(lián)通。

場景一：四個探測點中50%的監(jiān)控點無法收到您服務(wù)器的響應(yīng)，或50%的監(jiān)控點收到返回碼大于等于500時，才會判斷您的網(wǎng)站為宕機情況。

場景二：四個探測點中有50%以上的探測點探測您的網(wǎng)站返回碼是小于500的情況，則不會判斷您的網(wǎng)站為宕機。

云解析DNS“流量管理”

云解析“流量管理”可以在您設(shè)置的每條解析線路下，根據(jù)權(quán)重比例輪詢返回解析結(jié)果。當(dāng)線路下的IP宕機時可以通過監(jiān)控自動發(fā)現(xiàn)，并將宕機IP從當(dāng)前線路下摘除，直到監(jiān)控IP正常時會恢復(fù)解析。同時，當(dāng)一條解析線路下的所有IP都宕機時，可以切換至其他正常線路。最大程度保證您的網(wǎng)站服務(wù)高可用，減小損失。

部分服務(wù)最大異常時間

比如北京機房出現(xiàn)異常，這時轉(zhuǎn)發(fā)到阿里云機房的流量是可以正常訪問，只有轉(zhuǎn)發(fā)到北京機房的流量是異常的。

這時如果使用網(wǎng)站監(jiān)控或者類似服務(wù)，進(jìn)行監(jiān)控，并設(shè)置撥測間隔為1分鐘，TTL生效時間為1秒，那么最多有60+1秒部分服務(wù)異常時間，之后DNS會自動把北京機房的ip自動踢掉，流量全部切到阿里云。

補充

一期、二期方案的實現(xiàn)均強依賴于集團(tuán)的DNS服務(wù)
用戶中心通過ip暴露的服務(wù)，一但出現(xiàn)機房級別的故障，一期、二期方案均無法保證該部分服務(wù)可用。
其實除了DNS這種方案，還有一種方案就是用類似F5這種設(shè)備，作跨機房負(fù)載，但必須是gslb，而且兩端必須是相同的設(shè)備。

小結(jié)

對于，非一線互聯(lián)網(wǎng)大廠的公司而言，是實現(xiàn)異地容災(zāi)的時候，借助公有云是很有必要的，比如：

數(shù)據(jù)跨機房同步，可以使用阿里云的DTS(Data Transmission Service) 服務(wù)，目前DTS支持關(guān)系型數(shù)據(jù)庫、NoSQL、大數(shù)據(jù)(OLAP)等數(shù)據(jù)源間的數(shù)據(jù)傳輸。它是一種集數(shù)據(jù)遷移、數(shù)據(jù)訂閱及數(shù)據(jù)實時同步于一體的數(shù)據(jù)傳輸服務(wù)。

跨機房分布式數(shù)據(jù)庫，可以使用OceanBase。金融環(huán)境下通常對數(shù)據(jù)可靠性有更高的要求，OceanBase每一次事務(wù)提交，對應(yīng)日志總是會在多個數(shù)據(jù)中心實時同步，并持久化。即使是數(shù)據(jù)中心級別的災(zāi)難發(fā)生，總是可以在其他的數(shù)據(jù)中心恢復(fù)每一筆已經(jīng)完成的交易，實現(xiàn)了真正金融級別的可靠性要求。
異地多活由于各個公司的業(yè)務(wù)、基礎(chǔ)設(shè)施及要解決的問題皆不盡相同，所以選擇適合自己的就好。
或者直接使用云數(shù)據(jù)庫RDS MySQL 版