林靜

JAVA 技術(shù)專家

• 貨拉拉技術(shù)中心核心基礎(chǔ)設(shè)施部Java技術(shù)專家，對數(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è)。  

今天的分享主要包含以下幾個方面的內(nèi)容：

一直以來，都有這樣的觀點——隨著云時代的到來，基礎(chǔ)設(shè)施都會被云接管，基礎(chǔ)設(shè)施都沒了，自然也就沒必要自建中間件了。 而我的觀點恰恰相反，正是云時代的到來，我們才更需要自建中間件。

為什么這么說呢，主要有這樣兩個原因：一個是技術(shù)適配問題，我們的原生環(huán)境和云環(huán)境不可能是完全一致的，想要業(yè)務(wù)平滑上云就必然要由中間件做適配；另一個更重要的原因是保持廠商中立，各個云廠商的服務(wù)并沒有統(tǒng)一的標(biāo)準(zhǔn)，一旦企業(yè)習(xí)慣了某些獨一無二的服務(wù)，企業(yè)也就失去了自由選擇云平臺的能力。所以自建中間件是云時代的必然之路。而自建數(shù)據(jù)庫中間件正是其中不可或缺的一環(huán)—— “適配混合云，數(shù)據(jù)庫中間件的建設(shè)之路”，正是這次我要和大家探討的主題！

一、背景

• 業(yè)務(wù)體量持續(xù)增長遇到單庫瓶頸；
• 業(yè)務(wù)線不斷增多，數(shù)據(jù)庫總量不斷膨脹；
• 多語言異構(gòu)，技術(shù)底座不斷演進(jìn)，新老服務(wù)過度；
• 多云混合云部署。

和大多數(shù)上升期的企業(yè)一樣，隨著業(yè)務(wù)蓬勃發(fā)展， 技術(shù)底盤也迎來了自己的挑戰(zhàn)。 從量變到質(zhì)變，很多原來習(xí)以為常的解決方案變得不再那么完美，DB就是一個典型的例子。 原先單個DB毫無壓力的好日子不見了，在高并發(fā)、海量數(shù)據(jù)的壓力下，DB無論是吞吐量還是存儲都開始遇到瓶頸。 而當(dāng)DB在高水位的時候，也是最容易出故障的時候。

隨著業(yè)務(wù)不斷豐富和多元化，原來的單體架構(gòu)也在向微服務(wù)架構(gòu)演進(jìn)，而PHP為主的技術(shù)棧也由于各方面的考慮向Java技術(shù)棧過渡。在DB層面表現(xiàn)出來的就是大量的拆庫、遷庫、建庫工作。熟悉這塊的同學(xué)都知道“拆庫、遷庫”是一個耗時耗力又高風(fēng)險的操作。

而混合云背景，又加碼了問題的復(fù)雜度。混合云意味著我們的架構(gòu)設(shè)計必須具有跨云特性，需要能適配不同的云環(huán)境，不依賴特定的云廠商的獨有廠品。從業(yè)務(wù)研發(fā)視角看，就是統(tǒng)一的解決方案，不需要重復(fù)開發(fā)的代碼來適配底層環(huán)境。

二、混合云下的問題與挑戰(zhàn)

• 各云廠商的RDS存在各種差異 ；
• 現(xiàn)有線性DB擴(kuò)容方案不能跨云 ；
• DB頻繁拆分合并，風(fēng)險高容易影響業(yè)務(wù) ；
• DB層產(chǎn)品變更成本高，無法及時享受新技術(shù)紅利。

剛才介紹了背景，我們把內(nèi)容再捋一捋。

RDS在一個云平臺一般有多種選擇，而多云的情況可能就有一種逛淘寶的感覺了。一般來說協(xié)議上會兼容mysql，但具體到某個特定SQL語法，主從部署方案等細(xì)節(jié)的時候，就會有各種細(xì)微的差別。比如我們要限制所有SQL刪除數(shù)據(jù)必須有where條件，有的產(chǎn)品不支持這個功能，有的產(chǎn)品可能支持動態(tài)修改，而有的產(chǎn)品只能通過重啟來修改。

