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

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

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

??https://ost.??

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

微服務(wù)治理

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

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

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

講到 Kubernetes，如果成千上萬(wàn)個(gè)節(jié)點(diǎn)，上面可能有十萬(wàn)個(gè)pod，我們?cè)趺慈プ鏊姆?wù)治理？如果還沿用之前的服務(wù)發(fā)現(xiàn)框架，在兼容 Kubernetes 時(shí)多少會(huì)有一些水土不服。有沒(méi)有一種原生的方式去做 Kubernetes 之上的服務(wù)治理呢？這就是 Service Mesh。

Service Mesh

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

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

Istio 簡(jiǎn)介

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

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

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

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

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

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

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

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

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

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

從 Service Mesh 中學(xué)到的

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

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

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

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

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

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

Database Mesh 概念的提出

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

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

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

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

Database Mesh 的現(xiàn)狀

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

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

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

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

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

Database Mesh 1.0 vs 2.0

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

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

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

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

總結(jié)一下：

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

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

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

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

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

Kubernetes 的擴(kuò)展模式

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

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

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

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

它有三個(gè)比較主要的組件：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如何在 Kubernetes 中使用 Pisanix

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

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

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

在 VirtualDatabase 里面有一個(gè)字段叫做 TrafficStrategy，標(biāo)識(shí)對(duì)于這個(gè)數(shù)據(jù)庫(kù)的訪問(wèn)來(lái)說(shuō)，我們希望它以什么樣的策略去治理它。

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

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

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

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

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

??https://ost.??。

網(wǎng)頁(yè)題目：對(duì)創(chuàng)新互聯(lián)環(huán)境下數(shù)據(jù)庫(kù)服務(wù)治理的思考
鏈接地址：http://uogjgqi.cn/article/ccopdgg.html