什么時候可以選用應用雙活架構？
應用雙活架構采用數據主備集群模式，優點是實現簡單，業務改造成本低，不需要過多考慮多中心數據讀寫沖突問題，流量層和應用層常態化跨中心多活，數據層通過容災主備切換實現高可用。
推薦業務場景包括：
- 業務數據集中化，無法拆分。
- 業務數據拆分成本高，應用期望少改造或零改造。
- 數據中心距離較近，異地數據讀寫延遲可接受（建議物理距離≤100km，網絡延遲≤10ms）。
什么時候可以選用數據雙活架構？
數據雙活架構采用基于業務數據分片的單元化模式，不受數據中心距離限制，流量在單元內閉環，單元故障影響不外溢。相比異地應用雙活方案業務體驗更好、故障爆炸半徑更小、容災切換更平滑，但應用改造成本更高，要求業務數據拆分、流量帶標和標記傳遞。
推薦業務場景包括：
- 單個中心數據負載過高，需要水平拆分（要求業務數據能夠拆分）。
- 數據中心距離較遠，異地調用成本過高。
- 技術投入和技術棧能夠支撐應用改造。
多活容災是否一定要進行業務改造？
不一定。在選用應用雙活架構時，應用可以不做改造，只需要引入應用容災多活的探針即可。
數據雙活架構的數據分區與流量封閉需要對業務應用進行必要的改造，一般來說有如下考慮和實施：
- 如要求服務調用分區閉環，需進行業務垂直拆分和微服務改造。
- 如要求數據訪問分區閉環，需進行數據水平拆分，確定分片鍵。
- 如要求流量調度分區閉環，需進行入口流量帶標以及路由標傳遞改造。
多活容災是否只要做好入口流量分發和底層數據同步？
否。入口流量分發和底層數據同步是實現多活能力的重要步驟，但并不能完全保證系統具備多活能力。
要具備完整的多活能力，首先做好架構規劃與演進，其次要有配套的管控能力，包括集中管理、流量控制、數據同步、數據保護等。
如何保障業務在多活場景下的數據一致性？
默認使用異步復制和最終一致性模型，通過流量糾錯和禁寫保護避免臟寫，有更高要求建議使用分布式數據庫。
微服務是如何實現跨集群發現的？
微服務通過注冊中心數據同步來實現跨集群服務發現，服務調用時根據路由規則計算路由命中來選擇跨單元或跨站點調用。
微服務在多活場景該如何處理？
盡可能單元內自封閉，若無法自封閉，可配置HTTP/DUBBO的解析規則對微服務進行打標，流量通過路由規則計算后實現跨單元調用。
消息在多活場景該如何處理？
生產側在消息的header或body打標，消費側根據路由規則進行過濾或接管，消息在站點間同步，避免數據丟失。
緩存在多活場景該如何處理？
應用讀寫本地緩存集群，緩存本身不建議同步，本地數據中心的緩存不包含其他中心的數據，當流量切換到新中心時可通過數據庫重建緩存。
任務調度在多活場景該如何處理？
您可以考慮以下兩個方案：
- 數據雙活：2個站點均開啟定時任務，撈取全量數據，過濾掉非本單元的數據后再執行。
- 應用雙活：2個站點均開啟定時任務，通過配置中心開關控制任務執行的主、備站點角色，由主站點執行全量定時任務。
多活數據面性能指標如何？
- 應用容災多活協同其他云產品，用戶可以通過查閱天翼云官方文檔，了解使用到的產品組件指定規格實例的性能指標。
- 對于引入多活探針的性能變化，同城場景RT基本沒增長，異地場景RT約有1~10ms增長，取決于具體業務與物理距離。
業務如何盡可能平滑地過渡到雙活架構？
業務應用從原有架構向雙活擴展時，應以標準化的多環境多步驟的流程進行漸進式迭代，盡可能避免產生大范圍影響，從而實現平滑過渡。
多環境 ：
- 應用發布按標準的日常、預發、灰度、生產等流程進行上線。
多步驟 ：
- 分析業務現狀，明確流量、數據和代碼改造點，包括服務拆分、數據拆分、流量染色等。
- 規劃物理架構，開通目標區域、可用區、網絡和中間件等資源。
- 完成架構升級，根據不同改造點兼容性，業務原集群多版本迭代更新。
- 部署雙活集群，對新集群進行復影流量、灰度流量等業務正確性驗證。
- 應用分層切換，微服務、消息、數據庫等組件切換多活規則。