剛才我們提到單機(jī)瓶頸，云廠商都提供了各自的解決方案。早期的云廠商會提供自己的數(shù)據(jù)庫中間件，比如阿里云的DRDS，通過分庫分表的方式來支持?jǐn)?shù)據(jù)庫的水平擴(kuò)展。經(jīng)過一段時間的沉淀和演進(jìn)，現(xiàn)在云廠商推出了數(shù)種新型的分布式數(shù)據(jù)庫產(chǎn)品，提供了更好的可運(yùn)維性，我們不用關(guān)心部署的細(xì)節(jié)，而直接享受它線性擴(kuò)展的能力。這些新產(chǎn)品在單云環(huán)境下都是非常合適的解決方案，而問題是這些方案并不能跨云，這些方案都依賴各個云廠商的獨有產(chǎn)品。

還有一個問題是變更。我們就以拆庫為例子，兩個業(yè)務(wù)公用一個數(shù)據(jù)庫，現(xiàn)在需要拆分出來。那么具體執(zhí)行順序怎么安排呢？

① 同步數(shù)據(jù)到新庫；

② 業(yè)務(wù)中斷；

③ 業(yè)務(wù)服務(wù)使用新串重啟；

④ 業(yè)務(wù)恢復(fù)。

這個過程中我們依賴業(yè)務(wù)具有自我中斷的能力，另外我們會長時間中斷業(yè)務(wù)，需要確定是不是每一個業(yè)務(wù)節(jié)點都重啟了，否則就是數(shù)據(jù)不一致的災(zāi)難。萬一出問題需要回滾，這個冗長的步驟又要再來一次。這個時候我們就會想，我們要是能夠靈活的控制連接串，動態(tài)設(shè)置它指向哪里的DB就好了。一把就全切過去，有問題馬上切回來，中間業(yè)務(wù)服務(wù)都不用重啟。

最后我們再關(guān)心一下成本問題。云廠商由于其強(qiáng)大的技術(shù)背景以及市場競爭壓力，總能推陳出新，不斷推出產(chǎn)品的性價比更高的新產(chǎn)品，來替代老產(chǎn)品。我們對低廉的價格很感興趣，但變更的風(fēng)險又讓我們不敢輕舉妄動。

三、混合云下數(shù)據(jù)庫中間件建設(shè)

怎么解決上述問題呢？核心是解耦和適配。怎么理解呢？我們遇到的大部分問題都是底層的RDS和業(yè)務(wù)服務(wù)高耦合，這種情況在過去其實非常合理的架構(gòu)模式，而在云時代已經(jīng)不能滿足我們對可運(yùn)維性，高可用的要求。因此我們需要通過自建數(shù)據(jù)庫中間件來解耦業(yè)務(wù)服務(wù)和數(shù)據(jù)層，同時由數(shù)據(jù)庫中間件來適配DB層，給業(yè)務(wù)服務(wù)提供統(tǒng)一一致的體驗。

從這張圖，我們可以看到借由數(shù)據(jù)庫中間件，業(yè)務(wù)層和DB層實現(xiàn)了解耦。這樣的架構(gòu)下，DB層的變得更靈活也更安全。我們可以靈活地選擇DB層的產(chǎn)品，甚至做出跨云的設(shè)計。

回到剛才的DB拆分問題，在新的架構(gòu)下，我們就可以這樣處理：

• 業(yè)務(wù)服務(wù)使用新串（指向老庫）重啟；
• 同步數(shù)據(jù)到新庫；
• DB流量中斷；
• 流量指向新庫；

業(yè)務(wù)服務(wù)只需要修改鏈接串，而不用再做任何其他的操作。中斷時間變得非常短，只要完成增量數(shù)據(jù)同步就可以恢復(fù)數(shù)據(jù)庫的訪問。同時回滾操作也在DBA團(tuán)隊閉環(huán)了，原本需要幾方配合的變更，變成了DBA團(tuán)隊內(nèi)部閉環(huán)的動作，大大降低了復(fù)雜度，無論是效率，還是安全程度，都得到了非常大的提升。

1、核心功能與特性

