網易馬進：DDB從分散式資料庫到結構化資料中心的架構變遷

導語： 本文根據馬進老師在2018年5月10日【第九屆中國資料庫技術大會(DTCC)】現場演講內容整理而成。

馬進 網易 DDB專案負責人

來自網易杭研大資料平臺組，入職以來先後參與了分散式資料庫DDB，快取NKV，網易資料運河NDC等專案，目前是DDB專案負責人，主導資料庫中介軟體的各種專案研發。專注於分散式系統架構與資料庫技術，熱衷於構建高效的，高效能的分散式後臺應用。

摘要：

分散式資料庫DDB是網易研發最早的分散式系統，過去十幾年來一直為網易各大網際網路產品提供穩定透明的分庫分表服務，四年前我們推出了私有云DDB，為開發和運維人員在使用DDB和彈性伸縮上提供了極大便利；一年半之前我們從DDB的線上資料遷移模組中分化出來一套平臺化的異構資料庫資料遷移、同步和訂閱服務NDC；現今隨著網易內外部應用的網路環境更加複雜，應用場景日益繁多，對DDB的易用性，平臺化，面向機房和多租戶的解決方案提出更多需求和挑戰，這次分享將帶大家一起見證DDB在向結構化資料中心進化過程中的思考和架構變遷。

正文：

DDB發展簡介

DDB：一步到位的分散式資料庫

 

DDB是一個分庫分表資料庫，管理成千上萬個資料節點，並且可以支援PB級結構化資料儲存。目前公司內部使用的版本基本上都是查詢伺服器模式，查詢服務和儲存服務相分離，可以分開進行水平線性擴充套件以及可以支援百萬級的qps。此外，DDB還支援線上資料遷移的功能，可以支援每日GB-TB資料增長並且有標準化的訪問協議。

DDB的線上遷移功能本質上是我們分散式資料庫的一個核心需求，目前我們分庫分表架構還是將它定義為運維人員需要參與的過程。業界中說我們這種方式有上一代資料庫的感覺，其一是因為它還不夠標準化，其二是因為資料庫縮容還需運維人員的參與。但我個人覺得這屬於一個設計哲學的問題，我們可以很好的解決這兩個問題，但歸根結底還是要看它的運維和使用成本有多低。

左邊這張圖是我們資料庫的成本曲線。單機資料庫隨著資料規模和訪問規模的提升，成本曲線成長很不線性。例如，我們一旦達到了商務機器成本上線，往上擴容成本就很大。如果使用分庫分表分散式資料庫，我們能很好的實現儲存和查詢功能的線性擴充套件，它的使用方式能達到我們的要求，自然就會得到一個理想的線性曲線。

DDB發展歷程

2006年DDB第一個版本上線，當時的功能相對比較簡單，就是一個簡單SQL相容和部分管理功能。概括的說，從2006年的V1版本到2010的V3版本，都是一套驅動模式，我們內部叫做DBI模式。2012年，隨著私有云上線，我們開發了查詢伺服器，可以支援多語言，在查詢伺服器內部提供豐富的SQL統計功能。同時，我們在雲端計算的管理平臺上提供雲端計算DDB Pass服務，可以進行一鍵部署和管理監控。2017年之後，我們開始研發DDB 5.0版本，逐漸簡化架構並且把相關服務做了模組化的拆分，以及進一步擴充了SQL的相容度。

DDB功能特性：資料通道

在資料通道方面，第一，我們有比較好的均衡方式，有兩級對映的功能，有應用自定義配置的雜湊函式。

第二，我們有比較高的標準化，SQL 92能達到90%的相容度，5.0之後達到了95%。並且我們支援全域性自增ID、explain計劃，有資料標準匯入匯出，查詢伺服器相容MySQL通訊協議。

第三，我們支援分散式事務。業內很多專家人士可能會吐槽兩階段提交協議不可靠，但我認為ACID本質上是一個機率問題，兩階段提交協議的ACID功能在機率上遠不如單機版的事務，但並不代表它的可靠性沒有提升。另外，我們也會跟應用強調，業務場景裡涉及到的敏感資料交易。並且我們分散式事務兩階段提交協議的實現對使用者是透明的，內部會有一些最佳化措施，並不是所有的事務都是兩階段提交。最後強調一點，分散式事物兩階段提交協議在效能上還是存在瓶頸，在業務中我們也會跟應用具體強調。

