講師介紹

林靜，現(xiàn)任貨拉拉核心基礎(chǔ)設(shè)施技術(shù)專家、數(shù)據(jù)庫中間件團(tuán)隊負(fù)責(zé)人，對數(shù)據(jù)庫中間件研發(fā)有深刻的理解和豐富的實戰(zhàn)經(jīng)驗；曾任摩托羅拉子公司UniqueSoft的Java專家，主導(dǎo)自動逆向工程系統(tǒng)Java方向研發(fā)；曾任阿里本地生活中間件技術(shù)專家，負(fù)責(zé)DAL中間件的研發(fā)，同時負(fù)責(zé)多活體系中全局控制中心和數(shù)據(jù)層的建設(shè)。

分享概要

一、混合云自建數(shù)據(jù)庫中間件背景介紹

二、混合云自建數(shù)據(jù)庫中間件實踐

三、混合云自建數(shù)據(jù)庫中間件展望

四、混合云自建數(shù)據(jù)庫中間件思考

一、混合云自建數(shù)據(jù)庫中間件背景介紹

貨拉拉是一家業(yè)務(wù)分布國內(nèi)海內(nèi)外多個國家和地區(qū)的互聯(lián)網(wǎng)企業(yè)，在不同的地區(qū)，我們會根據(jù)當(dāng)?shù)氐那闆r，選擇合適的云商。因此我們的基礎(chǔ)就是一個多云多數(shù)據(jù)中心的架構(gòu)。

1、問題與挑戰(zhàn)

隨著業(yè)務(wù)的不斷發(fā)展，數(shù)據(jù)的總量不斷膨脹，同時業(yè)務(wù)線也在不斷增多。這給數(shù)據(jù)庫帶來了巨大的壓力，因為它們需要處理海量的數(shù)據(jù)，并保持高性能和穩(wěn)定性。

此外，我們的技術(shù)底層也在不斷演進(jìn)，新老服務(wù)也在不斷交替。這就要求我們的數(shù)據(jù)層架構(gòu)能夠適應(yīng)多語言異構(gòu)的環(huán)境，同時具備高度的可擴(kuò)展性和可維護(hù)性。

在混合云背景下，這些挑戰(zhàn)變得更加復(fù)雜。因為混合云意味著我們的架構(gòu)設(shè)計必須具有跨云特性，需要能適配不同的云環(huán)境，不依賴特定的云廠商的獨有產(chǎn)品。從業(yè)務(wù)研發(fā)視角看，就是統(tǒng)一的解決方案，不需要重復(fù)開發(fā)的代碼來適配底層環(huán)境。

2、歷史HLL服務(wù)架構(gòu)

我們先來看一下曾經(jīng)的架構(gòu)。

1）業(yè)務(wù)層存在多語言技術(shù)棧并存，技術(shù)適配困難的問題。技術(shù)棧眾多，本身不是問題，問題在于缺乏統(tǒng)一的維護(hù)，當(dāng)需要做公司級別的改造時，需要各個業(yè)務(wù)團(tuán)隊只能各自為政，不能形成有效的合力。

2）基礎(chǔ)中間件很多時候還停留在部署起來能跑的程度。缺乏長效的治理，比如apollo這種配置中心就部署了多套，各個業(yè)務(wù)團(tuán)隊各自維護(hù)一份配置數(shù)據(jù)，關(guān)鍵數(shù)據(jù)散落各處沒法管理。

3）數(shù)據(jù)庫中間件其實也是這種情況。本身無論是“SmartCLient”方式也好，“Proxy”方式也好，都是比較優(yōu)秀的開源解決方案。問題在于缺乏系統(tǒng)性的建設(shè)，沒有完整的監(jiān)控報警，沒有相應(yīng)的故障應(yīng)急，沒有自動化運維，不能滿足企業(yè)對高可用和可運維的訴求。

4）DB層客觀存在的云商差異讓運維工作復(fù)雜度倍增。

總的來說，當(dāng)時的整體架構(gòu)處于勉強能夠應(yīng)對業(yè)務(wù)訴求的程度，但在穩(wěn)定性和可運維性上存在不足。

二、混合云自建數(shù)據(jù)庫中間件實踐

1、HLL數(shù)據(jù)層架構(gòu)

我們再來看當(dāng)前的技術(shù)架構(gòu)。當(dāng)前的HLL架構(gòu)已經(jīng)補齊了大部分的中間件。

接入層包含了開源的統(tǒng)一流量網(wǎng)關(guān)KONG，自研服務(wù)化網(wǎng)關(guān)LAPIGateway，自建安全網(wǎng)關(guān)WAF，商用高防網(wǎng)關(guān)等組件。