前面說解耦是由自建數(shù)據(jù)庫中間件帶來的架構(gòu)靈活性來解決的，那么適配又是怎么做的呢？適配主要體現(xiàn)在數(shù)據(jù)庫中間件的具體功能上，我們在設(shè)計實現(xiàn)數(shù)據(jù)庫中間件功能的時候就需要有這樣的考量。下面我們來詳細(xì)講講這幾個功能點：

1）模版式分庫分表，讀寫分離

分庫分表可以是說目前性價比最高的數(shù)據(jù)庫線性擴(kuò)容方案，主流的分布式數(shù)據(jù)庫中間件都是采用這樣的方案。

• 提供給業(yè)務(wù)研發(fā)的視角是一個使用的視角。站在業(yè)務(wù)研發(fā)的角度，這是一個可伸縮的新型mysql數(shù)據(jù)庫，DB容量可以隨著業(yè)務(wù)的發(fā)展按需擴(kuò)容。
• 提供給DBA的視角是一個運(yùn)維的視角。這是一個由分庫和分表組成的集群，根據(jù)實際DB壓力來調(diào)節(jié)分庫分表的數(shù)量。

我們可以發(fā)現(xiàn)無論是業(yè)務(wù)研發(fā)視角，還是DBA視角，都是比較直觀的，不會引入特別抽象的概念。一條SQL實際執(zhí)行其實是非常復(fù)雜的，其中有語法解析，分庫分表規(guī)則映射，新SQL生成、新SQL下發(fā)到分庫執(zhí)行，結(jié)果聚合等等。這些復(fù)雜過程雖然重要，但從使用者的角度不是價值而是負(fù)擔(dān)，因此我們把細(xì)節(jié)全部交給數(shù)據(jù)庫中間件來隱藏起來。

我們給業(yè)務(wù)研發(fā)同學(xué)交付的是和普通DB一樣的連接串。我們給DBA同學(xué)提供的是新建邏輯庫的API，參數(shù)是分庫分表的數(shù)量，而具體的哈希函數(shù)選擇，分表分布等全部提供了默認(rèn)模版。這里正是企業(yè)自建數(shù)據(jù)庫中間件的特點，我們不會考慮做一個需要用戶自己調(diào)參的大而全的產(chǎn)品，而是迎合自身業(yè)務(wù)的特色直接給出一個最佳實踐的直觀產(chǎn)品。

這樣的設(shè)計是非常靈活的?？梢杂鲆姴贿b遠(yuǎn)的未來，會出現(xiàn)一種公認(rèn)高性價比且穩(wěn)定的新型數(shù)據(jù)庫，我們完全可以把邏輯庫的實現(xiàn)替換掉，而業(yè)務(wù)服務(wù)無需重啟直接享用。

2）支持多租戶，資源利用更高效

多租戶是一個云時代中間件必備的能力。多租戶核心在于資源池化，按需共享，能夠非常有效的提高資源利用率，簡單來說就是省錢。

多租戶這個特性可以幫助數(shù)據(jù)庫中間件適應(yīng)各種使用場景。比如在DEV環(huán)境，我們可以用一個數(shù)據(jù)庫中間件節(jié)點來代理所有的測試DB，使業(yè)務(wù)研發(fā)在測試開發(fā)階段保持和生產(chǎn)一致的體驗，而完全不用擔(dān)心資源浪費問題。

多租戶在設(shè)計實現(xiàn)上，主要需要考慮兩個方面的隔離：一個是配置隔離，不同邏輯庫的動態(tài)配置變更應(yīng)該互不影響；另一個是資源隔離，不同邏輯庫的SQL執(zhí)行不應(yīng)該爭搶資源。

3）SQL鏈路追蹤與SQL治理

SQL鏈路追蹤在一個企業(yè)級的環(huán)境中是非常實用且重要的功能，抓到一條問題SQL后，能夠迅速定位具體來源，將大大提升線上排障效率，加快故障恢復(fù)，減小損失。這個能力顯然不是單獨一個中間件能搞定的，而是需要和一個成熟的技術(shù)底盤結(jié)合起來才能實現(xiàn)。

