對云原生環(huán)境下數(shù)據(jù)庫服務治理的思考
從服務治理到數(shù)據(jù)庫服務治理
微服務治理
對于從服務治理到數(shù)據(jù)庫服務治理，我們還是要先從微服務治理來切入。從單體到微服務，伴隨業(yè)務越來越復雜、越來越多元，以及基礎設施規(guī)模越來越大，服務之間的調用關系變得非常復雜。對于微服務的治理行為，還停留在流量控制、可觀測性、安全訪問、配置管理和高可用等幾個方面。要想讓微服務架構更快地上線和部署，一定要有一個自動化的框架。對于運維，我們也希望能夠盡可能的標準化。
這時候就出現(xiàn)了像 Kubernetes 這樣的容器編排框架。Kubernetes 源自于 Google 內部的 Borg，它帶了很多 Google 的大廠屬性。大廠不是說技術多么厲害，而是說它的規(guī)模非常大。只有在一個特別大的規(guī)模里，運維的復雜度才會體現(xiàn)出來，也就更加依賴于平臺或者工具去提高自動化能力。
這種自動化的能力，我們把它叫做基礎設施即代碼，只要是 SRE 的同學去寫一個這樣的配置文件，然后把文件提交給 Kubernetes ，Kubernetes 就會根據(jù)里面描述的行為去做相應指令，只不過這個指令是聲明式的 API，在這個過程中就完成了對應用的自動化上線。
講到 Kubernetes，如果成千上萬個節(jié)點，上面可能有十萬個pod，我們怎么去做它的服務治理？如果還沿用之前的服務發(fā)現(xiàn)框架，在兼容 Kubernetes 時多少會有一些水土不服。有沒有一種原生的方式去做 Kubernetes 之上的服務治理呢？這就是 Service Mesh。
Service Mesh
Service Mesh 是在2016年由 Linkerd 項目率先提出的。Service Mesh 把對服務治理的行為或者能力下沉到基礎設施。Service Mesh 可以認為它是一個對于服務治理行為的編排框架，我們通過一些聲明式的配置，讓 Service Mesh 去交付給基礎框架、基礎設施，去代理我們執(zhí)行相關任務。
服務網格有個特別典型的圖，就是下邊這個圖。我們可以假設藍色的就是我們的業(yè)務應用，而黃色的部分就是我們的服務網格代理。服務網格就是通過這樣一個透明代理，去把應用的所有流量接管，再去對它治理。它通過這種接管的方式，實現(xiàn)各種服務治理的能力，比如服務發(fā)現(xiàn)等等。
Istio 簡介
說到 Service Mesh，就必須提到 Istio 這個項目。2016年 Linkerd 對于 Service Mesh 的理解可能還不是特別成熟，我們把那個時候叫做第一代 Service Mesh。到 Istio 出現(xiàn)，才真正成為了現(xiàn)在我們所看到的 Service Mesh 架構， Istio 我們把它叫做第二代 Service Mesh。
Istio 的主要架構就是下邊的這張圖，它底下有一個 Control panel。Control panel 叫做控制面，這個控制面里面有 Istiod，在早期1.0的時候，Istiod 是由多個獨立組件構成的，比如說 Pilot、Galley、Citadel，它們分別去負責一些證書，比如可觀測性的聚合。它原來還有個 Mixer，還有各個 Pilot 相關的配置等等。
微服務治理和數(shù)據(jù)庫服務治理的異同
或許有人要問：既然 Istio 可以代理應用的流量，那么為什么我們還要去談一個數(shù)據(jù)庫的服務治理？我們完全可以讓 Istio 劫持我們數(shù)據(jù)庫的協(xié)議或者讓它去代理所有的數(shù)據(jù)庫流量，來實現(xiàn)治理的效果。
如果我們把數(shù)據(jù)庫看成微服務中的一個特殊微服務，它可能是服務鏈路的最后一環(huán)，我們確實是可以通過 Service Mesh 對數(shù)據(jù)庫進行訪問治理，包括服務發(fā)現(xiàn)這些能力。但是數(shù)據(jù)庫也有一些特殊的治理屬性或者要求，比如說數(shù)據(jù)庫的協(xié)議，它的 MySQL 協(xié)議或者說 PG 的協(xié)議或者 Redis 協(xié)議有特殊性。比如 MySQL 協(xié)議我們在建連的時候，是服務端會先給我們發(fā)一個包，還有就是資源管理，可能對于微服務之間業(yè)務的應用之間，我們不用太關心它在運行時所消耗的資源，它應該是整個服務的一個性能指標。
但對于數(shù)據(jù)庫來說，可能就會有些區(qū)別。它體現(xiàn)在可觀測性上的時候，比如數(shù)據(jù)庫的指標，它可能會涉及到慢 SQL 或者 SQL 延遲。
對于流量治理這部分，數(shù)據(jù)庫也有它的特殊性，不管是 Redis、MongoDB 還是 MySQL，我們去做分片的時候，很難單純只依靠于流量本身去做分發(fā)。如果我們隨意地去轉發(fā)相應請求，可能就會得到一個錯誤答案。
另外，對于像分庫分表這樣的場景來說，所謂的負載均衡是基于對數(shù)據(jù)屬性的判斷，不能粗暴的只是讓它隨機發(fā)到后面的不同數(shù)據(jù)源。
最后還有訪問控制，一般來說對于業(yè)務應用來說，我們是一個微服務級別的訪問控制，可能關聯(lián)到一個全局的認證或者身份授權，很多情況下我們需要一個表級別甚至是列級別的訪問控制，只有通過特殊的治理手段，才能夠實現(xiàn)這樣一些特殊的治理效果。
如何設計一個Mesh模型
從 Service Mesh 中學到的
我們還回到剛才所說的 Service Mesh，我們從 Service Mesh 中能學到什么呢？
第一，Service Mesh 是一個控制面和數(shù)據(jù)面分離的部署結構。
第二，如果我們把控制面和數(shù)據(jù)面的協(xié)議做了標準化，我們可以讓數(shù)據(jù)面有更多的選擇。
第三，我們可以通過 Kubernetes 機制去實現(xiàn)基礎設施即代碼的配置能力。
第四，可以通過插件去支持各種不同的協(xié)議擴展。
這個時候我們就會去想，數(shù)據(jù)庫的 Database Mesh 和我們 Service Mesh 之間是一個包含關系嗎？還是兩個完全不同的場景呢？
Database Mesh 概念的提出
在2018年的時候，ShardingSphere 的創(chuàng)始人張亮在他的《未來架構》這本書里面，其實設想過，如果將 Service Mesh 治理的思路應用到數(shù)據(jù)庫治理上，會是一個什么樣的效果？
ShardingSphere 這個項目主要是去做了數(shù)據(jù)庫流量的治理，比如說做分庫分表、做數(shù)據(jù)的加密、做數(shù)據(jù)的Scaling 等等。是不是可以存在一個 ShardingSphere 的 Sidecar，跟業(yè)務的應用部署在一起，就像下邊這張圖一樣，正常的業(yè)務請求通過 Service Mesh 去做微服務、業(yè)務之間的服務發(fā)現(xiàn)和相關的調用。對于數(shù)據(jù)庫的流量，通過 Sharding Sidecar 把它代理到數(shù)據(jù)庫，而整個 Sharding Sidecar 也是依賴于一個控制面去做相關的注冊和發(fā)現(xiàn)。
Sharding Sidecar 和 ShardingSphere 已有的 Proxy 和 JDBC 能力應該是一樣的，通過這種方式可以完美地屏蔽掉 JDBC 和 Proxy 的缺點。Sharding Sidecar 以 Sidecar 的方式部署在業(yè)務應用的旁邊，業(yè)務應用如果是分布式的或多副本的，那么它就會有多個副本。業(yè)務的應用和它之間的通信也可以實現(xiàn)這種語言上的解耦，而不用受限于具體的語言棧。這種架構是不是就是一個彈性伸縮+零侵入+去中心的云上基礎設施呢？
這是2018年的時候，關于 Database Mesh 的一個想法。
Database Mesh 的現(xiàn)狀
從2018年到現(xiàn)在這短短四年的時間里，Database Mesh 這個概念其實已經在很多公司得到了充分的探索和實踐。概括起來有三種典型的方案。
第一種，是 ShardingSphere Sidecar 的形式。把對數(shù)據(jù)庫治理的特性，以 Sidecar 的形式提供給業(yè)務的 Pod。
第二種，可能在一些大廠里會見得比較多，就是統(tǒng)一的 Mesh 管控。
第三種，叫做分布式數(shù)據(jù)庫。
這三種方式有一個共同點，就是它都關注于數(shù)據(jù)庫服務治理中流量治理的那一部分。我們如果把這個階段稱之為1.0階段，那么假設我們要去對它做一個升級，要做2.0，應該又有什么樣的特性呢？
Database Mesh 1.0 vs 2.0
我們在經過了充分思考之后，覺得應該有更多的擴展性和面向更好的用戶體驗，所以我們提出了 Database Mesh 2.0的概念。我們現(xiàn)在專門做了一個網站，它的口號就是“通過可編程，實現(xiàn)高性能的擴展，來應對云上數(shù)據(jù)庫的治理挑戰(zhàn)”。
我們希望通過這種可配置、可插拔或者可編程的方式，能夠實現(xiàn)一個覆蓋數(shù)據(jù)庫流量、運行時資源和穩(wěn)定性保障等方面的治理框架。不管是什么類型的數(shù)據(jù)庫，我們希望能夠有一個標準界面，然后去把它治理起來。這就是 Database Mesh 2.0所希望的能力。
對于 Database Mesh 2.0來說，其實特別要強調的一點就是，我們在做設計的時候，一直在想 Mesh 到底代表的是什么含義。其實最開始的時候，我們就會覺得 Sidecar 就是 Mesh，我們通過 Sidecar 和別的東西交互了，就構成一個網格，這個網格就是 Mesh。但是后來我們發(fā)現(xiàn)其實不是這個樣子，Mesh 的核心不是 Sidecar，Mesh 只是它的一種表現(xiàn)形式。
我們接下來就看 Database Mesh 2.0的全景圖。這個全景圖左半部分上面其實是按照用戶來分的，上面是 Developers，就是開發(fā)人員對于 Database Mesh 的感受是什么。而右側對于 SRE 或者 DBA 的同學來說，他們想看到的東西就比較多了，不管是訪問控制、審計、風控、可觀測性、事件。而右側對于 SRE 或者 DBA 的同學來說，他們想看到的東西就比較多了，不管是訪問控制、審計、風控、可觀測性、事件。
總結一下：
第一，Database Mesh 2.0里邊，我們認為數(shù)據(jù)庫是一等公民，所有的這些抽象都是圍繞數(shù)據(jù)庫進行的，也就是剛才我們所說的 VirtualDatabase。
第二，我們希望它是能夠面向工程師的體驗，不管是開發(fā)人員還是 SRE 還是 DBA，用關心數(shù)據(jù)庫實際的位置。
第三，云原生，它應該是一個天生面向云的環(huán)境，用戶不用擔心這個東西是廠商鎖定的。
如何利用 Kubernetes 實現(xiàn)數(shù)據(jù)庫 Mesh
最后這部分，我們就介紹一下我們如何利用 Kubernetes 去實現(xiàn)這樣一個模型。
Kubernetes 的擴展模式
Kubernetes 被稱為是平臺的平臺。我們在 Kubernetes 之上，之前也涌現(xiàn)出來好多創(chuàng)業(yè)公司和一些 PaaS 服務商，在它上面去構建各種各樣的能力。
Kubernetes 的擴展能力是它生命力的關鍵，它的第一種擴展模式叫做 Sidecar；第二個擴展模式是 AdmissionWebhook；第三個擴展模式，也是它特別厲害的一個能力，就是用戶自定義資源定義。
Pisanix 設計與實現(xiàn)
介紹完 Kubernetes 之后，我們就來看一下 ??Pisanix?? 這個項目。Pisanix 是 SphereEx 團隊對 Database Mesh 提供的一個解決方案。Pisanix 是由 Go 和 Rust 兩種語言編寫的，我們去適配了 Kubernetes 環(huán)境，目前支持 MySQL 的協(xié)議。
它有三個比較主要的組件：
- Pisa-Controller：Pisanix 這個項目的核心組件，Pisa-Controller 承擔的就是控制面，它是 Golang 實現(xiàn)的，是一個必選的組件。
- Pisa-Proxy：Pisa-Proxy 是負責代理流量的數(shù)據(jù)面，Pisa-Proxy 就是以 Sidecar 的形式部署在 Pod 里面，它是 Rust 實現(xiàn)的，它也是一個必選的組件。
- Pisa-Daemon（即將發(fā)布）：它是負責資源優(yōu)化的數(shù)據(jù)面，是一個 DaemonSet，是每一個 Kubernetes 集群的節(jié)點都會有一份 Daemon，它是一個可選的組件。
三個組件共同達到的效果：
第一，實現(xiàn)了SQL感知的流量治理。
第二，面向運行時的資源可編程。
第三，數(shù)據(jù)庫可靠性工程，也叫DRE。
我們會重點講一下 Pisa-Proxy。Pisa-Proxy 是我們最主要的一個核心組件，所有的能力其實都依賴于它，我們選擇了 Rust 而去實現(xiàn)它的一個主要原因，是因為 Rust 的生命力是非常頑強的。
Pisa-Proxy 可以看作是面向數(shù)據(jù)庫流量的負載均衡器，主要工作流程如下：
目前 Pisa-Proxy 支持 MySQL 協(xié)議，將自己偽裝為數(shù)據(jù)庫服務端，應用連接配置只需修改訪問地址即可建連：
- Pisa-Proxy 通過讀取應用發(fā)來的握手請求和數(shù)據(jù)包，得到應用希望執(zhí)行的 SQL。
- 對該 SQL 進行詞法和語法解析后得到對應 AST。
- 基于 AST 實現(xiàn)高級訪問控制和 SQL 防火墻能力。
- 訪問控制和防火墻通過后 SQL 提交執(zhí)行。
- SQL 執(zhí)行階段的指標將采集為 Prometheus Metrics。
- 根據(jù)負載均衡策略獲取執(zhí)行該語句的后端數(shù)據(jù)庫連接。
- 如果連接池為空將根據(jù)配置建立和后端數(shù)據(jù)庫的連接。
- SQL 將從該連接發(fā)往后端數(shù)據(jù)庫，并讀取相應返回結果。
- SQL 執(zhí)行結果進行組裝后返回給業(yè)務應用。
最后講到Pisa-Daemon。Pisa-Daemon 離不開 eBPF 技術。eBPF 現(xiàn)在比較火，eBPF 這個技術本身就像容器一樣，也不是特別新鮮的東西。
eBPF 是 Extended BPF 的簡稱，可以在 Linux 內核中構建沙箱并運行各種程序。eBPF 是一種安全和高效的內核擴展機制，常被用于：
- 可觀測性：eBPF 在內核態(tài)可以進行各種可觀測指標的采集，生成多樣化的圖表。
- 系統(tǒng)安全：通過 eBPF 可以觀測到所有的系統(tǒng)調用，配合對網絡包或套接字的管理以及進程上下文追蹤能力，實現(xiàn)更細粒度的安全控制。
- 網絡：eBPF 的編程擴展能力，天然適合對網絡流量包的處理過程，無需離開內核的網絡處理上下文。
- 追蹤和調優(yōu)：通過對用戶態(tài)進程以及系統(tǒng)調用的探測，實現(xiàn)零侵入的關聯(lián)追蹤和性能分析體驗。
對于 Pisa-Daemon 來說，號稱是做資源可編程，Pisa-Daemon 利用內核機制去提供資源方面的管理能力，這個資源就是運行時資源。通過 Pisa-Daemon 和 Pisa-Proxy 去做配合，我們可以標識不同優(yōu)先級業(yè)務出來的數(shù)據(jù)庫流量。
未來我們希望做成一種擴展機制，以可插拔或者可編程方式，支持更多種類型的運行時資源管理。
如何在 Kubernetes 中使用 Pisanix
最后我們可以看一下在 Kubernetes 里面如何去使用 Pisanix 這個項目。
Pisanix 既然是對于 Database Mesh 的一個實現(xiàn)，那么我們也沿用它的規(guī)范，首先我們使用了三種 CRD，這三種叫做 VirtualDatabase、TrafficStrategy 和 DatabaseEndpoint。
VirtualDatabase 就是我們前面介紹 Database Mesh 的時候，它的聚合根，它的所有對于 Database Mesh 治理的能力，都是體現(xiàn)在 VirtualDatabase 上面。
在 VirtualDatabase 里面有一個字段叫做 TrafficStrategy，標識對于這個數(shù)據(jù)庫的訪問來說，我們希望它以什么樣的策略去治理它。
那它 Random 到誰呢？就是在 TrafficStrategy 里面它有 Selector。Selector 通過 Label 去選擇后端的 DatabaseEndpoint。
這三個 CRD 就可以覆蓋這個業(yè)務應用對于后端數(shù)據(jù)源和對于 MySQL 代理的相關配置信息。接下來就是 Pisa-Controller 拿到 CRD，然后根據(jù)里面的配置內容轉化成 Pisa-Proxy 的配置，然后推給相應的 Sidecar。Pisa-Proxy 拿到這個配置，然后根據(jù)里面的內容將向后端實際的數(shù)據(jù)庫去建連，然后同時前端去監(jiān)聽端口，接收請求。最后對應用來說，它只要訪問里面配置的這個端口就可以實現(xiàn)了。
其實 Pisa-Proxy 我們也在思考它其實也是可以被單獨使用的，有的 Kubernetes 不是適用于每一個公司或者每一個業(yè)務，如果說也需要這種對于數(shù)據(jù)庫的治理，尤其對于流量這種統(tǒng)一接入的治理，其實是可以把 Pisa-Proxy 單獨拿出來去部署。這個時候的用法，就跟我們用一個 Nginx 組成一個集群是一樣的，不管后面你是什么樣的數(shù)據(jù)庫，比如你是 RDS 或者 TiDB、ShardingSphere，都可以由 Pisa-Proxy 做成數(shù)據(jù)庫的統(tǒng)一接入層，來對它做代理，實現(xiàn)這種比如無感的高可用切換，實現(xiàn)面向 SQL 的可觀測性等等。
