講師介紹

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

分享概要

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

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

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

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

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

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

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

隨著業(yè)務(wù)的不斷發(fā)展，數(shù)據(jù)的總量不斷膨脹，同時(shí)業(yè)務(wù)線也在不斷增多。這給數(shù)據(jù)庫(kù)帶來了巨大的壓力，因?yàn)樗鼈冃枰幚砗Ａ康臄?shù)據(jù)，并保持高性能和穩(wěn)定性。

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

在混合云背景下，這些挑戰(zhàn)變得更加復(fù)雜。因?yàn)榛旌显埔馕吨覀兊募軜?gòu)設(shè)計(jì)必須具有跨云特性，需要能適配不同的云環(huán)境，不依賴特定的云廠商的獨(dú)有產(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)需要做公司級(jí)別的改造時(shí)，需要各個(gè)業(yè)務(wù)團(tuán)隊(duì)只能各自為政，不能形成有效的合力。

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

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

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

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

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

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

我們?cè)賮砜串?dāng)前的技術(shù)架構(gòu)。當(dāng)前的HLL架構(gòu)已經(jīng)補(bǔ)齊了大部分的中間件。

接入層包含了開源的統(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)控報(bào)警系統(tǒng)HLL-Monitor等模塊。

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

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

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

2、為什么選擇自建

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

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

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

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

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

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

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

1）技術(shù)棧：

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

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

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

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

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

4）功能特性比較多，我們挑幾個(gè)來簡(jiǎn)單聊一聊：

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

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

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

主要成果是：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8、SQL深度洞察效果圖

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

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

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

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

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

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

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

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

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

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

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

• 還有一個(gè)不能忽視的部分是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)并不會(huì)提升系統(tǒng)穩(wěn)定性，反而會(huì)有所降低。

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

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

圖中是一個(gè)簡(jiǎn)化的多AZ架構(gòu)設(shè)計(jì)，采用的是雙AZ對(duì)等部署的方式。系統(tǒng)整體沒有額外的IT成本，AZ故障后，利用K8S的彈性能力，在健康的AZ內(nèi)快速?gòu)棾鲎銐虻娜萘俊?/span>

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

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

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

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

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

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

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

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

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

首先是避免“唯技術(shù)”，技術(shù)是手段不是目的，不能因?yàn)橄矚g什么技術(shù)就投入進(jìn)去。

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

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

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

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

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

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

2、高可用設(shè)計(jì)有哪些要點(diǎn)

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

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

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

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