這里需要一提的是，和所有的中間件一樣，數(shù)據(jù)庫中間件產(chǎn)品只有成為企業(yè)技術(shù)體系的一部分才能發(fā)揮全部的價值，即可以獲得包括監(jiān)控，配置中心，注冊中心的支持，也給整個技術(shù)體系提供DB層的埋點數(shù)據(jù)和治理能力。而成為一個數(shù)據(jù)孤島的話，肯定會有功能和運(yùn)維性的短板，甚至成為企業(yè)技術(shù)體系里的黑洞。

• SQL治理能力包括： 緊故障防護(hù)能力、應(yīng)急故障處理能力；
• 故障防護(hù)能力包括：消峰限流、連接管理、SQL攔截審計等；
• 應(yīng)急故障處理能力包括：指定SQL限流攔截、SQL Index hint注入、強(qiáng)制綁定主庫等；

整套SQL治理能力工具集能夠適配各種云環(huán)境，有效保障DB健康穩(wěn)定。

2、核心技術(shù)指標(biāo)

這里列了一些比較關(guān)鍵的指標(biāo)，我們來簡單解讀下：

• 線性擴(kuò)容上限——單機(jī)容量*1024 
• 多租戶上限——單集群理論上限達(dá)10K 

這兩個指標(biāo)主要考量這樣一個問題：我們現(xiàn)在的架構(gòu)方案是否能夠滿足企業(yè)未來2-3年的發(fā)展，假設(shè)未來3年我們的體量翻10倍，我們的架構(gòu)能否夠平穩(wěn)應(yīng)對。從數(shù)據(jù)層這個角度來講，答案是肯定的，以自建數(shù)據(jù)庫中間件為基礎(chǔ)的數(shù)據(jù)庫層架構(gòu)，可以平穩(wěn)支撐未來百倍的業(yè)務(wù)增長。

• DB遷移影響  — 秒級中斷

DB遷移影響這個指標(biāo)代表的是我們的遷移能力的成熟度。也可以這么說，它代表在業(yè)務(wù)無損的前提下，我們遷移能力的自由度。秒級中斷的能力，可以幫助我們做到業(yè)務(wù)低峰期無損遷移。最理想的情況肯定是全天可操作，這也是我們努力的方向。

• 低延遲—99.999%延遲小于10ms

低延遲指標(biāo)其實包含了2個維度的考量：一個RT平均值的小，一個RT抖動的小。做為數(shù)據(jù)庫中間件，穩(wěn)定性肯定第一位的，我們一般選擇RT抖動做為衡量穩(wěn)定性的核心指標(biāo)。在技術(shù)上我們選擇了Netty NIO的多路復(fù)用框架以及Java16 ZGC來實現(xiàn)這個維度指標(biāo)的提升。

• 高可用—99.999%服務(wù)可用

高可用的量化指標(biāo)一般用X個9來表達(dá)，X個9表示在系統(tǒng)1年時間的使用過程中，系統(tǒng)可以正常使用時間與總時間（1年）之比。一般企業(yè)級軟件要求是4個9，也就是全年允許掛50分鐘，5個9的話就是全年只能掛5分鐘，而我們的數(shù)據(jù)庫中間件上線16個月一直保持0故障，算是我們做的比較滿意的部分。

• 低成本— 成本占用不到RDS的5%

所謂低成本，自己做的蛋糕肯定比買的便宜。當(dāng)然這只是開個玩笑，這個肯定不能這么考慮。這里涉及到三個成本，軟硬件成本+運(yùn)維成本+研發(fā)成本。前兩個相信大家都比較熟悉了。

我主要分享下對第三個成本的觀點：和過去大家什么都想要自己開發(fā)相反，現(xiàn)在我們往往會過分夸大自研投入的成本，而直接放棄自研的選項。在中間件領(lǐng)域開源氛圍濃郁的大環(huán)境下，我們其實比以往更容易培養(yǎng)中間件人才，利用社區(qū)資源我們也更有把握解決相關(guān)的難題，因此研發(fā)的成本并不會太高。而我們在研發(fā)實踐后也能夠反饋社區(qū)，形成正循環(huán)，這是一個雙贏選擇。

3、可運(yùn)維性與技術(shù)設(shè)計

可運(yùn)維性是衡量一個中間件產(chǎn)品設(shè)計是否“好用”的重要維度。雖然是針對產(chǎn)品上線后的生命周期，卻是在設(shè)計階段決定?？蛇\(yùn)維性的內(nèi)容比較豐富，在總結(jié)反思我們產(chǎn)品的建設(shè)過程后，總結(jié)了以下4點。

