適配混合云，貨拉拉的數(shù)據(jù)庫(kù)中間件建設(shè)之路

作者：林靜 2022-04-01 10:55:30

數(shù)據(jù)庫(kù)

云計(jì)算 自建數(shù)據(jù)庫(kù)中間件正是其中不可或缺的一環(huán)—— “適配混合云，數(shù)據(jù)庫(kù)中間件的建設(shè)之路”，正是這次我要和大家探討的主題！

創(chuàng)新互聯(lián)專注于企業(yè)全網(wǎng)整合營(yíng)銷推廣、網(wǎng)站重做改版、長(zhǎng)島網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5頁(yè)面制作、商城網(wǎng)站建設(shè)、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為長(zhǎng)島等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

林靜

JAVA 技術(shù)專家

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

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

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

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

一、背景

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1、核心功能與特性

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

1）模版式分庫(kù)分表，讀寫分離

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

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

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

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

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

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

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

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

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

3）SQL鏈路追蹤與SQL治理

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

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

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

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

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

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

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

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

• DB遷移影響  — 秒級(jí)中斷

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3）排障智能化

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

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

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

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

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

4）管理自動(dòng)化

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

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

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

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

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

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

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

四、解決的問題及收益

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

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

文章標(biāo)題：適配混合云，貨拉拉的數(shù)據(jù)庫(kù)中間件建設(shè)之路
網(wǎng)頁(yè)URL：http://m.fisionsoft.com.cn/article/dpohoeg.html