神武八荒一颗小说,耳根

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

對創(chuàng)新互聯(lián)環(huán)境下數(shù)據(jù)庫服務(wù)治理的思考

??想了解更多關(guān)于開源的內(nèi)容，請?jiān)L問：??

目前累計(jì)服務(wù)客戶千余家，積累了豐富的產(chǎn)品開發(fā)及服務(wù)經(jīng)驗(yàn)。以網(wǎng)站設(shè)計(jì)水平和技術(shù)實(shí)力，樹立企業(yè)形象，為客戶提供成都做網(wǎng)站、成都網(wǎng)站制作、網(wǎng)站策劃、網(wǎng)頁設(shè)計(jì)、網(wǎng)絡(luò)營銷、VI設(shè)計(jì)、網(wǎng)站改版、漏洞修補(bǔ)等服務(wù)。創(chuàng)新互聯(lián)始終以務(wù)實(shí)、誠信為根本，不斷創(chuàng)新和提高建站品質(zhì)，通過對領(lǐng)先技術(shù)的掌握、對創(chuàng)意設(shè)計(jì)的研究、對客戶形象的視覺傳遞、對應(yīng)用系統(tǒng)的結(jié)合，為客戶提供更好的一站式互聯(lián)網(wǎng)解決方案，攜手廣大客戶，共同發(fā)展進(jìn)步。

?? 開源基礎(chǔ)軟件社區(qū)??

??https://ost.??

從服務(wù)治理到數(shù)據(jù)庫服務(wù)治理

微服務(wù)治理

對于從服務(wù)治理到數(shù)據(jù)庫服務(wù)治理，我們還是要先從微服務(wù)治理來切入。從單體到微服務(wù)，伴隨業(yè)務(wù)越來越復(fù)雜、越來越多元，以及基礎(chǔ)設(shè)施規(guī)模越來越大，服務(wù)之間的調(diào)用關(guān)系變得非常復(fù)雜。對于微服務(wù)的治理行為，還停留在流量控制、可觀測性、安全訪問、配置管理和高可用等幾個方面。要想讓微服務(wù)架構(gòu)更快地上線和部署，一定要有一個自動化的框架。對于運(yùn)維，我們也希望能夠盡可能的標(biāo)準(zhǔn)化。

這時候就出現(xiàn)了像 Kubernetes 這樣的容器編排框架。Kubernetes 源自于 Google 內(nèi)部的 Borg，它帶了很多 Google 的大廠屬性。大廠不是說技術(shù)多么厲害，而是說它的規(guī)模非常大。只有在一個特別大的規(guī)模里，運(yùn)維的復(fù)雜度才會體現(xiàn)出來，也就更加依賴于平臺或者工具去提高自動化能力。

這種自動化的能力，我們把它叫做基礎(chǔ)設(shè)施即代碼，只要是 SRE 的同學(xué)去寫一個這樣的配置文件，然后把文件提交給 Kubernetes ，Kubernetes 就會根據(jù)里面描述的行為去做相應(yīng)指令，只不過這個指令是聲明式的 API，在這個過程中就完成了對應(yīng)用的自動化上線。

講到 Kubernetes，如果成千上萬個節(jié)點(diǎn)，上面可能有十萬個pod，我們怎么去做它的服務(wù)治理？如果還沿用之前的服務(wù)發(fā)現(xiàn)框架，在兼容 Kubernetes 時多少會有一些水土不服。有沒有一種原生的方式去做 Kubernetes 之上的服務(wù)治理呢？這就是 Service Mesh。

Service Mesh

Service Mesh 是在2016年由 Linkerd 項(xiàng)目率先提出的。Service Mesh 把對服務(wù)治理的行為或者能力下沉到基礎(chǔ)設(shè)施。Service Mesh 可以認(rèn)為它是一個對于服務(wù)治理行為的編排框架，我們通過一些聲明式的配置，讓 Service Mesh 去交付給基礎(chǔ)框架、基礎(chǔ)設(shè)施，去代理我們執(zhí)行相關(guān)任務(wù)。

