1. 引言
   同城雙活，是年度最大的架構變更。同城容災，對於生產的高可用保障，重大的意義和價值是不言而喻的。
   用儲總的話說，這麼重要的架構工作，所有架構師都應該重點主導和參與。
   同城雙活，表面看是生產增加了一套環境，從架構上看，這個改變影響是巨大的，它對資料一致性保障、應用高可用管理、請求流量管理、版本釋出管理、網路架構管理提升了不少的複雜度。
   以往，我們生產只有一套環境，現在變成二套環境，研發團隊在這方面的認知和應對經驗，也是相對缺乏的。
   同城雙活如此重要，挑戰這麼大，那麼，它的目標是什麼，怎麼達成？方案是什麼，怎麼落地？這些挑戰和問題，我們如何應對？
   我們將釋出同城雙活系列文章，希望可以幫助大家找到答案。
2. 同城雙活目標
   同城雙活是一個長期，不斷持續改進的事情，我們需要長短結合，分階段分步驟來落實。

2.1 短期（2020年）目標

說明：

    1.  短期來講，最重要的是把雙活環境構建起來，支援同城容災。只有所有應用系統都做了雙活，雙活環境才完整。

    2.  雙活環境，需要確保是“活”的，也就是常規情況下，必須有流量進入。它的目的是保證雙活環境的版本與生產主環境的版本一致，保持常規情況下，是可用狀態。

    3.  當主環境故障時，儲存進行主從切換，換到雙活環境，流量100%匯入雙活環境，30分鐘內完成恢復，實現同城容災。

    4.  為避免出現“資料一致性問題”及雙活架構過於複雜，短期同城雙活的目標是：應用雙活，儲存跨IDC同步（熱備）。

    5.  “同城雙活”的主要目的是：同城容災，提升生產的高可用。
 

2.2 長期（2021年）目標

說明：

1. 同城跨IDC存在時延和頻寬問題，問題影響有多大？應用系統能否接受？目前還沒有大規模生產實踐、論證過，暫時是沒有答案的。

如何改進或者規避，暫時也是沒有很具體答案的。

短期，我只匯入極小部分流量進行雙活環境，以及容災切換時儲存切換到雙活環境的方式，儘量避免跨IDC請求的發生，來規避這個問題。

長期，我們需要逐步增加匯入雙活的流量，逐步增加跨IDC的請求，持續監控觀察，持續改進；在實踐過程中，逐步把這個問題解決掉或規避掉，直至雙活環境能穩定承擔一半（50%）的流量。

2. 短期，各類中介軟體、運維工具對容災切換的支援尚不完善，也缺少生產演練和實踐，容災切換過程中，必然有比較多的手工操作，甚至有些小複雜。所以，短期的同城容災切換，每個子系統需要根據自身實際情況，建立”容災切換操作手冊“，給到運維使用。

長期，我們需要通過工具、中介軟體、應用改造，實現操作的介面化、一鍵化，達到運維變更和驗證自助自動化，並儘量降低RTO恢復時間。

所以，容災切換過程，是一個需要不斷打磨的過程，我們需要先學會“走路”，慢慢跑起來，越跑越順。

3. 長期來看，如果條件允許，可以對儲存進行分割槽改造，實現真正意義上的儲存雙活。

4. 整體方案
   接下來，我們介紹一下整體方案。

3.1 雙活環境

說明：

1. Redis所有請求回主環境，雙活環境熱備，預設不進行跨IDC資料主從同步；跨IDC資料同步目前還沒有通過驗證，不具備投產條件。
   更詳細內容，參見：同城雙活-Redis篇。

2. Job同時只能一個環境跑，預設主環境跑，雙活環境關閉。QuartzJob、SpringJob建議改造遷移到Horae。

3. DB跨IDC主從同步，主環境為主，雙活環境為從。兩邊應用預設都連“主環境DB“。DB包括Mysql、Oracle、Mongodb。
   更詳細內容，參見：同城雙活-DB篇。

4. NAS儲存：NAS不推薦使用，建議改造使用分散式儲存替代。短期過渡，雙邊環境連線主環境NAS，不做主從同步。

