上線3年0故障，混合云下的數(shù)據(jù)庫中間件建設

2023-05-05 09:18:02來源：dbaplus社群

講師介紹

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

分享概要

(相關資料圖)

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

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

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

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

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

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

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

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

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

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

2、歷史HLL服務架構

我們先來看一下曾經的架構。

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

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

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

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

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

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

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

我們再來看當前的技術架構。當前的HLL架構已經補齊了大部分的中間件。

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

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

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

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

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

2、為什么選擇自建

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

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

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

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

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

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

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

1）技術棧：

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

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

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

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

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

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

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

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

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

主要成果是：

跨云通用的MySQL水平擴容能力。理論上能夠支持1024倍的擴容，能夠滿足企業(yè)未來3-5年的業(yè)務發(fā)展訴求。跨云通用的MySQL保護能力。能夠阻斷常規(guī)的MySQL風險，具備應對各種突發(fā)異常的應急能力。

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

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

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

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

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

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

6、為什么不直接使用云上SQL治理產品

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

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

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

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

7、基于DBProxy的旁路SQL能力建設

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

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

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

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

8、SQL深度洞察效果圖

這里有兩個主要的應用場景：

一個場景是，先看DB整體情況，比如影響行數(shù)過多的，RT太長的，可以根據(jù)SQLID反溯它的來源。另一個場景是，先通過業(yè)務視角發(fā)現(xiàn)某條SQL比較反常，可以通過SQLID來查看它的更詳細的情況，比如使用頻率和RT抖動幅度等。

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

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

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

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

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

“多AZ”架構還是有門檻的：

首先是AZ間的網絡延遲（一般AZ間的延遲在1-10ms）。必須充分地考量業(yè)務系統(tǒng)的延遲敏感度，確保業(yè)務系統(tǒng)能夠在這種延遲中正常工作。然后是IT成本。在剛才的例子中，我們有三個50%的AZ，假設容量和IT成本成正比，我們起碼需要承擔1.5倍的IT成本。還有一個不能忽視的部分是AZ間的網絡穩(wěn)定性。AZ間的網絡穩(wěn)定性是遠不如AZ內部的，如果業(yè)務系統(tǒng)自身不夠健壯，網絡一抖就崩潰。那么這種情況下“多AZ”的架構并不會提升系統(tǒng)穩(wěn)定性，反而會有所降低。

2、當前多AZ高可用架構設計

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

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

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

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

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

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

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

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

當然這個過程不是一蹴而就的。

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

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