服務(wù)網(wǎng)格有個特別典型的圖，就是下邊這個圖。我們可以假設(shè)藍(lán)色的就是我們的業(yè)務(wù)應(yīng)用，而黃色的部分就是我們的服務(wù)網(wǎng)格代理。服務(wù)網(wǎng)格就是通過這樣一個透明代理，去把應(yīng)用的所有流量接管，再去對它治理。它通過這種接管的方式，實(shí)現(xiàn)各種服務(wù)治理的能力，比如服務(wù)發(fā)現(xiàn)等等。

Istio 簡介

說到 Service Mesh，就必須提到 Istio 這個項(xiàng)目。2016年 Linkerd 對于 Service Mesh 的理解可能還不是特別成熟，我們把那個時候叫做第一代 Service Mesh。到 Istio 出現(xiàn)，才真正成為了現(xiàn)在我們所看到的 Service Mesh 架構(gòu)， Istio 我們把它叫做第二代 Service Mesh。

Istio 的主要架構(gòu)就是下邊的這張圖，它底下有一個 Control panel。Control panel 叫做控制面，這個控制面里面有 Istiod，在早期1.0的時候，Istiod 是由多個獨(dú)立組件構(gòu)成的，比如說 Pilot、Galley、Citadel，它們分別去負(fù)責(zé)一些證書，比如可觀測性的聚合。它原來還有個 Mixer，還有各個 Pilot 相關(guān)的配置等等。

微服務(wù)治理和數(shù)據(jù)庫服務(wù)治理的異同

或許有人要問：既然 Istio 可以代理應(yīng)用的流量，那么為什么我們還要去談一個數(shù)據(jù)庫的服務(wù)治理？我們完全可以讓 Istio 劫持我們數(shù)據(jù)庫的協(xié)議或者讓它去代理所有的數(shù)據(jù)庫流量，來實(shí)現(xiàn)治理的效果。

如果我們把數(shù)據(jù)庫看成微服務(wù)中的一個特殊微服務(wù)，它可能是服務(wù)鏈路的最后一環(huán)，我們確實(shí)是可以通過 Service Mesh 對數(shù)據(jù)庫進(jìn)行訪問治理，包括服務(wù)發(fā)現(xiàn)這些能力。但是數(shù)據(jù)庫也有一些特殊的治理屬性或者要求，比如說數(shù)據(jù)庫的協(xié)議，它的 MySQL 協(xié)議或者說 PG 的協(xié)議或者 Redis 協(xié)議有特殊性。比如 MySQL 協(xié)議我們在建連的時候，是服務(wù)端會先給我們發(fā)一個包，還有就是資源管理，可能對于微服務(wù)之間業(yè)務(wù)的應(yīng)用之間，我們不用太關(guān)心它在運(yùn)行時所消耗的資源，它應(yīng)該是整個服務(wù)的一個性能指標(biāo)。

但對于數(shù)據(jù)庫來說，可能就會有些區(qū)別。它體現(xiàn)在可觀測性上的時候，比如數(shù)據(jù)庫的指標(biāo)，它可能會涉及到慢 SQL 或者 SQL 延遲。

對于流量治理這部分，數(shù)據(jù)庫也有它的特殊性，不管是 Redis、MongoDB 還是 MySQL，我們?nèi)プ龇制臅r候，很難單純只依靠于流量本身去做分發(fā)。如果我們隨意地去轉(zhuǎn)發(fā)相應(yīng)請求，可能就會得到一個錯誤答案。

另外，對于像分庫分表這樣的場景來說，所謂的負(fù)載均衡是基于對數(shù)據(jù)屬性的判斷，不能粗暴的只是讓它隨機(jī)發(fā)到后面的不同數(shù)據(jù)源。