基礎(chǔ)框架方面，建設(shè)了基礎(chǔ)框架JAF，微服務(wù)框架HLL-SOA，任務(wù)系統(tǒng)LLjob，監(jiān)控報警系統(tǒng)HLL-Monitor等模塊。

變化最大的其實是數(shù)據(jù)庫中間件的部分。我們通過自建數(shù)據(jù)庫中間件DBProxy統(tǒng)一了這一層的標(biāo)準(zhǔn)：

• 異構(gòu)proxy架構(gòu)，實現(xiàn)了對上層開發(fā)語言的兼容；
• 集成HLL體系，集成了HLL的DMS，LLMonitor，配置中心，注冊中心等基礎(chǔ)組件，讓數(shù)據(jù)庫中間件不再是數(shù)據(jù)孤島，和各個組件形成合力；
• 跨云適配 + 場景化分庫分表，讓DBProxy能夠屏蔽底層差異，給業(yè)務(wù)服務(wù)提供一致的體驗。幫助業(yè)務(wù)服務(wù)高效安全的從歷史存留各種數(shù)據(jù)庫中間件遷移到DBProxy上來；
• 高可用設(shè)計，讓DBProxy本身不會成為系統(tǒng)的弱點；
• 高性能架構(gòu)，讓DBProxy擁有超過同類的產(chǎn)品的性能表現(xiàn)；
• DB穩(wěn)定性保障，讓DBProxy能夠滿足各個云臺下rds通用的穩(wěn)定性訴求；
• 企業(yè)級的可運維性，是DBProxy能夠解決歷史遺留問題的核心。我們有嚴(yán)格的開發(fā)流程，全面的應(yīng)急預(yù)案，完善的監(jiān)控報警體系，自動化的管理運維手段。

隨著自建數(shù)據(jù)中間件的落地，讓HLL的系統(tǒng)的穩(wěn)定性和可運維性都獲得了巨大的提升。

2、為什么選擇自建

選擇自建數(shù)據(jù)庫中間件，是混合云背景下的必然選擇。

大廠目前普遍都有自己的數(shù)據(jù)庫中間件，經(jīng)歷過大廠復(fù)雜業(yè)務(wù)場景考驗，無論是功能還是穩(wěn)定性都值得信賴?？上Ь褪遣婚_源，而開源出來的產(chǎn)品和內(nèi)部線上產(chǎn)品往往有代差。

云產(chǎn)品是我們比較理想的選擇，上線快、穩(wěn)定性好、功能成熟，但不能做到跨云通用，不符合我們“跨云通用”的基本訴求。

開源產(chǎn)品幫助我們解決了許多問題。無論是功能豐富的開源產(chǎn)品，還是友好的開源社區(qū)，都讓我們在系統(tǒng)演化的道路上受益匪淺。伴隨著企業(yè)的發(fā)展，我們對產(chǎn)品提出了更多定制化的需求，而這些肯定是不能通過開源產(chǎn)品實現(xiàn)的。

因此我們選擇了自建數(shù)據(jù)庫中間件這條道路。

3、數(shù)據(jù)庫中間件架構(gòu)

HLL數(shù)據(jù)庫中間件的架構(gòu)還是比較簡單的，我們由下往上看：

1）技術(shù)棧：

• 采用Java技術(shù)棧，為了保證GC停頓時間盡量短，使用了ZGC這種低停頓垃圾回收方式；
• 采用了異步網(wǎng)絡(luò)框架 Netty，保證系統(tǒng)對高并發(fā)的支持；
• 采用了事件異步驅(qū)動編程模型，保證了系統(tǒng)的高可用和高性能；
• 采用異構(gòu)Proxy架構(gòu)，保證了對多語言的兼容。

2）可運維性（“平滑”是最主要的關(guān)鍵詞）：

• 平滑升級，連接預(yù)熱，快啟動，慢退出，連接平滑釋放等細(xì)節(jié)來達(dá)成變更平滑、管理平滑、運維平滑；
• 監(jiān)控報警，是一個系統(tǒng)長期穩(wěn)定的關(guān)鍵之一。在越早的階段發(fā)現(xiàn)問題，問題的影響就越小，而監(jiān)控報警是發(fā)現(xiàn)識別問題的關(guān)鍵。監(jiān)控報警既要全面，又要準(zhǔn)確，必須有一個持續(xù)收斂保鮮的過程才能保證它的有效。

3）高可用設(shè)計（體現(xiàn)在方方面面）：