5. NAS、Redis、DB屬於“儲存”，短期目標是應用雙活，應用雙活不包括“儲存”，雙活環境訪問儲存，預設跨IDC回主環境。

6. 短期，以支援口袋App這個渠道的關鍵業務場景雙活為主。口袋App端在渠道入口採用HTTP-DNS方式，匯入"白名單或1%“的流量進入雙活環境。
   應用系統，依據“同IDC優先“的策略，應用請求儘量不跨IDC，全鏈路雙活。
   更詳細內容，參見：同城雙活-流量分流篇。

7. 在業務場景雙活的全鏈路上，如果某些應用系統暫時未做雙活，進行雙活環境的流量，需要跨IDC調回“主環境”，例如示意圖中的“應用B"。

8. 依據“同IDC優先“的策略，雙活環境的應用請求儘量不跨IDC回“主環境”，儘量避免“跨IDC“呼叫。

9. 雙活環境為獨立一套環境，基礎設施也是獨立的，包括Pafa5配置中心、Dubbo註冊中心、Apollo配置中心、內網F5、ESB等等。

10. 雙活環境資源配置對等原則：即雙活環境的資源配置須與主環境的資源配置完全一樣，包括應用、MQ、儲存。確保這套環境能承擔生產100%的流量。

11. 雙活環境的配置檔案為獨立一套，包括Pafa5配置中心、Apollo配置中心。雙活環境的配置，有可能部分配置與生產主環境不一樣，雖然部署的應用版本是一樣的。
    更詳細內容，參見：同城雙活-釋出篇。

12. 雙活環境Dubbo服務註冊中心為獨立一套，雙邊環境註冊中心資料會進行同步，沒做雙活應用Dubbo請求，都會跨IDC調回主環境（觀瀾IDC）。
    Dubbo支援“同IDC優先“請求分流，需要升級Pafa5版本到5.4.9及以上。
    更詳細內容，參見：同城雙活-Dubbo篇。

13. MQ短期預設方案是：單邊生產單邊消費，即訊息生產投遞迴到主環境的Topic，消費預設在主環境消費；MQ雙活環境熱備；MQ包括ISC、RocketMQ、Kafka。
    更詳細內容，參見：同城雙活-MQ篇。
    3.2 容災切換
    

    當主環境（觀瀾IDC）故障，需要進行同城容災切換。即儲存進行主從切換（雙活環境儲存轉換為主），流量100%匯入雙活環境：

說明：

1. 容災切換，假設主環境（觀瀾IDC）不可用，需要把所有（100%）使用者請求匯入雙活環境，進行故障恢復。
   因為主環境的儲存也不可用，需要啟用雙活環境的儲存。
   因為主環境的儲存不可用，所以雙活跨IDC的應用請求，都會失敗。
2. Redis切換到雙活環境的熱備。在未做資料跨IDC同步的情況下，Redis資料是丟失的。
   需要研發團隊，逐一分析Redis中的資料和使用場景，評估是否容忍資料丟失，降級措施是什麼？
   更詳細內容，參見：同城雙活-Redis篇
3. DB需要DBA進行主從切換，雙活環境DB需要切換為主，雙活應用也需要變更連線配置。
4. Job只在單邊環境跑，主環境不可用即已關閉跑Job，所以雙活環境需要修改配置，啟用雙活環境Job跑批。
5. NAS儲存將不可用，需要分析、評估影響範圍，並做好容錯降級措施。
   6.未做雙活的關聯方應用，將不可用，注意做好容錯降級措施，避免”雪崩“。
   7.MQ主環境Topic將不可用，生產者需要修改配置切換到雙活環境的Topic。
   做了雙活的消費者，則在雙活環境消費；未做雙活的消費者，訊息將在雙活MQ積壓，訊息可能丟失。
   更詳細內容，參見：同城雙活-MQ篇。
   8.Dubbo主環境的服務註冊中心將不可用，則雙活環境的服務註冊中心會偵測到不可用，並剔除主環境的服務提供者。
   更詳細內容，參見：同城雙活-Dubbo篇。
   3.3 容災切換操作手冊
   通過切換啟用雙活環境進行容災恢復，每個應用系統需要根據自身實際情況，制定詳細的切換操作手冊，確保安全、高效、有序切換。