最后還有訪問控制，一般來說對于業(yè)務(wù)應(yīng)用來說，我們是一個微服務(wù)級別的訪問控制，可能關(guān)聯(lián)到一個全局的認(rèn)證或者身份授權(quán)，很多情況下我們需要一個表級別甚至是列級別的訪問控制，只有通過特殊的治理手段，才能夠?qū)崿F(xiàn)這樣一些特殊的治理效果。

如何設(shè)計(jì)一個Mesh模型

從 Service Mesh 中學(xué)到的

我們還回到剛才所說的 Service Mesh，我們從 Service Mesh 中能學(xué)到什么呢？

第一，Service Mesh 是一個控制面和數(shù)據(jù)面分離的部署結(jié)構(gòu)。

第二，如果我們把控制面和數(shù)據(jù)面的協(xié)議做了標(biāo)準(zhǔn)化，我們可以讓數(shù)據(jù)面有更多的選擇。

第三，我們可以通過 Kubernetes 機(jī)制去實(shí)現(xiàn)基礎(chǔ)設(shè)施即代碼的配置能力。

第四，可以通過插件去支持各種不同的協(xié)議擴(kuò)展。

這個時候我們就會去想，數(shù)據(jù)庫的 Database Mesh 和我們 Service Mesh 之間是一個包含關(guān)系嗎？還是兩個完全不同的場景呢？

Database Mesh 概念的提出

在2018年的時候，ShardingSphere 的創(chuàng)始人張亮在他的《未來架構(gòu)》這本書里面，其實(shí)設(shè)想過，如果將 Service Mesh 治理的思路應(yīng)用到數(shù)據(jù)庫治理上，會是一個什么樣的效果？

ShardingSphere 這個項(xiàng)目主要是去做了數(shù)據(jù)庫流量的治理，比如說做分庫分表、做數(shù)據(jù)的加密、做數(shù)據(jù)的Scaling 等等。是不是可以存在一個 ShardingSphere 的 Sidecar，跟業(yè)務(wù)的應(yīng)用部署在一起，就像下邊這張圖一樣，正常的業(yè)務(wù)請求通過 Service Mesh 去做微服務(wù)、業(yè)務(wù)之間的服務(wù)發(fā)現(xiàn)和相關(guān)的調(diào)用。對于數(shù)據(jù)庫的流量，通過 Sharding Sidecar 把它代理到數(shù)據(jù)庫，而整個 Sharding Sidecar 也是依賴于一個控制面去做相關(guān)的注冊和發(fā)現(xiàn)。

Sharding Sidecar 和 ShardingSphere 已有的 Proxy 和 JDBC 能力應(yīng)該是一樣的，通過這種方式可以完美地屏蔽掉 JDBC 和 Proxy 的缺點(diǎn)。Sharding Sidecar 以 Sidecar 的方式部署在業(yè)務(wù)應(yīng)用的旁邊，業(yè)務(wù)應(yīng)用如果是分布式的或多副本的，那么它就會有多個副本。業(yè)務(wù)的應(yīng)用和它之間的通信也可以實(shí)現(xiàn)這種語言上的解耦，而不用受限于具體的語言棧。這種架構(gòu)是不是就是一個彈性伸縮+零侵入+去中心的云上基礎(chǔ)設(shè)施呢？

這是2018年的時候，關(guān)于 Database Mesh 的一個想法。

Database Mesh 的現(xiàn)狀

從2018年到現(xiàn)在這短短四年的時間里，Database Mesh 這個概念其實(shí)已經(jīng)在很多公司得到了充分的探索和實(shí)踐。概括起來有三種典型的方案。

第一種，是 ShardingSphere Sidecar 的形式。把對數(shù)據(jù)庫治理的特性，以 Sidecar 的形式提供給業(yè)務(wù)的 Pod。

第二種，可能在一些大廠里會見得比較多，就是統(tǒng)一的 Mesh 管控。

第三種，叫做分布式數(shù)據(jù)庫。