1）面向故障設(shè)計

• 非核心依賴可降級
• 核心依賴做好冗余
• 建設(shè)系統(tǒng)“自證清白”能力
• 最后一道防線手動SOP

面向故障設(shè)計應(yīng)該是大家比較熟悉的概念了。特別是在體量上來以后，故障就變成是必然，只有一臺機(jī)器的時候我們說今天它有可能壞，而我們有10000臺的時候，我們會肯定的說今天必然要壞一臺。特別值得一提的是，我們有時候會神化云環(huán)境的穩(wěn)定性，以為上云了就不會有故障了。云環(huán)境的穩(wěn)定性不是說不出故障，而是有一套完整機(jī)制來故障恢復(fù)，是一種反脆弱的設(shè)計。而有些故障特別是硬件故障，并沒有快速的恢復(fù)辦法，比如交換機(jī)壞了，光發(fā)現(xiàn)問題就需要不短的時間，更何況恢復(fù)。所以無論是什么環(huán)境，我們都要設(shè)計好故障的預(yù)案。

在數(shù)據(jù)庫中間件的場景里，可降級的依賴一般指影響旁路的功能，動態(tài)修改配置，監(jiān)控等。不可降級的部分包括關(guān)鍵數(shù)據(jù)，硬件設(shè)備等。對于數(shù)據(jù)我們肯定要做好備份，而硬件問題換個角度其實更多是單節(jié)點故障，集群化是非常合適的解決方案。

在一個大的系統(tǒng)里發(fā)生故障，往往是到處都冒煙，但就是找不到真正出問題的點。這個時候“自證清白”就顯的非常重要，如果所有組件能快速確定自己的狀態(tài)，故障點清晰可見了。當(dāng)然“自證清白”并不是那么容易的，真實的情況往往是大盤故障了，所有人都摸不清自己的模塊是不是有問題，然后各種看日志，查監(jiān)控，可即使這樣的付出，還是很難得出結(jié)論。“自證清白”是一個重要又非常有挑戰(zhàn)的能力，需要對本領(lǐng)域有非常深的理解，同時又需要監(jiān)控報警等基礎(chǔ)能力配合。在數(shù)據(jù)庫中間件這里，主要關(guān)注內(nèi)部的工作線程負(fù)載，外部表現(xiàn)的RT，以及網(wǎng)絡(luò)的丟包這三個關(guān)鍵數(shù)據(jù)。

手動SOP屬于兜底手段了，比如數(shù)據(jù)庫中間件保留了本地文件啟動能力。

2）產(chǎn)品標(biāo)準(zhǔn)化

• 針對不同使用特征，分級群隔離
• 使用統(tǒng)一硬軟件標(biāo)準(zhǔn)
• 盡量復(fù)用企業(yè)現(xiàn)有標(biāo)準(zhǔn)
• 接入標(biāo)準(zhǔn)化
• 功能簡單正交

標(biāo)準(zhǔn)化是一種追求全局最優(yōu)的設(shè)計理念。

一個是功能設(shè)計的標(biāo)準(zhǔn)化。 作為基礎(chǔ)中間件，我們的功能必須是簡單正交的，這樣就能夠在實現(xiàn)功能的時候更專注保證質(zhì)量，同時也留出進(jìn)一步的編排的空間。舉個例子，我們提供了限制指定SQL pqs的功能，也提供了上報異常SQL（類似SQL長度過長）的能力。這個時候如果在上層控制面做一個自動限制異常SQL的能力，就會非常順利，即容易實現(xiàn)也可以方便的灰度回滾。而我們?nèi)绻婚_始就在數(shù)據(jù)庫中間件這里憋大招，就很難做到這樣自如，反而很有可能會因為功能相互影響，復(fù)雜度太高，引入bug等破壞迭代節(jié)奏。

另一個是外部依賴的標(biāo)準(zhǔn)化。 比如盡量使用公司統(tǒng)一的ECS機(jī)型，能夠最大的避免機(jī)器沒庫存的問題。使用公司統(tǒng)一的基礎(chǔ)組件，能夠免去額外維護(hù)的成本，同時提高的產(chǎn)品開發(fā)效率和穩(wěn)定性。