第四，我們提供Hint功能，可以在DDB內部實現讀寫分離，然後實現SQL自定義路由。

第五，我們在查詢伺服器層面提供豐富的統計功能，包括SQL模式統計、SQL頻度統計、慢SQL 統計、多維度QPS統計。

DDB功能特性：管理通道

在管理通道方面，需要特別說明的是我們相容MySQL管理語法，建立表等操作都跟MySQL在語法上高度一致，使用者管理上也比較類似。並且，我們線上資料遷移功能提供較多的是場景化的線上遷移。前期應用在建立表的時候，如果沒有選擇好分割槽欄位，我們可以在管理工具上做分割槽欄位更改的操作，底層就會實施資料重分佈。另外還有一些擴充套件功能，比如定時任務、懸掛事務報警。在高可用方面，我們查詢伺服器是一個熱備的，底層的資料庫也是比較經典的主從架構，內部做了自動fail-over機制。

DDB核心優勢

DDB的核心優勢，第一，有標準化的訪問協議，有較高的SQL相容度。第二，分散式事務能夠保證資料的高一致，有較完善的圖形化管理工具、線上擴縮容功能。第三，所有的元件都是高可用的。

DDB V1-V3架構：DBI模型

DDB架構過去十年的變遷：

這是V1-V3的經典架構，在這套架構裡，分庫分表實現在驅動層。在應用端，它們會依賴我們提供的JDBC驅動的jar包來訪問DDB。DDB內部的語法解析執行計劃都在驅動層做。另外，我們有一個Master元件，負責整個叢集的後設資料管理和同步。

但這套叢集也會帶來一些問題。第一，從語法解析到執行計劃到最後的結果集合並，DBI內部的這些實現比較耗費CPU。第二，在這種架構裡，DDB版本很難管理。第三個問題比較嚴重，尤其對於提量大的應用。DBI跟隨應用層做水平擴充套件，如果我們發現體量不夠，就要加應用伺服器，DBI也會跟著增加，訪問底層資料庫節點的連線數也會隨著增加，這樣就很可能會導致底下資料庫被打爆的問題。

這套架構也比較經典，很多小夥伴應該能看出來這套架構跟阿里TDDL比較相似。但很重要的一點區別是我們的叢集管理比較獨立，每一套叢集都有一個單獨的Master做管理。這個跟我們公司的背景也有關係，例如淘寶當初做中介軟體，是為了淘寶的核心業務服務的，它只需服務於一個業務。但網易不一樣，從一開始網易內部就有很多不同型別的產品，比如網易考拉、網易音樂兩個截然不同的應用，一個是典型的電商場景，一個是典型的讀多寫少場景，這就要求把不同的叢集隔離開。

DDB V4架構：QS模式

DDB V4是提供查詢伺服器的，這套架構就相當於透過單獨部署QueryServer元件，把DBI包起來，然後對應用提供一個標準的MySQL協議支援。同時在Query Server和應用之間部署LVS\HAPProxy+keepplived組合做負載均衡。

如圖所示，應用發起一個請求要透過LVS、QueryServer到最後的資料庫，這套架構比原來的架構多了兩次轉發，鏈路或許會有點長，但卻很好的解決了之前DBI存在的問題。

首先Query Server的數量和應用的數量沒有繫結關係。其次Query Server由平臺的運維人員部署，我們能追蹤它的版本管理和內部問題定位。

除此之外，在叢集管理上我們還是沿用老一套，包括管理工具。

DDB V1-V4：小結

﹣DBI模式

• 部署簡單，省機器

• 對JAVA應用較為友好

• 問題跟蹤和定位成本高

• 佔用比較多應用端的CPU資源

• 版本升級週期長，新功能推廣困難

  ﹣QS模式

• 多語言支援，整合任意連線池和DAO

• 版本便於管理，跟蹤定位問題成本大大降低

• 慢語句，TopSQL等功能便於SQL最佳化

• 連線收斂，連線池熔斷等功能提升可用性

DDB v5：LBDriver

DDB V4雖然解決了之前DBI模式的各種問題但還是會有一些潛在問題。

