螞蟻金服資料通路層有三個核心元件：資料通路架構 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 等技術有一定的了解。