螞蟻金服 DB Mesh 的探索與實踐

支付寶技術團隊發表於2019-12-16

螞蟻金服資料訪問層有三個核心元件：資料訪問框架 ZDAL、 資料訪問代理 DBP  和 OceanBase 代理伺服器 OBProxy。本篇主要涉及 ZDAL 和 OBProxy 兩個元件。ZDAL 作為全站資料訪問的標準元件，不僅提供了分庫分表、讀寫分離、分散式 Sequence等標準的應用能力，還提供了鏈路跟蹤、影子壓測、單元化、容災切換等技術風險能力 。OBProxy 作為 OceanBase 的訪問入口，提供了 OceanBase 路由定址、讀寫分離等資料庫能力，同時從執行效率和資源成本角度考慮，從 OBProxy 誕生那天我們就採用了近應用的獨立程式部署模式，目前生產環境上保持在幾十萬級別的程式數。

本篇文章透過介紹當前螞蟻金服資料訪問層遇到的問題，解決的思路，演進的方向三個方面，期望能夠用闡述下 DB Mesh 發展的一些思考並讓更多同學認識到 DB Mesh。期望能夠 DB Mesh 的方式將資料訪問層下沉到統一的基礎設施之上，讓新業務快速使用上螞蟻金服內部多年的技術風險能力，並能夠持續享受到更多的效能、資源等技術紅利。

背景

隨著業務的快速發展，ZDAL 作為客戶端模式的元件，一直存在業務耦合、版本迭代推進、多語言支援等問題。OBProxy 是為 OceanBase 資料庫專門量身定製的代理伺服器，天然就是業務無耦合、支援多語言。使用者的資料在 OceanBase 上以多副本的形式存放在各個 OBServer 上，OBProxy 則負責接收使用者發過來的 SQL 請求，解析 SQL 請求並計算分割槽資訊後，將使用者請求轉發到最佳目標 OBServer 上，並將執行結果給使用者。在螞蟻金服內部也存在分庫分表元件 ZDAL，用在多 OceanBase 叢集以及單元化的場景。兩者配合使用，分庫分表元件 ZDAL 做業務層的流量調撥，OceanBase 分割槽功能支援資料庫的水平擴容能力。

螞蟻金服 DB Mesh 的探索與實踐

我們進一步看 ZDAL 和 OBProxy 這兩個元件的核心邏輯。

ZDAL 的核心邏輯：

  • SQL 解析器：獲得表名及分庫分表欄位；
  • 規則引擎：計算分庫分表結果；
  • 執行層：將 SQL 改寫發給資料庫，並做結果集合並使用者；


OBProxy 的核心邏輯：

  • 協議解析器：解析協議中的 SQL，Parse 後獲得表名及分割槽欄位；
  • 路由器：計算分割槽表所在的 OBServer；
  • IO 層：將請求轉發給 OBServer，將結果集返回給客戶端；


可以看出，OBProxy 和 ZDAL 這兩個元件的執行路徑有一定的重複度，比如兩個元件都做了 SQL 解析，並分析表名和欄位。這對效能帶來一定的損耗，而且這種重複給研發迭代帶來更多的工作量。

    螞蟻金服 DB Mesh 的探索與實踐

基於前面的考慮將 ZDAL 和 OBProxy 兩者合併成一個元件的是一個自然的方案，透過將 ZDAL 邏輯下沉到 OBProxy 中，讓 OBProxy 提供了分庫分表、讀寫分離、分散式序列等中介軟體能力，這個元件我們命名為 ODP（Open Database Proxy）。

ODP 作為近業務端部署的程式，雖然邏輯獨立出來，升級時但是依然需要去改動業務的容器，所以迭代過程中的升級推進工作也是比較費時費力，而且 ODP 只是整個產品的冰山一角，需要大量的精力來構建冰山之下的基礎設施，比如說如何解決 ODP 的運維問題、使用者透明切換的方案、複雜配置的推送問題、金融級資料庫金鑰管理問題等。我們發現這部分與螞蟻金服內部 大規模實踐的 ServiceMesh 遇到的問題有比較大的重合度，所以與 ServiceMesh 一起共建底層基礎設施，為這塊的完整產品方案命名為 DBMesh。下文會簡單介紹一下我們的演進路線和發展方向。

解決思路

Sidecar 模式解耦部署


