引言

在異地多活項目整體推過程中的一些注意事項和設計點歸納和整理，拋磚引玉，其中一些點還有待深入探討和優(yōu)化。

一、指導事項歸納

1.多活原因歸納

推動多活的原因大體可歸納為以下三種。

• 高可用架構部署
• 業(yè)務整體的容災
• 單機房容量限制

2.多活指導歸納

多活牽扯公司業(yè)務方方面面，整體來講業(yè)務改造和基礎設施中間件改造兩大塊。

• 核心鏈路自包含可邏輯分片
• 調(diào)用盡可能收斂在本單元
• 流量分片邏輯盡可能均衡
• 中間件多活架構改造升級
• 業(yè)務改造支持多活方案
• 業(yè)務場景驗證中間件能力

3.推動事項歸納

順利推進多活事項是公司重要戰(zhàn)略，需要統(tǒng)一思想，將多活項目當成最高優(yōu)先級推進。

• 統(tǒng)一思想認識自覺對齊到公司級戰(zhàn)略項目
• 設置總架構師級別建議對齊部門負責人，對整體架構方案和結果負責

例如：總架構師擁有對各個部門牽頭同學擁有不低于60%的績效考核權

• 部門負責人作為該部門領導需要全力推動
• 每個業(yè)務線設置接口人并負責該業(yè)務線所有對接和推動事務，對本業(yè)務線或者部門的推動結果負責

例如：業(yè)務線接口人擁本業(yè)務參與多活事項同學不低于60%的績效考核權

• 項目架構師與各業(yè)務負責人周會例會及時跟進問題和進度
• 各個牽頭人梳理的問題對外溝通前，先部門內(nèi)部對齊，提升溝通效率

4.抓核心鏈路

先保證核心鏈路的多活，避免面面俱到嚴重拖累進度，例如：

• 優(yōu)惠券庫存類扣減先中心機房統(tǒng)一扣減
• 管理運營類等無實時要求的先不做多活
• 流量切換過程中容忍分鐘級不可用，切換結束后恢復

二、多活規(guī)則與流量選擇

1.路由因子選擇與映射

路由因子選擇： 需要根據(jù)公司業(yè)務場景選擇，常見的路由因子有地域、用戶ID。

路由因子與機房映射：

地域因子：將地域編號與機房建立映射，例如：001->unit-a

用戶因子：將UID與機房建立映射，例如：123456與機房編號哈希后映射到unit-a

2.請求分配正確機房

一個請求有了多活規(guī)則后如何將請求路由到正確機房，歸納了以下幾種方式：

• 終端服務通過多域名切換：將請求直接路由到正確機房
• 在反向代理層轉發(fā)：轉發(fā)屬于異地機房流量
• 在網(wǎng)關層轉發(fā)：轉發(fā)屬于異地機房流量

3.多活管控中心服務

• 多活部署通過雙向同步或者雙寫方式保證數(shù)據(jù)的一致性
• 提供SDK和服務接口供中間件或者服務服務映射規(guī)則
• 提供流量切換的整個閉環(huán)流程

三、RPC跨機房調(diào)用能力

1.注冊中心架構圖

• 節(jié)點注冊時需要將機房信息一并注冊
• 注冊中心提供跨機房雙向同步能力

2.RPC框架跨機房調(diào)用

• 默認本機房調(diào)用策略
• 提供自定義路由功能供業(yè)務選擇是否跨機房調(diào)用
• 需要注意新老版本以及發(fā)布時是否存在流量傾斜問題

四、消息跨機房復制

1.復制插件管理與監(jiān)控

在一些業(yè)務場景中需要消息集群提供跨機房復制能力，將其他機房的流量收斂到一個機房去消費。

• 通過復制器插件將消息跨機房復制
• 通過管理平臺對復制器的監(jiān)控和管理

2.流量隔離與動態(tài)訂閱

• 通過不同主題進行流量隔離規(guī)避重復復制問題
• 動態(tài)喚醒消費SDK訂閱復制流量
• 復制流量來源機房打標

五、存儲雙向同步

