簡介：Dubbo 作為分布式微服務框架，眾多公司在實踐中基于 Dubbo 進行分布式系統架構，重啟開源后，我們不僅看到 Dubbo 3.0 最新的 Roadmap 發布，而且還看到阿里在自身電商開始推進 Dubbo 和內部 HSF 的融合，并在 雙11 上開始使用 Dubbo 3.0，本文是工商銀行基于 Dubbo 構建金融微服務架構的分享，主要講述了服務發現的應對策略和成果，后續將發布工行大規模服務監控治理的實踐，以及從企業角度怎么去對 Dubbo 二次開發等內容，歡迎關注，

作者 | 張遠征
來源|阿里巴巴云原生公眾號

導讀：Dubbo 作為分布式微服務框架，眾多公司在實踐中基于 Dubbo 進行分布式系統架構，重啟開源后，我們不僅看到 Dubbo 3.0 最新的 Roadmap 發布，而且還看到阿里在自身電商開始推進 Dubbo 和內部 HSF 的融合，并在 雙11 上開始使用 Dubbo 3.0，本文是工商銀行基于 Dubbo 構建金融微服務架構的分享，主要講述了服務發現的應對策略和成果，后續將發布工行大規模服務監控治理的實踐，以及從企業角度怎么去對 Dubbo 二次開發等內容，歡迎關注，

背景及概覽

工行傳統的業務系統一般都是基于 JEE 的單體架構，面對金融業務線上化及多樣化的發展趨勢，傳統架構已經無法滿足業務的需求，因此從 2014 年開始，工行選擇了一個業務系統做服務化的嘗試，并驗證、評估、對比了當時的幾個分布式服務框架，最終選擇了相對完善、并且國內已經有較多公司落地使用的 Dubbo，與此同時，工行還對 Dubbo 做了企業定制，幫助這個業務系統完成了服務化的落地，上線之后也收到了非常好的效果，

2015 年，工行開始擴大服務架構的落地范圍，一方面幫助傳統業務系統進行架構轉型，另一方面也逐漸沉淀了類似中臺的超大規模服務群組，支撐業務系統快速服務的組合和復用，隨著經驗積累，工行也不斷對 Dubbo 進行迭代優化和企業定制，同時圍繞服務也逐步打造了完善的服務生態體系，

2019 年，工行的微服務體系也正式升級為工行開放平臺核心銀行系統的關鍵能力之一，助力工行 IT 架構實作真正的分布式轉型，

工行的微服務體系組成如下圖所示：

• 基礎設施方面，不管是業務系統的服務節點，還是微服務平臺自身的作業節點，都已部署在工行的云平臺，
• 服務注冊發現方面，除了常規的服務注冊中心外，還配合部署了元資料中心，用于實作服務的按節點注冊發現，
• 服務配置方面，通過外部的分布式配置中心，以實作各類動態引數的統一管理和下發，
• 服務監控方面，實作對服務各類運行指標的統一采集和存盤，并與企業的監控平臺對接，
• 服務跟蹤方面，主要是用于實時跟蹤服務的整體鏈路，幫助業務系統快速定位故障點，并準確評估故障的影響范圍，
• 服務網關是為了滿足傳統業務系統訪問服務需求，在 Dubbo 服務訂閱及 RPC 能力之上，實作了新服務、新版本的自動發現、自動訂閱和協議轉換能力（HTTP 協議轉 RPC 協議），實作 7×24 小時不間斷運行，
• 服務治理平臺，提供給運維人員和開發測驗人員一個一站式的管理、監控、查詢的平臺，提升日常服務治理的效率，

最大的挑戰

經過工行多年的落地實踐，本文共總結了以下兩方面的最大挑戰：

• 性能容量方面，目前線上服務數（即 Dubbo 概念中的服務介面數），已超 2 萬，每個注冊中心上的提供者條目數（即每個服務的所有提供者累計），已超 70 萬，根據評估，未來需要能支撐 10 萬級別的服務數，以及每個注冊中心 500 萬級的提供者條目數，
• 高可用方面，工行的目標是：微服務平臺任何節點故障都不能影響線上交易，銀行的業務系統 7×24 小時運行，即使在版本投產時間窗內，各業務系統的投產時間也是相互錯開的，平臺自身節點要做升級，如何避免對線上交易帶來影響，特別是注冊中心的自身的版本更新，

本文將先從服務發現方面，來分享一下工行的應對策略及成效，

服務發現難點和優化

1. 入門

在 Dubbo 中，服務的注冊訂閱及呼叫是一個標準范式，服務的提供者初始化時注冊服務，服務消費者初始化時訂閱服務并獲取全量提供者串列，而運行期間，服務提供者發生變化時，服務消費者可獲取最新的提供者串列，消費者與提供者之間點對點 RPC 呼叫，呼叫程序不經注冊中心，