這三種方式有一個共同點(diǎn)，就是它都關(guān)注于數(shù)據(jù)庫服務(wù)治理中流量治理的那一部分。我們?nèi)绻堰@個階段稱之為1.0階段，那么假設(shè)我們要去對它做一個升級，要做2.0，應(yīng)該又有什么樣的特性呢？

Database Mesh 1.0 vs 2.0

我們在經(jīng)過了充分思考之后，覺得應(yīng)該有更多的擴(kuò)展性和面向更好的用戶體驗(yàn)，所以我們提出了 Database Mesh 2.0的概念。我們現(xiàn)在專門做了一個網(wǎng)站，它的口號就是“通過可編程，實(shí)現(xiàn)高性能的擴(kuò)展，來應(yīng)對云上數(shù)據(jù)庫的治理挑戰(zhàn)”。

我們希望通過這種可配置、可插拔或者可編程的方式，能夠?qū)崿F(xiàn)一個覆蓋數(shù)據(jù)庫流量、運(yùn)行時資源和穩(wěn)定性保障等方面的治理框架。不管是什么類型的數(shù)據(jù)庫，我們希望能夠有一個標(biāo)準(zhǔn)界面，然后去把它治理起來。這就是 Database Mesh 2.0所希望的能力。

對于 Database Mesh 2.0來說，其實(shí)特別要強(qiáng)調(diào)的一點(diǎn)就是，我們在做設(shè)計(jì)的時候，一直在想 Mesh 到底代表的是什么含義。其實(shí)最開始的時候，我們就會覺得 Sidecar 就是 Mesh，我們通過 Sidecar 和別的東西交互了，就構(gòu)成一個網(wǎng)格，這個網(wǎng)格就是 Mesh。但是后來我們發(fā)現(xiàn)其實(shí)不是這個樣子，Mesh 的核心不是 Sidecar，Mesh 只是它的一種表現(xiàn)形式。

我們接下來就看 Database Mesh 2.0的全景圖。這個全景圖左半部分上面其實(shí)是按照用戶來分的，上面是 Developers，就是開發(fā)人員對于 Database Mesh 的感受是什么。而右側(cè)對于 SRE 或者 DBA 的同學(xué)來說，他們想看到的東西就比較多了，不管是訪問控制、審計(jì)、風(fēng)控、可觀測性、事件。而右側(cè)對于 SRE 或者 DBA 的同學(xué)來說，他們想看到的東西就比較多了，不管是訪問控制、審計(jì)、風(fēng)控、可觀測性、事件。

總結(jié)一下：

第一，Database Mesh 2.0里邊，我們認(rèn)為數(shù)據(jù)庫是一等公民，所有的這些抽象都是圍繞數(shù)據(jù)庫進(jìn)行的，也就是剛才我們所說的 VirtualDatabase。

第二，我們希望它是能夠面向工程師的體驗(yàn)，不管是開發(fā)人員還是 SRE 還是 DBA，用關(guān)心數(shù)據(jù)庫實(shí)際的位置。

第三，云原生，它應(yīng)該是一個天生面向云的環(huán)境，用戶不用擔(dān)心這個東西是廠商鎖定的。

如何利用 Kubernetes 實(shí)現(xiàn)數(shù)據(jù)庫 Mesh

最后這部分，我們就介紹一下我們?nèi)绾卫?Kubernetes 去實(shí)現(xiàn)這樣一個模型。

Kubernetes 的擴(kuò)展模式

Kubernetes 被稱為是平臺的平臺。我們在 Kubernetes 之上，之前也涌現(xiàn)出來好多創(chuàng)業(yè)公司和一些 PaaS 服務(wù)商，在它上面去構(gòu)建各種各樣的能力。

Kubernetes 的擴(kuò)展能力是它生命力的關(guān)鍵，它的第一種擴(kuò)展模式叫做 Sidecar；第二個擴(kuò)展模式是 AdmissionWebhook；第三個擴(kuò)展模式，也是它特別厲害的一個能力，就是用戶自定義資源定義。