說明：

1. 切換特別要注意的是資料一致性，儲存不是雙活的，雙邊環境只能連同一儲存。
2. 應用中，還有一些降級配置需要啟用的，需要在操作手冊中說清楚。
3. 確保主環境是關閉的，如果未關閉，確保與雙活環境連線的是同一儲存，JOB單邊跑的配置是正確的。
4. 為確保雙活環境在故障時，能起到容災作用。常規情況下，需要定期容災演練，確保方案可執行性。
   建議每季度一次，由運維決定。
5. 操作手冊，需要有詳細的回滾步驟，意外情況說明及應對措施。
6. 長期來看，我們需要將操作手冊中的手工操作內容，介面化，一鍵式自動化，自適應自驗證，幹掉操作手冊。
7. 主要挑戰和問題
   同城雙活帶來的架構複雜度，是空前的。

4.1 跨IDC時延和頻寬
觀瀾IDC與福田IDC是通過專線連線的，並且多層防火牆，網路吞吐能力、丟包率、網路效率肯定比不上IDC內部（目前，通過一些已經完成雙活應用的實踐，時延在8ms左右）。
這些問題對應用系統影響有多大？應用系統能否接受？應用需要在哪些地方，做什麼樣的改造或規避措施？這些暫時還沒有具體答案，因為沒有實踐，是很難想象出來的。
如果所有應用系統都做了雙活，且10%以上的流量匯入雙活環境，因為儲存單活存在大量的跨IDC訪問，這種情況下，IDC的間網路能力能否支撐？
這個目前也是估不出來的。
解決這個問題，短期就是儘量避免儘量減少跨IDC訪問；雙活環境在常規情況下，只匯入極小部分流量進入雙活環境（白名單/1%）；應用呼叫則按照“同IDC優先“的原則，避免跨IDC應用呼叫；容災切換時，進行“儲存切換"，完全避免跨IDC訪問。
長期，在常規情況下逐步加大匯入雙活環境的流量，持續監控觀察，持續應用優化改造，把這個問題解決掉或規避掉。
4.2 資料一致性
資料一致性是同城雙活的主要挑戰。為了確保資料一致性，我們只能做"應用雙活，儲存跨IDC同步(熱備)"。
儲存包括DB（mysql、Oracle、mongodb）、NAS、Redis、Zookeeper、ES、Hive等有資料存取能力的中介軟體。
每個儲存中介軟體，都需要對存入資料進行分析，分析資料丟失、資料不一致的容忍度，來決定它的雙活方案。
雙活方案中，也一定要把資料一致性的保障機制，描述情楚，執行到位。
在後續的一些同城雙活文章中，對各儲存中介軟體進行詳細剖析。
4.3 關聯應用未完成雙活
雙活環境的最終目標之一，是所有應用系統都做了雙活，雙活是一套完整的環境。
但受制於短期資源不足和團隊協同成本，必然有些應用先做雙活，有些應用後做雙活，就會存在應用做雙活時，部分關聯方不支援雙活。
這種情況下，進行入雙活環境的請求，在呼叫鏈路上，是需要調回觀瀾IDC(主環境)的。當容災切換，假定關聯方不可用，需要呼叫方評估並落實容錯降級機制。
關聯方呼叫存在同步（Dubbo、ESB）和非同步（MQ）兩種方式。在同城雙活-Dubbo篇，同城雙活-MQ篇，我們會做詳細的闡述。
4.4 防火牆問題
儲存會跨IDC訪問，應用會跨IDC呼叫，原本沒有防火牆的呼叫，現在可能有防火牆了。
需要對所有跨IDC的情況進行識別和整理，提前開通防火牆，並做好驗證。
4.5 版本釋出問題
雙活環境構建後，意味著生產有二套環境，雙活環境也要求與主環境（觀瀾IDC）的版本保持一致。
也就意味著應用包要釋出2次，先發預設環境（觀瀾IDC），再先發雙活環境（福田IDC）。
雙活環境的Pafa5配置中心、Apollo配置中心是獨立的。雙活環境的一些環境配置，容錯降級配置與主環境也不一樣，
所以，雙活環境是獨立一套配置檔案 ，意味著兩套配置檔案需要分別釋出到兩套環境。
這裡就需要釋出平臺(CD平臺)支援，我們將在“同城雙活-釋出篇”進行闡述。
4.6 福田IDC資源不足
雙活環境（福田IDC）短期資源不足，不足以支援所有應用系統立即全面展開雙活建設。如果小部分應用先做雙活，也很難起到業務容災的作用，也沒法全鏈路驗證。
但生產容災這個事，無論從監管要求，還是生產高可用，存在緊迫性，已經到了不可容忍的程度。這是個關鍵矛盾。
依據關鍵渠道的關鍵業務場景來驅動雙活建設的策略，有效解決了這個矛盾。
把關鍵渠道的關鍵業務場景（比如：口袋App的轉賬）識別出來，形成優先順序。再全鏈路識別涉及的強依賴（不可降級）應用系統，優先進行雙活建設。
這樣，即保障了關鍵業務的高可用，也有效推進行雙活建設。
4.7 架構複雜度問題
同城雙活提升了生產的高可用，但有得有失，它同時提升了架構複雜度。
架構複雜度增加是有成本的，運維成本、研發成本、架構管理成本、一致性高可用等技術保障成本，對研發團隊要求也就越高。
對高可用、一致性的要求，對業務的支撐，要與架構複雜度取得平衡。
所以，在支撐業務、高可用、一致性得到保障的前提下，架構能簡單則儘量簡單，不要搞一些花哨的東西。
各技術元件，也儘量選擇簡單的方案。
4.8 應用改造問題
為了支援雙活，應用可能需要進行一些程式碼改造來支援，比如：升級Pafa5版本，去NAS，MQ跨IDC消費、JOB改造遷到Horae等。
改造需要提需求、排期、開發、測試、上線，時間和投入成本不小。而且這類需求屬於技術改造類需求，取得業務方認可及取得較高優先順序，都不容易。
有些改造是致命且必須的，阻礙雙活建設的，有些則非必須的，所以需要區分開來，有策略有節奏地進行改造。
有個原則： 短期，儘量避免程式碼改造；能不改造，就不改造；非必須改造的，也不納入專案範圍。
長期，排優先順序，有策略有節奏地進行改造。
4.9 容災切換可執行
容災切換是一個很複雜的過程，涉及流量切換，也涉及儲存切換。包括”主環境切到雙活環境“，也包括”雙活環境切換到主環境”。
當故障發生，能不能很快完成：發現故障，切換決策，執行切換，恢復可用的整個過程，是個很大考驗。這個過程，任何環節出問題，都將達不到“容災恢復”的目的。
所以，生產切換演練，是確保切換可執行的最為重要一環，確保故障發生時，知道切，敢切，能切。
應該至少每個季度執行一次演練。
測試環境FAT102，作為容災切換演練的測試環境，至關重要。一定要在測試環境全鏈路模擬生產環境，演練清楚，問題整理清楚。
所以，大家要儘快構建好測試環境，進行全鏈路切換演練，把一些細節問題發現出來，並解決掉。
5. 總結
通過本文解讀，相信大家對同城雙活的目標、方案、挑戰已經有了基本的認識，後續我們會發布系列文章，進行更深入的解讀。
這裡，我們再強調一下：

1. 同城雙活建設是一個長期持續建設的事情，長短結合，拆分目標，分階段實施。
2. 每個應用系統，都要根據自身實際情況，制定可落地可執行雙活架構和方案。
3. 最大的挑戰在：容災切換，一定要在測試環境先演練清楚，確保生產可安全執行。
4. 在達成目標的前提下，儘量保持架構簡單，不要過渡設計。
   本文轉載至：https://www.modb.pro/db/52908