引言

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

一、指導事項歸納

1.多活原因歸納

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

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

2.多活指導歸納

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

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

3.推動事項歸納

順利推進多活事項是公司重要戰略，需要統一思想，將多活項目當成最高優先級推進。

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

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

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

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

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

4.抓核心鏈路

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

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

二、多活規則與流量選擇

1.路由因子選擇與映射

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

路由因子與機房映射：

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

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

2.請求分配正確機房

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

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

3.多活管控中心服務

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

三、RPC跨機房調用能力

1.注冊中心架構圖

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

2.RPC框架跨機房調用

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

四、消息跨機房復制

1.復制插件管理與監控

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

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

2.流量隔離與動態訂閱

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

五、存儲雙向同步

1.Redis雙向同步

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

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

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

• 斷點續傳
• 數據同步
• 數據遷移
• 數據校驗

實現原理：

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

注意事項：

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

2.MySql雙向同步

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

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

解決循環復制實現原理：

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

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

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

注意事項提點：

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

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

六、其他改造事項

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

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

七、流量切換過程

1.流量切換大體流程

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

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

2.流量切換注意問題

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

部分流量切換時數據庫禁止設計判斷

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

3.復制器監控與思考

針對復制器自身穩定性和性能的監控

復制器復制進度的監控思考

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