最后是用戶使用的標(biāo)準(zhǔn)化。 我們應(yīng)該避免提供太多的不確定給用戶，而是只給一個標(biāo)準(zhǔn)答案。我們應(yīng)該統(tǒng)一出一套最佳實踐來，在這個基礎(chǔ)上做好配套的優(yōu)化。這樣用戶可以輕松接入，并把這個過程輕松復(fù)制給其他人。提升效率的同時，也避免了因不合理的使用姿勢可能引發(fā)的故障。

3）排障智能化

• 服務(wù)監(jiān)控，系統(tǒng)監(jiān)控，外部依賴監(jiān)控
• 鏈路追蹤
• 自動報警

監(jiān)控的重要性毋庸置疑，我們需要在一開始就把監(jiān)控埋點納入到開發(fā)計劃中，而不是在某次故障后，才開始補(bǔ)充各種監(jiān)控指標(biāo)。

監(jiān)控埋點的要點在于能夠全面覆蓋產(chǎn)品主要流程，包括數(shù)據(jù)流和控制流，正常流程和異常流程。這個時候容易進(jìn)入的誤區(qū)是，過早的對埋點數(shù)據(jù)做處理。比如內(nèi)部有一個工作隊列，比起根據(jù)某個閾值打一個隊列是否繁忙的點，更合適的做法是直接打出隊列長度，這樣我們可以使用圖表來展示隊列的繁忙度變化，也可以靈活的設(shè)置告警。告警可是0值的空閑異常告警，也可以是100的繁忙異常告警。

無論是報警，鏈路還是監(jiān)控都是要服務(wù)于排障的，所以我們要站在的方便排障的角度，來設(shè)計和驗收這些指標(biāo)埋點。當(dāng)我們懷疑某處的打點是否必要時，可以看看是否對線上排障有幫助。

線上排障我們說要“智能化”，其實我們真正想做到的是“傻瓜式”的排障預(yù)案。能夠在故障發(fā)生第一時間收到報警，然后通過鏈路追蹤工具直接找到根因，最后通過預(yù)案按部就班處理。

4）管理自動化

• 最終“消滅”人工環(huán)節(jié)
• 用戶自助

自動化提升效率是我們的共識，自動化能夠幫助我們從大量的重復(fù)勞動中解放出來，提升工作效率。

那么如果量不是那么大，也不是那么重復(fù)的部分呢？是否還有必要自動化，比如審核等動作。

我認(rèn)為是必要的。當(dāng)我們發(fā)現(xiàn)某個部分不能自動化，想用人工的方式“糊弄”過去的時候，往往這就是我們沒有考慮清楚的地方，不徹底解決這個問題，這個問題就會像狗皮膏藥一樣一直拉低我們的用戶體驗。我們之前就遇到過這樣情況：新建邏輯庫可能會影響老邏輯庫，怕用戶填錯信息導(dǎo)致異常，我們就設(shè)置了好幾道人工審核來review。而事實上人工審核并沒有解決問題，反而阻礙了整體的自動化。最后我們重新設(shè)計了邏輯庫的配置隔離和回滾能力，自然自動化也不成問題了。

“消滅”人工環(huán)節(jié)很大程度是在掃清我們產(chǎn)品的潛在問題，是我們假裝看不見的地方。

用戶自助也是類似的，一個能夠自助的系統(tǒng)意味什么呢？意味我們的系統(tǒng)是健壯穩(wěn)定的，我們有良好的隔離設(shè)計，有強(qiáng)大的容錯能力。把自助當(dāng)成目標(biāo)，是建設(shè)更好的產(chǎn)品的良好推動力。

總的來說，可運(yùn)維性影響軟件后期所要投入的“隱性成本”，是一種高回報的長遠(yuǎn)的投資。

四、解決的問題及收益

這里總結(jié)下自建數(shù)據(jù)庫中間件帶來的收益。

• 提升研發(fā)效率；
• 提升運(yùn)維效率；
• 提升系統(tǒng)穩(wěn)定性；
• 保持廠商中立，實現(xiàn)“云自由”。