• 分集群部署，是解決不同業(yè)務(wù)對資源有不同側(cè)重的問題；
• 擁塞設(shè)計是非常重要的。假設(shè)一條SQL返回100個G的結(jié)果，如果沒有合理的擁塞機(jī)制，輕易就能撐爆DBProxy的內(nèi)存。所以必須有合理的擁塞機(jī)制，DBProxy要盡快把數(shù)據(jù)吐到客戶端，要像TCP滑動窗口一樣，根據(jù)客戶端的數(shù)據(jù)接收能力，對數(shù)據(jù)流速作出調(diào)整；
• 線程收斂是DBProxy性能保障的核心之一，一旦線程數(shù)過多，額外的內(nèi)存和CPU開銷就會增多。同時很多框架機(jī)制都是和線程數(shù)相關(guān)的，比如ZGC在線程數(shù)增多的時候，效果就會變差。 

4）功能特性比較多，我們挑幾個來簡單聊一聊：

• 限流：我們的限流采用的是限制DB并發(fā)數(shù)的令牌桶算法。為什么不是采用更好理解的QPS或者連接數(shù)限制呢？主要因為這兩個維度在不同的SQL應(yīng)用場景下數(shù)值差距太大，需要付出非常大的運維成本。而基于DB核數(shù)設(shè)定并發(fā)數(shù)的動態(tài)限流，更符合數(shù)據(jù)庫領(lǐng)域的特征。
• 動態(tài)index hint注入：這個功能解決的是，SQL由于數(shù)據(jù)量變化等原因沒有走到合理的索引，變異成慢SQL的問題。在業(yè)務(wù)高峰的時候直接在DB上加索引，或者改業(yè)務(wù)SQL是不現(xiàn)實的。通過DBProxy，可以動態(tài)給SQL添加index hint，等過了業(yè)務(wù)高峰期，再常規(guī)修復(fù)是非常安全高效的做法。
• ShardingMapingKey：這個功能是為滿足Sharding表的額外映射訴求。比如有一張表包含兩個唯一ID，根據(jù)其中一個ID做分庫分表后，用另一ID查數(shù)據(jù)就只能全分片掃，才能找到對應(yīng)的數(shù)據(jù)，這可能導(dǎo)致上千倍的讀放大。ShardingMapingKey能自動維護(hù)一張Mapping表，來管理兩個ID的映射關(guān)系，這樣就避免全分片掃的問題。

總的來說，沒有什么出人意料的技術(shù)技巧，有的只是為了滿足業(yè)務(wù)的訴求，而細(xì)細(xì)打磨的過程。

4、數(shù)據(jù)庫中間件建設(shè)成果

主要成果是：

• 跨云通用的MySQL水平擴(kuò)容能力。理論上能夠支持1024倍的擴(kuò)容，能夠滿足企業(yè)未來3-5年的業(yè)務(wù)發(fā)展訴求。

• 跨云通用的MySQL保護(hù)能力。能夠阻斷常規(guī)的MySQL風(fēng)險，具備應(yīng)對各種突發(fā)異常的應(yīng)急能力。

此外，HLL數(shù)據(jù)庫中間件具備低延遲、高可用、低成本的特性。HLL DBProxy已經(jīng)上線快3年了，自身一直保持0故障，通過攔截異常SQL，消弭流量沖擊，阻擋連接風(fēng)暴等能力，為數(shù)據(jù)庫提供了強有力的保護(hù)。

5、數(shù)據(jù)庫領(lǐng)域還有哪些問題

首先是數(shù)據(jù)安全問題：過去我們的SQL審計只能由業(yè)務(wù)研發(fā)，在業(yè)務(wù)邏輯中插入特定代碼實現(xiàn)，存在覆蓋不全、成本高、推進(jìn)難的問題。

然后是SQL治理問題：由于我們的數(shù)據(jù)庫全部由云商托管，很多細(xì)節(jié)不再對DBA和研發(fā)暴露。觀察SQL詳情的手段只有類似吞吐量，RT95線這樣的監(jiān)控報警，不能很好地了解SQL執(zhí)行的細(xì)節(jié)，存在SQL治理粒度不夠細(xì)，SQL無法追蹤的問題。

還有是SQL預(yù)警問題：很多時候，風(fēng)險SQL只有到了生產(chǎn)并造成一定破壞后，我們才能發(fā)現(xiàn)，這個時候已經(jīng)只能亡羊補牢了。雖然亡羊補牢，為時未晚，但我們更想要防患于未然。