首先就是之前提到過的鏈路長的問題。其次，LVS透過連線做負載均衡存在弊端。第一，在低峰期活躍連線數比較少的情況下，無法保證這些活躍連線數均勻分散到每個Query Server上，如果使用雲端計算部署查詢伺服器，這種不均衡容易導致CPU使用率飆升。另外一點，使用LVS做負載均衡，在應用端cancel語句或query timeout情況下，建立臨時連線執行kill query指令的時候，可能建立的臨時連線落到另外一個QueryServer上，這樣如果這個節點上沒有一樣的connection id，那相當於cancel或timeout沒有實現，如果有connection id，相當於錯誤的kill掉了一個連線。

因此，我們給應用提供了一套全新均衡方案：在應用端的連線池和驅動之間開發了一個loadbalance driver元件，這個元件包裝了JDBC驅動，對連線池提供邏輯連線，並與各個QueryServer的物理連線實現對映。在連線池使用連線的過程中，它會按照SQL請求做負載均衡，這樣首先解決了LVS不能夠按照請求去均衡的問題。其次，在連線超時的情況下，能夠拿到底層的真實物理連線，並透過它複製臨時連線來執行kill指令。

最後，我們的lLBDriver不會給應用帶來遷移成本，因為它本身就是一個JDBC驅動，應用使用lLBDriver時 ，只需要配置裡更改下driver名稱和URL就可以了。

DDB V5：去master

這是DDB V5的架構。除了透過LBDriver做負載均衡外，我們還去掉了Master元件。原因第一是出於省成本考慮。第二，Query Server本身是一個我們自己去掌控的服務端，所以完全可以用它去做一些管理上的功能，QueryServer之間本身互為熱備，在實施了master的部分功能整合到QueryServer上後，在多個QueryServer之間選擇一個leader作為管控節點，這樣同時解決了我們管理功能的高可用問題。

DDB V5：面向租戶的WEB管理工具

DDB V5版本還提供了面向租戶的WEB管理工具。因為之前實踐私有云的Pass服務時，最大的感觸就是，面向租戶的管理方式能夠很大程度上減少運維人員在運維上的開銷和代價。除此之外，我們還在這套WEB管理工具裡還提供了SQL統計，稽核，報表和大屏服務等。

DDB V5：NDC服務拆分

DDB V5還做了服務拆分。我們把DDB以前的線上資料遷移元件拎出來獨立做了一套NDC服務，全名Netease Data Canal，直譯為網易資料運河系統。它除了可以做DDB線上資料遷移之外，也可以把MySQL的binlog獨立拉出來做一些複雜的ETL，這樣我們中介軟體產品棧就會更加豐富。

DDB V5：面向IDC的解決方案

最後，我們在DDB V5裡面提供了面向IDC的解決方案。DDB V5做的最大的改進就是架構精簡化。我們一般怎樣評價一個分散式系統是一個好分散式系統呢？例如Hadoop，它給我們最大的感受就是複雜。但它會提供 Standalone模式，透過一臺機器和一些簡單的指令就可以拉起一個系統，這是所謂的重中有輕，我們DDB也希望做到這一點。

我們最簡單的一個QueryServer整合了分庫分表和相關管理功能，這樣我們只需要部署一個QueryServer和資料節點，分散式資料庫就能建立起來，並且具有DDB整套功能集。後面這些管理工具、元件都是選裝的，即便沒有它，DDB也可以使用。

DDB的WEB管理工具透過DDL向QS管控節點發起管理操作，可以把它當做更加豐富的上層功能。值得一提的是，這個管理功能可以跨IaaS，一套叢集裡它既可以有物理部署也可以在雲端部署。我們提供了可插拔的介面，可以在上面做不同的IaaS層適配，好處是在不同的物理平臺或雲平臺上我們可以用統一的介面去運維和使用它。

DDB V5：小結

﹣降低各種成本

• 架構精簡，去master，降低學習和部署成本

• 以LBDriver替換LVS，提升可用性，降低使用成本

• QS相容MySQL DDL，向標準化更加邁進一步

• 面向租戶的平臺化方案，降低部署和運維成本

• 透過平臺化的NDC支援線上資料遷移和同步

﹣從軟體包到解決方案