在注冊中心的選擇上，工行在 2014 年就選擇了 Zookeeper，Zookeeper 在業界的各類場景下有大規模的應用，并且支持集群化部署，節點間資料一致性通過 CP 模式保證，

在 Zookeeper 內部，Dubbo 會按服務建立不同的節點，每個服務節點下又有 providers、consumers、configurations 及 routers 四個位元組點：

• providers 臨時節點：記錄該服務提供者清單，提供方下線子節點就自動洗掉，通過 Zookeeper 的 watch 機制，消費者可以第一時間知道提供者清單發生了變化，
• consumers 臨時節點：記錄消費者的清單，主要用于服務治理時查詢消費者，
• configurations 持久節點：主要保存服務治理時需要調整的服務引數，
• routers：子節點為持久節點，主要用于配置服務的動態路由策略，

在線上生產環境，Zookeeper 分資料中心部署了多個集群，每個集群配置了 5 個選舉節點，若干個 Observer 節點，Observer 節點是 Zookeeper3.3.3 版本引入的一個新的節點型別，它不參與選舉，只聽取表決結果，其他能力則和 Follower 節點相同，Observer 節點有以下幾方面的好處：

• 分流網路壓力：隨著服務節點的增多，如果客戶端都連接選舉節點，對選舉節點來說需要消耗大量的 CPU 去處理網路連接和請求，但是選舉節點又無法任意水平擴容，選舉節點越多，事務投票程序就越長，對高并發寫性能是不利的，
• 降低跨城跨 DC 的注冊訂閱流量：當有 100 個消費者需要跨城訂閱同一個服務，Observer 可以統一處理這部分跨城網路流量，避免對城際間的網路帶寬帶來壓力，
• 客戶端隔離：可以將幾個 Observer 節點專門分配給某個重點應用使用，保障其網路流量隔離，

2. 問題分析

工行根據這幾年線上 Zookeeper 的使用心酸血淚史，總結了 Zookeeper 在作為服務注冊中心時面臨的問題：

• 隨著服務數量以及服務提供者節點的增加，服務推送的資料量會呈爆炸式增長，舉個例子，一個服務有 100 個提供者，當提供者啟動的時候，因為 Zookeeper 的 CP 特性，每上線一個提供者，消費者都會收到事件通知，并從 Zookeeper 來讀取這個服務的當前全部提供者的串列，然后重繪本地快取，這個場景下，理論上每個消費者總共收到了 100 次事件通知，并從 Zookeeper 讀取了 100 次服務提供者串列，1+2+3+...+100，總計 5050 條提供者資料，這在業務系統投產高峰期問題尤為突出，容易導致 Zookeeper 集群的網路被打滿，造成服務訂閱效率極其低下，并進一步影響了服務注冊的性能，
• 隨著寫在 Zookeeper 上節點數量的增多，Zookeeper 的 snapshot 檔案也不斷變大，每次 snapshot 寫入磁盤，會出現一次磁盤 IO 沖高，投產高峰期，因為事務量大，寫 snapshot 檔案的頻率也非常高，這對基礎設施帶來了較大的風險，同時 snapshot 檔案越大，也預示著 Zookeeper 節點故障后恢復的時間越長，
• 當 Zookeeper 選舉節點發生重新選舉后，Observer 節點都要從新的 Leader 節點同步全量事務，這個階段如果耗時過長，就很容易導致連接在 Observer 節點上的客戶端 session 超時，使對應 providers 節點下的臨時節點全部被洗掉，即從注冊中心角度看，這些服務都下線了，消費者端則出現無提供方的例外報錯，緊接著，這些提供者會重新連接 Zookeeper 并重新注冊服務，這種短時間內大批量服務的注冊翻轉現象，往往帶來更為嚴重的服務注冊推送的性能問題，

綜上，可以得出的結論是：總體上 Zookeeper 作為注冊中心還是比較稱職的，但在更大規模服務量場景下，需要進一步優化，

3. 優化方案

工行最主要的優化措施包括下面這幾方面：訂閱延遲更新、注冊中心采取 multiple 模式、升級到按節點注冊等，

1）訂閱延遲更新

工行對 Zookeeper 客戶端組件 zkclient 做了優化，把消費者收到事件通知后獲取提供者串列做了一個小的延時，

當 zkclient 收到 childchange 一次性的事件后，installWatch() 通過 EventThread 去恢復對節點的監聽，同時又使用 getChildren() 去讀取節點下的全部子節點獲取提供者串列，并重繪本地服務提供者快取，這就是前面說的“5050 條資料”問題的根源，