1.Redis雙向同步

Redis雙向同步并不是做多活的公司都需要，如果能作為極短時間過期使用無需進行同步。然而也有的作為較長時間去存儲，如果業(yè)務改造成本巨大需要提供雙向復制能力。方案有很多種，有改源碼的，下面介紹一種RedisSyncer，java實現(xiàn)，詳見下面github連接。

• https://github.com/TraceNature/redissyncer-server

可根據(jù)實際場景進行改造，主要功能有：

• 斷點續(xù)傳
• 數(shù)據(jù)同步
• 數(shù)據(jù)遷移
• 數(shù)據(jù)校驗

實現(xiàn)原理：

• 復制器偽裝成從節(jié)點復制數(shù)據(jù)
• 同步時通過寫入輔助key的方式來識別流量來源，規(guī)避重復復制問題。

注意事項：

• 是否需要redis雙向復制提早規(guī)劃
• 過濾過短時間key無效復制，比如：小于3秒的不再同步
• 批量寫入提升性能

2.MySql雙向同步

數(shù)據(jù)庫的雙向同步在異地多活通常是必須要做的事情，下面是阿里開源otter，可基于其二次定制開發(fā)。

• https://github.com/alibaba/otter

解決循環(huán)復制實現(xiàn)原理：

• 通過事務表解決數(shù)據(jù)循環(huán)復制
• 復制數(shù)據(jù)時同時寫入一條數(shù)據(jù)到事務表在同一個事物中
• 同步數(shù)據(jù)時只同步不再事務表中的數(shù)據(jù)到異地機房

還需要提供其他周邊工具：

• 提供數(shù)據(jù)校驗工具
• 提供數(shù)據(jù)訂正工具
• 提供DDL雙向同步
• 提供數(shù)據(jù)沖突策略

注意事項提點：

• 統(tǒng)一關系數(shù)據(jù)庫存儲 多種數(shù)據(jù)庫PostgreSQL、MySql等的建議統(tǒng)一為一種
• 相關任務提早同步進行
• 中間件與DBA開發(fā)協(xié)同推進 例如：可以將周邊工具交由DBA開發(fā)

另外，在存儲側流量切換時需要提供數(shù)據(jù)庫禁寫功能，避免實現(xiàn)切流過程數(shù)據(jù)的不一致，禁寫的實現(xiàn)可以通過sql動態(tài)拼接一個很大的時間戳實現(xiàn)。

六、其他改造事項

除了中間件和業(yè)務核心服務改造外，還有一些其他的改造事項，例如：

• 發(fā)布系統(tǒng)支持不同機房發(fā)布
• CMDB中的資源和應用標識
• 監(jiān)控體系支持不同機房流量標識
• 其他存儲相關(ES、Hbase等)盡量不復制

七、流量切換過程

1.流量切換大體流程

從機房A流量切換機房B的大體流程圖如下：

• @1 多活規(guī)則中心下發(fā)禁寫通知和禁寫時間基線
• @2 數(shù)據(jù)庫SDK收到禁寫數(shù)據(jù)庫寫入和更新
• @2 雙向復制器收到超過禁寫時間基線不再復制
• @3 雙向復制器上報復制完成狀態(tài)
• @4 多活規(guī)則中心下發(fā)流量切換通知
• @5 Nginx&網(wǎng)關層收到將流量切換到機房B并上報切換完成狀態(tài)
• @6 多活規(guī)則中心下發(fā)取消禁寫通知

2.流量切換注意問題

部分流量切換的問題 場景一：切某個地域的10%流量 場景二：切某個場景用戶的10%流量

部分流量切換時數(shù)據(jù)庫禁止設計判斷

部分流量切換時復制器完成的判斷和替代方案

3.復制器監(jiān)控與思考

針對復制器自身穩(wěn)定性和性能的監(jiān)控

復制器復制進度的監(jiān)控思考

本文轉載自微信公眾號「瓜農(nóng)老梁」，可以通過以下二維碼關注。轉載本文請聯(lián)系瓜農(nóng)老梁公眾號。