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

螞蟻金服數據訪問層有三個核心組件：數據訪問框架 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 分區功能支持數據庫的水平擴容能力。

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

ZDAL 的核心邏輯：

SQL 解析器：得到表名及分庫分表字段；
規則引擎：計算分庫分表結果；
執行層：將 SQL 改寫發給數據庫，並作結果集合並用戶；

OBProxy 的核心邏輯：

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

能夠看出，OBProxy 和 ZDAL 這兩個組件的執行路徑有必定的重複度，好比兩個組件都作了 SQL 解析，並分析表名和字段。這對性能帶來必定的損耗，並且這種重複給研發迭代帶來更多的工做量。

基於前面的考慮將 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 也是比較合理和方便實施的了。

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

合併重複邏輯拿技術紅利

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

整個分庫分表組件功能下沉以後，在今年雙十一咱們在覈心繫統上線，拿到了一些很是可觀的技術紅利：

性能提高：經過功能的合併能夠省去額外的 SQL 解析和路由計算過程，雙十一上線的系統 SQL 平均響應時間能夠降低上百微秒；
啓動速度：應用只須要和 ODP 創建鏈接便可，無需初始化多個分庫的數據源，初始化時間從數十秒降到數十毫秒；
內存降低：和啓動速度同樣，因爲應用和 ODP 的鏈接數減小了，一樣也能夠節省應用端的內存使用，生產上可以降低上百 MB；

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

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

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

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

做者介紹

易鴻偉（花名：改之），螞蟻金服高級技術專家，負責數據中間件及 OceanBase 鏈路層方向的研發工做。主要技術關注在分佈式數據庫、高性能服務器、數據庫高可用、分佈式事務、單元化架構等，並對微服務、雲原生、Mesh 等技術有必定的理解。

相關閱讀

螞蟻金服 Service Mesh 大規模落地系列 - 網關篇螞蟻金服 Service Mesh 大規模落地系列 - RPC 篇螞蟻金服 Service Mesh 大規模落地系列 - 運維篇螞蟻金服 Service Mesh 大規模落地系列 - 消息篇螞蟻金服 Service Mesh 大規模落地系列 - 核心篇Service Mesh 落地負責人親述：螞蟻金服雙十一四大考題