Pisanix 設(shè)計(jì)與實(shí)現(xiàn)

介紹完 Kubernetes 之后，我們就來看一下 ??Pisanix?? 這個項(xiàng)目。Pisanix 是 SphereEx 團(tuán)隊(duì)對 Database Mesh 提供的一個解決方案。Pisanix 是由 Go 和 Rust 兩種語言編寫的，我們?nèi)ミm配了 Kubernetes 環(huán)境，目前支持 MySQL 的協(xié)議。

它有三個比較主要的組件：

Pisa-Controller：Pisanix 這個項(xiàng)目的核心組件，Pisa-Controller 承擔(dān)的就是控制面，它是 Golang 實(shí)現(xiàn)的，是一個必選的組件。
Pisa-Proxy：Pisa-Proxy 是負(fù)責(zé)代理流量的數(shù)據(jù)面，Pisa-Proxy 就是以 Sidecar 的形式部署在 Pod 里面，它是 Rust 實(shí)現(xiàn)的，它也是一個必選的組件。
Pisa-Daemon（即將發(fā)布）：它是負(fù)責(zé)資源優(yōu)化的數(shù)據(jù)面，是一個 DaemonSet，是每一個 Kubernetes 集群的節(jié)點(diǎn)都會有一份 Daemon，它是一個可選的組件。

三個組件共同達(dá)到的效果：

第一，實(shí)現(xiàn)了SQL感知的流量治理。

第二，面向運(yùn)行時的資源可編程。

第三，數(shù)據(jù)庫可靠性工程，也叫DRE。

我們會重點(diǎn)講一下 Pisa-Proxy。Pisa-Proxy 是我們最主要的一個核心組件，所有的能力其實(shí)都依賴于它，我們選擇了 Rust 而去實(shí)現(xiàn)它的一個主要原因，是因?yàn)?Rust 的生命力是非常頑強(qiáng)的。

Pisa-Proxy 可以看作是面向數(shù)據(jù)庫流量的負(fù)載均衡器，主要工作流程如下：

目前 Pisa-Proxy 支持 MySQL 協(xié)議，將自己偽裝為數(shù)據(jù)庫服務(wù)端，應(yīng)用連接配置只需修改訪問地址即可建連：

Pisa-Proxy 通過讀取應(yīng)用發(fā)來的握手請求和數(shù)據(jù)包，得到應(yīng)用希望執(zhí)行的 SQL。
對該 SQL 進(jìn)行詞法和語法解析后得到對應(yīng) AST。
基于 AST 實(shí)現(xiàn)高級訪問控制和 SQL 防火墻能力。
訪問控制和防火墻通過后 SQL 提交執(zhí)行。
SQL 執(zhí)行階段的指標(biāo)將采集為 Prometheus Metrics。
根據(jù)負(fù)載均衡策略獲取執(zhí)行該語句的后端數(shù)據(jù)庫連接。
如果連接池為空將根據(jù)配置建立和后端數(shù)據(jù)庫的連接。
SQL 將從該連接發(fā)往后端數(shù)據(jù)庫，并讀取相應(yīng)返回結(jié)果。
SQL 執(zhí)行結(jié)果進(jìn)行組裝后返回給業(yè)務(wù)應(yīng)用。

最后講到Pisa-Daemon。Pisa-Daemon 離不開 eBPF 技術(shù)。eBPF 現(xiàn)在比較火，eBPF 這個技術(shù)本身就像容器一樣，也不是特別新鮮的東西。

eBPF 是 Extended BPF 的簡稱，可以在 Linux 內(nèi)核中構(gòu)建沙箱并運(yùn)行各種程序。eBPF 是一種安全和高效的內(nèi)核擴(kuò)展機(jī)制，常被用于：