最后是壓測SQL流量失真問題：壓力測試是保障系統(tǒng)容量的核心手段，但在DB領(lǐng)域，我們經(jīng)常因為測試SQL和線上真實運行的SQL存在差異，而無法有效驗證出數(shù)據(jù)庫的真實容量，存在容量風(fēng)險和資源浪費的雙重問題。

6、為什么不直接使用云上SQL治理產(chǎn)品

1）部分云商提供了類似的產(chǎn)品，但價格普遍比較昂貴。由于成本壓力，我們只會開幾天然后盡早關(guān)閉，只能應(yīng)急，不能當(dāng)作常規(guī)手段。

2）在這些領(lǐng)域，不同云商提供的產(chǎn)品服務(wù)差別非常大。有的云商提供了非常豐富的相關(guān)產(chǎn)品服務(wù)，但在另外的云商那里卻是一片空白?？缭撇町惥薮?，完全不能通用。

3）云商提供的能力和我們的實際需求還是存在一些差異，畢竟云服務(wù)只會支持通用場景，而不會按照企業(yè)的需求做定制。

4）云上產(chǎn)品也不是只要能用就好，還要考慮集成問題，比如研發(fā)使用習(xí)慣，監(jiān)控報警，溝通，審計，管控等。

7、基于DBProxy的旁路SQL能力建設(shè)

SQL安全審計：基于DBProxy的“SQL安全審計”能力，對業(yè)務(wù)沒有侵入，隨著DBProxy對業(yè)務(wù)的全面覆蓋，所有的DB都自動納入了審計范圍。解決了推廣覆蓋難、接入成本高的問題。

SQL深度洞察：基于DBProxy的“SQL深入洞察”能力，不僅收集分析了SQL的執(zhí)行細(xì)節(jié)，而且集成了SQL指紋（SQLID）和業(yè)務(wù)調(diào)用的Trace信息，解決了SQL觀察粒度粗、難以追蹤的問題。

SQL線下預(yù)警：“SQL深入洞察”能夠在預(yù)發(fā)環(huán)境就識別出風(fēng)險SQL，解決了問題SQL后知后覺的問題。

SQL流量仿真：“SQL流量仿真”能夠精準(zhǔn)還原線上真實SQL流量，保障系統(tǒng)數(shù)據(jù)庫容量安全，同時避免資源浪費。

8、SQL深度洞察效果圖

這里有兩個主要的應(yīng)用場景：

• 一個場景是，先看DB整體情況，比如影響行數(shù)過多的，RT太長的，可以根據(jù)SQLID反溯它的來源。

• 另一個場景是，先通過業(yè)務(wù)視角發(fā)現(xiàn)某條SQL比較反常，可以通過SQLID來查看它的更詳細(xì)的情況，比如使用頻率和RT抖動幅度等。

四、混合云自建數(shù)據(jù)庫中間件思考

1、下一步最直接的挑戰(zhàn)是“多AZ”

“多AZ”架構(gòu)可以簡單理解為云上的同城多活架構(gòu)。

云上“多AZ”對比一般自建同城多活，優(yōu)勢在于成本更低、粒度更靈活。由于基礎(chǔ)設(shè)施的部分已經(jīng)由云商建設(shè)好，企業(yè)可以有選擇性地落地多AZ架構(gòu)，比如只有MySQL使用多AZ架構(gòu)，其他部分保持單AZ。

圖中是一個簡化的三AZ部署案例，每個AZ可以承擔(dān)50%的流量。任意一個AZ出問題，系統(tǒng)都能正常工作。

“多AZ”架構(gòu)還是有門檻的：

• 首先是AZ間的網(wǎng)絡(luò)延遲（一般AZ間的延遲在1-10ms）。必須充分地考量業(yè)務(wù)系統(tǒng)的延遲敏感度，確保業(yè)務(wù)系統(tǒng)能夠在這種延遲中正常工作。

• 然后是IT成本。在剛才的例子中，我們有三個50%的AZ，假設(shè)容量和IT成本成正比，我們起碼需要承擔(dān)1.5倍的IT成本。

• 還有一個不能忽視的部分是AZ間的網(wǎng)絡(luò)穩(wěn)定性。AZ間的網(wǎng)絡(luò)穩(wěn)定性是遠(yuǎn)不如AZ內(nèi)部的，如果業(yè)務(wù)系統(tǒng)自身不夠健壯，網(wǎng)絡(luò)一抖就崩潰。那么這種情況下“多AZ”的架構(gòu)并不會提升系統(tǒng)穩(wěn)定性，反而會有所降低。