工行在 zkclient 收到 childchange() 的事件后，做了個等待延遲，再讓 installWatch() 去做它原來該做的事情，這個等待程序中如果服務提供者發生變化，則不產生 childchange 事件，

有人會問，這是不是違背了 zookeeper 的 CP 模型呢，其實并不是，zookeeper 服務端的資料是強一致的，消費者也收到了事件通知，只是延后去讀取提供者清單，后面執行 getChildren() 時，讀取到的已經是 zookeeper 上的最新資料，所以是沒有問題的，

內部壓測結果顯示，服務提供者大規模上線時，優化前，每個消費者收到了總計 422 萬個提供者節點的資料量，而延遲 1 秒處理后，這個資料量則變成了 26 萬，childchange 事件次數和網路流量都變成了原來的 5% 左右，做完這個優化，就能從容應對投產高峰期大量服務的上下線，

2）Multiple 模式

工行采納并優化改造了 Dubbo 新版本中 registry-multiple 的 SPI 實作，用于優化多注冊中心場景下的服務訂閱，

Dubbo 中服務消費者原有處理邏輯是這樣：當存在多個注冊中心的時候，消費者按注冊中心對應的 invoker 快取去篩選提供方，第一個注冊中心對應的快取中如果沒找到，則去找第二個注冊中心對應的快取，如果此時第一個注冊中心出現可用性問題，推送給消費者的資料有缺失，甚至為空，就會影響消費者的這個篩選程序，如出現無提供方的例外、呼叫負載不均衡等，

而 multiple 注冊中心是把多個注冊中心推送的資料合并后再更新快取，所以即使單個注冊中心故障，推送了資料不完整或者為空，只要有其他任意一個注冊中心的資料使完整的，就不會影響最后合并的資料，

并且，multiple 注冊中心機制也用于異構的注冊中心場景，出現問題可以隨時把注冊中心下線，這個程序對服務節點的服務呼叫則完全透明，比較適合灰度試點或者應急切換，

更進一步，還有額外的收益，消費者端 Reference 物件是比較占用 JVM 記憶體，通過 multiple 注冊中心模式，可以幫消費者端節省一半的 invoker 物件開銷，因此，非常推薦多個注冊中心場景采用 multiple 模式，

3）按節點注冊

工行反向移植 Dubbo2.7 及 Dubbo3.0 的服務發現邏輯，使用“按節點注冊”的服務注冊-發現模型，這里即配置中心、元資料中心、注冊中心這個鐵三角組合：

• 配置中心：主要用來存盤節點級別的動態引數，以及服務的原來寫在 Zookeeper 上的 configurations 和 routers 這些持久節點的資料，
• 元資料中心：存盤節點元資料，也就是每個服務節點名稱（也就是 applicaiton-name）和其提供的服務的映射關系，以及每個服務的類定義資訊，比如每個方法的輸入輸出引數資訊，
• 注冊中心：此時注冊中心則只需要存盤服務提供者節點名稱和實際 ip 埠的關系，

這個模型的變化，對于消費者的服務呼叫則沒有任何影響，消費者端根據元資料中心上“服務節點名稱”與“服務”的關系，以及注冊中心“服務節點名稱”與實際 ip 埠的關系，生成兼容存量模式的服務提供方 invoker 快取，

壓測結果顯示，按節點注冊可以讓注冊中心上的資料量變成原來的 1.68%，這對量就對線上的 Zookeeper 來說毫無壓力，10 萬級別的服務量和 10 萬級別的節點量都能夠輕松支撐，

未來的規劃

未來，工行也希望能有機會走出去，深度參與到社區中，把自身在 Dubbo、Zookeeper 服務端、zkclient 上的好的 feature 貢獻出來，比如除了上面的優化點外，工行還在 Dubbo 上做了 RPC 結果的精細化識別，PAAS 的適配，同埠多協議、自隔離等能力，還在 Zookeeper 上增加了注冊熔斷機制，同時正在研究 Observer 的同步機制避免資料全量同步帶來的一系列問題，

另外，從微服務的發展看，Mesh 已經是目前的熱點之一，工行的痛點主要在服務 SDK 版本升級上，Istio 不爭氣，MCP 生死未卜，如何能讓存量 Dubbo 服務平滑過渡到 MESH 架構，目前已經有初步的方案，但還有非常多的技術難關需要克服，

歡迎 Dubbo 有實踐的同學們一起來探討大規模場景下的問題和心得，共同把 Dubbo 的企業落地做的更好！

更多企業落地實踐內容，可下載云原生架構白皮書了解詳情！

原文鏈接：https://developer.aliyun.com/article/779740?

著作權宣告：本文內容由阿里云實名注冊用戶自發貢獻，著作權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任，具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》，如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻洗掉涉嫌侵權內容，