可觀測性：eBPF 在內(nèi)核態(tài)可以進(jìn)行各種可觀測指標(biāo)的采集，生成多樣化的圖表。
系統(tǒng)安全：通過 eBPF 可以觀測到所有的系統(tǒng)調(diào)用，配合對網(wǎng)絡(luò)包或套接字的管理以及進(jìn)程上下文追蹤能力，實(shí)現(xiàn)更細(xì)粒度的安全控制。
網(wǎng)絡(luò)：eBPF 的編程擴(kuò)展能力，天然適合對網(wǎng)絡(luò)流量包的處理過程，無需離開內(nèi)核的網(wǎng)絡(luò)處理上下文。
追蹤和調(diào)優(yōu)：通過對用戶態(tài)進(jìn)程以及系統(tǒng)調(diào)用的探測，實(shí)現(xiàn)零侵入的關(guān)聯(lián)追蹤和性能分析體驗(yàn)。

對于 Pisa-Daemon 來說，號稱是做資源可編程，Pisa-Daemon 利用內(nèi)核機(jī)制去提供資源方面的管理能力，這個資源就是運(yùn)行時資源。通過 Pisa-Daemon 和 Pisa-Proxy 去做配合，我們可以標(biāo)識不同優(yōu)先級業(yè)務(wù)出來的數(shù)據(jù)庫流量。

未來我們希望做成一種擴(kuò)展機(jī)制，以可插拔或者可編程方式，支持更多種類型的運(yùn)行時資源管理。

如何在 Kubernetes 中使用 Pisanix

最后我們可以看一下在 Kubernetes 里面如何去使用 Pisanix 這個項(xiàng)目。

Pisanix 既然是對于 Database Mesh 的一個實(shí)現(xiàn)，那么我們也沿用它的規(guī)范，首先我們使用了三種 CRD，這三種叫做 VirtualDatabase、TrafficStrategy 和 DatabaseEndpoint。

VirtualDatabase 就是我們前面介紹 Database Mesh 的時候，它的聚合根，它的所有對于 Database Mesh 治理的能力，都是體現(xiàn)在 VirtualDatabase 上面。

在 VirtualDatabase 里面有一個字段叫做 TrafficStrategy，標(biāo)識對于這個數(shù)據(jù)庫的訪問來說，我們希望它以什么樣的策略去治理它。

那它 Random 到誰呢？就是在 TrafficStrategy 里面它有 Selector。Selector 通過 Label 去選擇后端的 DatabaseEndpoint。

這三個 CRD 就可以覆蓋這個業(yè)務(wù)應(yīng)用對于后端數(shù)據(jù)源和對于 MySQL 代理的相關(guān)配置信息。接下來就是 Pisa-Controller 拿到 CRD，然后根據(jù)里面的配置內(nèi)容轉(zhuǎn)化成 Pisa-Proxy 的配置，然后推給相應(yīng)的 Sidecar。Pisa-Proxy 拿到這個配置，然后根據(jù)里面的內(nèi)容將向后端實(shí)際的數(shù)據(jù)庫去建連，然后同時前端去監(jiān)聽端口，接收請求。最后對應(yīng)用來說，它只要訪問里面配置的這個端口就可以實(shí)現(xiàn)了。

其實(shí) Pisa-Proxy 我們也在思考它其實(shí)也是可以被單獨(dú)使用的，有的 Kubernetes 不是適用于每一個公司或者每一個業(yè)務(wù)，如果說也需要這種對于數(shù)據(jù)庫的治理，尤其對于流量這種統(tǒng)一接入的治理，其實(shí)是可以把 Pisa-Proxy 單獨(dú)拿出來去部署。這個時候的用法，就跟我們用一個 Nginx 組成一個集群是一樣的，不管后面你是什么樣的數(shù)據(jù)庫，比如你是 RDS 或者 TiDB、ShardingSphere，都可以由 Pisa-Proxy 做成數(shù)據(jù)庫的統(tǒng)一接入層，來對它做代理，實(shí)現(xiàn)這種比如無感的高可用切換，實(shí)現(xiàn)面向 SQL 的可觀測性等等。