2、當(dāng)前多AZ高可用架構(gòu)設(shè)計

建設(shè)AZ級別的故障轉(zhuǎn)移能力，對企業(yè)來說是十分必要的。我們之前遇到過一次類似的故障：由于第三方的意外操作，機(jī)房內(nèi)部100多個機(jī)架斷電，相關(guān)服務(wù)組件全部故障，系統(tǒng)不可用持續(xù)長達(dá)1個多小時。假如當(dāng)時我們的系統(tǒng)具備AZ級別故障轉(zhuǎn)移能力，這次事故就能完全避免掉。

圖中是一個簡化的多AZ架構(gòu)設(shè)計，采用的是雙AZ對等部署的方式。系統(tǒng)整體沒有額外的IT成本，AZ故障后，利用K8S的彈性能力，在健康的AZ內(nèi)快速彈出足夠的容量。

而數(shù)據(jù)庫中間件在“多AZ”架構(gòu)里是存在不足的：

• 首先是AZ間延遲放大問題。當(dāng)業(yè)務(wù)節(jié)點和DBProxy不在同一個AZ時，一個SQL請求需要經(jīng)歷兩次跨AZ延遲，這對系統(tǒng)RT容忍性提出了更高的要求。
• 然后是彈性能力不足問題。我們需要投入額外的IT成本和運維開銷來適配AZ容災(zāi)場景。

這方面“RedisMesh”已經(jīng)領(lǐng)先了一步，通過K8S DaemonSet+Sidecar的近客戶端部署架構(gòu)，規(guī)避了中間件放大跨AZ延遲的問題，也解決了彈性問題。

3、未來數(shù)據(jù)庫中間件的展望

未來我們期望把DBProxy、KafkaGateway這樣的數(shù)據(jù)層中間件都轉(zhuǎn)型到sidecar模式，和現(xiàn)有的RedisMesh集成，打造新一代的數(shù)據(jù)層中間件DataMesh。

DataMesh不僅具備原來數(shù)據(jù)庫中間件的基礎(chǔ)能力，而且具備遠(yuǎn)超當(dāng)前數(shù)據(jù)庫中間件的云環(huán)境適應(yīng)性，能夠靈活適配未來復(fù)雜多變云上架構(gòu)。

當(dāng)然這個過程不是一蹴而就的。

4、混合云數(shù)據(jù)庫中間件走向何處

對于數(shù)據(jù)庫中間件前進(jìn)的方向和節(jié)奏，我們是這樣的考慮的。

首先是避免“唯技術(shù)”，技術(shù)是手段不是目的，不能因為喜歡什么技術(shù)就投入進(jìn)去。

然后“比業(yè)務(wù)快半步”，就是說基礎(chǔ)技術(shù)要像一碗剛做好的面一樣，溫度剛剛好。太晚了不行，不能讓業(yè)務(wù)餓著了，太早了也不行，面就涼。

最后是“面向云原生”，我們不能試圖去撇開云環(huán)境去做什么，而應(yīng)該更靠近云，讓業(yè)務(wù)服務(wù)更容易享受的云時代的便利。

三、混合云自建數(shù)據(jù)庫中間件展望

1、無論什么時候穩(wěn)定性都是第一位

我們的核心工作是為企業(yè)帶來穩(wěn)定性價值和效率價值。穩(wěn)定性永遠(yuǎn)是第一位的。這方面，我們比較信奉海恩法則。

簡單來說，故障的發(fā)生是有跡可循的，我們應(yīng)該通過流程和機(jī)制把故障消滅在萌芽狀態(tài)。

2、高可用設(shè)計有哪些要點

就像前面說的高可用是可以通過建設(shè)來達(dá)成的。簡單總結(jié)下來就是：

• 做最壞的打算，不要有僥幸心理；
• 要解決大部分人的問題，符合大部分人的使用習(xí)慣，不要標(biāo)新立異；
• 不要單打獨斗，借助整個公司基礎(chǔ)設(shè)施的力量，形成合力；
• 把好的機(jī)制和流程沉淀到工具去。

3、數(shù)據(jù)庫中間件研發(fā)培養(yǎng)

最后跟大家分享一點關(guān)于如何培養(yǎng)數(shù)據(jù)庫中間件研發(fā)的想法，培養(yǎng)中間件領(lǐng)域的研發(fā)，應(yīng)該從這三方面入手：領(lǐng)域知識、產(chǎn)品意識、編程技巧。一名優(yōu)秀的數(shù)據(jù)庫中間件開發(fā)應(yīng)該同時具備這三方面的能力，三者缺一不可。