從執行效率和資源成本角度考慮，OBProxy 在螞蟻金服一直都在採用近業務端部署的方式，日常保有的服務數在數十萬的級別。近業務端部署雖然提供了高效率，但是也帶來了運維上的複雜度，同時需要升級版本時，也需要和通知業務一起來做釋出和升級。要讓單個應用升級，基本都是按月計，如果涉及到全站層面的升級，時間基本不太好估算。

但是隨著雲原生以及 Kubernetes 的發展，讓 Sidecar 模式更為成熟，即在業務的容器旁邊再執行一個容器，這個非常貼合我們近業務端部署的 OBProxy 程式，只需要將 OBProxy 程式改造成 OBProxy Sidecar，即可進行獨立升級、釋出、運維等。同時螞蟻金服在雲原生領域有非常深的實踐，有著世界上最大規模的 Kubernetes 叢集和 ServiceMesh 叢集，將 OBProxy 變成 Sidecar 也是比較合理和方便實施的了。

螞蟻金服 DB Mesh 的探索與實踐

今年雙十一切了約 10% 的數萬個的 PODs 到 ODP Sidecar 模式，透過 Sidecar 的方式能夠讓業務快速享受到基礎軟體迭代的好處，本次雙十一 ODP 修復了一個非預期日誌列印導致某個機房出現 慢 SQL 問題，在傳統的本地程式方式，需要推動所有的業務進行拉迭代、釋出、打包時間週期基本不太可控。而今年讓所有涉及應用獨立的灰度、升級僅花費兩天時間。

合併重複邏輯拿技術紅利


解決了部署模式的問題，透過快速迭代並且獨立升級的方式，才能讓功能下沉的落地成為可能。我們將分庫分表元件的大多數功能都下沉到了 ODP 上，比如：分庫分表功能、讀寫分離功能、分散式 Sequence 功能、全鏈路跟蹤等。如下圖：

螞蟻金服 DB Mesh 的探索與實踐

整個分庫分表元件功能下沉之後，在今年雙十一我們在核心繫統上線，拿到了一些非常可觀的技術紅利：

  • 效能提升： 透過功能的合併可以省去額外的 SQL 解析和路由計算過程，雙十一上線的系統 SQL 平均響應時間可以下降上百微秒；
  • 啟動速度： 應用只需要和 ODP 建立連線即可，無需初始化多個分庫的資料來源，初始化時間從數十秒降到數十毫秒；
  • 記憶體下降： 和啟動速度一樣，由於應用和 ODP 的連線數減少了，同樣也可以節省應用端的記憶體使用，生產上能夠下降上百 MB；


共建 Mesh 基礎設施完善技術風險

螞蟻金服 DB Mesh 的探索與實踐

研發同學會將更多的關注點放在 ODP 資料鏈路上，如何提高資料平面的效能，如何增加更多的 SQL 特性，而會忽略非 SQL 執行鏈路上的訴求。DBMesh 作為應用側的基礎設施，更多的要考慮如何更好的管理 Sidecar、資料訪問高安全防控、滿足配置變更的三板斧要求、最大程度的節省資源成本等。

我們在與螞蟻金服 ServiceMesh 團隊共建整個雲原生下 Mesh 的技術風險能力，優先完善 Sidecar 的運維能力和變更三板斧能力，後續會將 ODP Sidecar 部署到宿主機上以最大程度最佳化 ODP 的資源佔用，也會逐步下沉更多如影子壓測、灰度機房、流量映象等的技術風險能力。

總結

DBMesh 讓資料訪問從客戶端模式切換到代理模式，給應用帶來了啟動速度的極大最佳化。Sidecar 的部署模式則是 SQL 平均響應時間、資源利用的最優模式。將更多的技術風險能力沉澱進來，讓新應用快速享受到金融級的技術風險能力，存量應用的技術風險指標更完善。我們期望透過統一的資料訪問基礎設施，讓業務都使用標準的技術元件，降低學習以及維護成本，僅專注在業務開發和創新上。

作者介紹


易鴻偉（花名：改之），螞蟻金服高階技術專家，負責資料中介軟體及 OceanBase 鏈路層方向的研發工作。主要技術關注在分散式資料庫、高效能伺服器、資料庫高可用、分散式事務、單元化架構等，並對微服務、雲原生、Mesh 等技術有一定的理解。

相關閱讀



來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69904796/viewspace-2668706/，如需轉載，請註明出處，否則將追究法律責任。

相關文章