• 面向IDC的解決方案，透過NDC實現異地同步

• 跨IaaS的支援，物理環境和雲環境混合部署

結構化資料中心——DDB以及NDC規劃和瞻望

這是我們比較經典的一個多機房資料庫和快取的架構。單機房內部一般會有應用層、快取層以及資料庫層。傳統架構一般是應用層在執行資料庫操作之後，由它們去負責更新快取。但如果我們把這種模式遷移到多機房場景，另一個機房的cache就很難維護。另外，它還可能導致資料不一致。

一個比較好的方法就是透過binlog方式，把每一個機房的binlog拉出來，由NDC資料訂閱功能去執行快取的淘汰或更新。這種場景下我們可以把NDC當做DDB的一個跨系統的觸發器。這個在業界算是一個較成熟的方案，在很多的網際網路公司得到了廣泛應用。

在這套架構裡，DDB和NDC可以看成一個有機整體，如果我們把NDC當成DDB的一個觸發器來看，它就可以被當做成一個系統來用。

以NDC為總棧的架構

這是一個更加複雜的架構，除了在不同的機房之間做資料同步之外，在一個機房內部也可以透過NDC做異構的資料庫線上遷移。同時，我們可以用NDC做一些同機房內部的資料訂閱滿足一些下游應用的解耦。

這套複雜的架構裡還存在很多可以被挖掘的點。例如，在不同的系統之間做資料同步，首先每一個系統要配合一個管理介面，然後需要把每一個系統之間的使用者許可權打通，由運維人員配NDC任務。但這個過程中會有很多管理上的壁壘，我們做一個簡單的需求總結：

﹣ODMP潛在需求

• 各個資料系統之間管理方式有壁壘

• 缺乏統一的資源劃分，認證方式

• 各個系統間許可權不通，需要人工同步

• 沒有統一的監控，部署平臺

• 傳統的工單流程容易造成資源浪費

﹣ODMP（線上資料管理平臺）

• 可插拔，可擴充套件，易整合，面向IDC的資料系統管理平臺

• 整合租戶管理，許可權同步，資源池管理，報警監控，自動部署

• 基於NDC實現異構系統和IDC間資料同步（核心實現）

這是我們最終想要達到的效果。其實我們內部已經實現了這些功能，但都是彼此獨立不相同的。我們希望建立一個統一標準進行統一維護，這樣就能很大程度降低運維和使用成本。

兩個問題

一路下來我們總結出這兩個問題。其一：為什麼我們在做應用的時候團隊越大，DEVOPS門檻越高？

隨著我們應用發展、團隊成長、規模擴充，面臨的業務場景越加複雜，需要做的技術選型越來越多，開發人員從調研到測試、從部署開發到最後運維，長期處於這樣的迴圈裡。一套成熟的系統進入到一個比較正規的運維流程往往需要一個很長的週期。

其二：在這個過程中做中介軟體，怎樣做可以降低成本？

第一，儘可能自動化，減少工單流程。第二，儘可能挖掘出平臺運維的角色，即我們開發人員，開發人員本身就是DBVOPS，可以直接面嚮應用開發，這樣可以省去運維人員的介入。第四，注意各個平臺和系統之間的串聯，這一點也是ODMP的本質問題。

ODMP：hybrid console

hybrid console相當於一個DDB的命令列工具，可以選擇訪問QueryServer的節點。我們可以對這個功能進行這樣的一些展望：在選擇節點之前是否可以選擇要訪問的系統，是否可以在同一介面進行這些操作，具體訪問了哪個系統是否可以隱藏起來。目前，業界很多產品都在朝這個方向發展，hybrid這種訪問方式或許會成為未來的主流趨勢。

總結

﹣DDB十年架構變遷

• V1-V3：驅動模式，滿足JAVA應用所需

• V4：代理模式，多語言支援，增強可用性和運維能力

• V5：平臺模式，精簡掉lvs和master，面向租戶和IDC的解決方案 

﹣ODMP展望

• 脫胎於DDB和NDC對平臺化的理念

• 核心價值：打通異構線上資料系統的壁壘，實現統一的部署，監控， 租戶認證，許可權打通，使大團隊中DEVOPS成為可能

• 核心實現：基於NDC實現異構系統和IDC間資料匯流排