文｜顏高飛【工商銀行】
金融科技研究院雲計算實驗室
本文 2651字 閱讀5分鐘
前言
中國工商銀行於 2014 年率先啓動銀行核心業務系統的分佈式架構轉型探索，自主研發了同業領先的分佈式服務平臺。
註冊中心爲服務平臺提供了核心的服務發現功能，其健壯性對服務調用的成功率起着至關重要的作用。近年來，隨着服務架構落地範圍迅速擴大，註冊中心性能容量支撐能力面臨更高挑戰。
工商銀行結合金融業實際運行場景，對註冊中心架構進行了深度定製及優化，不斷探索性能容量和高可用能力極限。
PART. 1
問題及挑戰
工商銀行分佈式服務平臺選用 zookeeper ****作爲分佈式服務註冊中心。
zookeeper 在業界分佈式系統中使用廣泛，具有大規模應用場景，爲用戶提供高效、穩定的分佈式協調服務。zookeeper 支持集羣化部署、性能可擴展，可用性也較高，主要表現有：
1、半數存活即可用特性，使其容災性能較強
只要選舉節點中有過半節點正常工作，集羣即可正常對外提供服務。若集羣內個別服務器宕機，客戶端會自動切換連接至其他可用服務器。
2、會話機制，使客戶端註冊信息保持穩定
客戶端與 zookeeper 服務端之間通過心跳保持會話，默認會話超時 40s。若集羣正常對外服務，在會話超時後，zookeeper 服務端將剔除客戶端註冊信息。而若集羣整體不可用，會話不會過期，在註冊中心集羣恢復後，能自動從快照中重新恢復故障前的會話和註冊信息，無需外部干預。
3、集羣提供 observer 機制
實現讀寫分離、流量隔離
observer 節點不參與集羣選舉，只承擔客戶端連接和請求，提升整體吞吐量；分擔選舉節點壓力，提升集羣穩定性。在實施 observer 分組的情況下，還可實現客戶端流量隔離。
在金融業務實際運行場景中，工商銀行搭建了以選舉節點爲核心、擴展部署 observer 節點的 zookeeper 註冊中心集羣，並在工商銀行穩定運行多年。
理論上，當 zookeeper 註冊中心集羣出現故障時，服務調用不會受到影響。
但在實際混沌工程故障演練過程中，我們發現：偶發場景下，分佈式服務平臺存在因 zookeeper 系統資源故障或其他問題導致影響業務交易的現象。
具體問題列舉如下：
- 問題一：
單服務擴容後提供方節點數過多
觸及 zookeeper 推送報文 4M 的上限，從而導致 zookeeper 服務器性能壓力過大，未能及時處理其他服務註冊請求，影響交易。
- 問題二：
zookeeper 集羣 leader 服務器內存故障
進程僵死後集羣重新選舉產生新 leader，但集羣內部分服務器未及時感知新 leader，導致部分服務提供方掉線，影響交易。
- 問題三：
zookeeper 註冊數據大幅增大後
集羣故障重新選舉後 leader 向其他節點同步的數據量過大，服務器網絡到達瓶頸，導致部分服務器未及時加入新集羣，影響交易。
基於以上問題，工商銀行一方面對 zookeeper 源碼進行了深度定製，另一方面開始着手研究提升服務註冊和服務發現高可用能力的機制。
PART. 2
建設多註冊多訂閱機制
提升服務調用穩定性
爲規避單註冊中心集羣故障而影響服務調用的問題，工商銀行構建了多點接入的高可用註冊模型 （如圖 1 所示）。
圖 1 分佈式服務高可用註冊模型
說明：上圖中 DC1 和 DC2 爲 2 個機房，分別部署有 2 個獨立的註冊中心集羣。DC1 和 DC2 中部署的提供方和消費方均註冊、訂閱自兩個註冊中心集羣。DC1 中的消費方優先使用 DC1 註冊中心推送的提供方列表，DC2 中的消費方優先使用 DC2 註冊中心推送的提供方列表。
在同城雙機房內獨立部署兩個 zookeeper 集羣，提供方註冊服務至雙註冊中心，消費方也從雙註冊中心訂閱服務。消費方優先使用與其在同一機房內的註冊中心推送的數據，當同機房註冊中心集羣發生故障時，其他機房的註冊中心可接管。註冊中心集羣故障接管過程中，服務正常調用。
雙註冊雙訂閱機制建成後，分佈式服務平臺多次完美應對了底層系統資源故障、網絡隔離等問題，分佈式服務註冊和服務發現穩定性顯著提升。
基於雙 zookeeper 集羣部署的雙活架構，因雙集羣註冊中心組件技術棧相同，極小概率下仍存在系統性交易風險——若兩個 zookeeper 註冊中心集羣在同一時刻均出現同一類型故障時 （ 比如同時達到性能瓶頸） ，業務交易仍然可能會受到影響。
因此，爲規避極小概率的系統性風險，工商銀行進一步開展異構註冊中心建設，追求極致的服務註冊和發現高可用能力。
PART. 3
建設異構註冊中心 規避單一技術棧風險
註冊中心異構部署，進一步提升高可用能力
工商銀行開展異構註冊中心建設，在部署 zookeeper 集羣的同時對等部署一套獨立的異構註冊中心集羣。業務系統同時向 zookeeper 和異構註冊中心兩個集羣註冊並進行服務訂閱 （如圖 2 所示） 。
圖 2 異構註冊模型
異構註冊中心與 zookeeper 協同工作，提升註冊中心整體對外服務能力。當 zookeeper 集羣與異構註冊中心任一集羣發生系統性故障時，另一註冊中心集羣可接管 （如圖 3 所示數據表結構） 。
圖 3 異構註冊模型下任一註冊中心集羣故障
說明：上圖中 zookeeper 集羣故障，異構註冊中心正常工作，服務仍可正常註冊、訂閱及調用。
提出合併訂閱機制，
使註冊中心故障時遷移更加平滑
工商銀行原有多註冊中心訂閱機制，消費方優先使用某一註冊中心推送的提供方列表，僅當該註冊中心上無任一可用提供方，消費方纔切換使用下一註冊中心推送的數據。此時若優先使用的註冊中心因故障推送了不完整的提供方列表，消費方集中調用這些提供方，可能導致“提供方負載不均”、“觸發併發限流”等問題。
爲保障建設異構註冊中心後註冊中心故障時遷移更加平滑，工商銀行研究並提出了消費方合併訂閱機制： 在消費方側合併 zookeeper 和異構註冊中心的訂閱視圖，各註冊中心訂閱數據合併後再刷新 invoker 緩存。
即使某註冊中心故障推送了空或者不完整的提供方列表，合併後的數據仍是有效的，提高了消費方篩選提供方的效率，提升交易成功率。
圖 4 多註冊中心合併訂閱機制
註冊中心異構部署和消費方合併訂閱機制建成後，混沌模擬註冊中心 CPU 滿載、內存高負荷、磁盤故障、網絡抖動、網絡隔離等故障場景，提供方負載均衡，交易無失敗，符合預期。同時，合併訂閱機制還能額外降低多註冊中心模式下消費方緩存提供方列表所佔用的內存。
基於以上技術儲備及基礎建設，工商銀行於 2020 年開展異構註冊中心建設，規避行內註冊中心單一技術棧風險，進一步提升了註冊中心核心組件在整個分佈式體系中的高可用能力。
PART. 4
未來展望
爲滿足分佈式服務平臺金融級高可用的需求，工商銀行探索並提出異構註冊高可用方案，消除了大規模服務註冊場景下單一註冊中心存在的系統性風險，保障金融系統的穩健運行。
未來，工商銀行將在異構註冊的基礎上進一步推動單元化部署運維轉型，打破註冊中心爲全局唯一流量樞紐的現狀，實現交易流量在單元內部最大限度完成閉環，輔以單元自動切換實現故障隔離，進一步控制區域性故障場景下的故障爆炸半徑，全面提升分佈式服務平臺流量控制、高可用接管能力，爲同業微服務架構規模化應用提供最佳實踐和範例。
