為內(nèi)容面很大，我的整體思路是從一些概念的邊界入手來進行相關策略的推導，過程中會側(cè)重展開一些落地的案例和設計思想，我將通過如下4個部分的內(nèi)容來進行闡述。

一、關于架構(gòu)思路和一些概念邊界

1.為什么需要數(shù)據(jù)庫分布式架構(gòu)？

首先需要有一個整體的認識，為此有一個靈魂拷問：為什么需要數(shù)據(jù)庫分布式架構(gòu)？答案確實是千人千面，為此我整理了一個比較粗略的圖來說明我的觀點。

早期的數(shù)據(jù)庫架構(gòu)模式主要是單機模式。單機模式雖然也能滿足我們早期一些業(yè)務需求，但是隨著數(shù)據(jù)規(guī)模的擴大以及業(yè)務的快速增長，對單機數(shù)據(jù)庫體系有了更高要求，從而延伸出以下幾個發(fā)展方向：

1）通過更高級配置、擴大容量等方式將原本的單機數(shù)據(jù)庫變得更大更強，在這種情況下，數(shù)據(jù)庫會變成一個“超人”，如上圖所示的“超人”。

2）將業(yè)務分為多個部分完成，這種模式發(fā)展到后期可能會產(chǎn)生多個分支，如果容量越來越大，需求的復雜度會越來越高，可能涉及到集群模式管理，如上圖所示的“三個工人”和”兩個超人”。

3）集群模式可能會延伸出另一種模式，當原本的單機模式難以擴展時，我們可以將原本的高配單機增加至兩個或者多個，然后通過業(yè)務拆分來完成，這種情況可能會導致一種尷尬局面，容量足夠的情況下部分配置存在上限，例如達到一定程度后數(shù)據(jù)庫會變得“臃腫”。為解決這一問題，人工難以承載的業(yè)務可以基于代理層來實現(xiàn)，如上圖所示的“六個工人+代理人”。

4）上述第三種模式再進行延伸，可能出現(xiàn)另一種模式，將數(shù)據(jù)存儲與數(shù)據(jù)管理分離，即將數(shù)據(jù)存儲與數(shù)據(jù)計算分離，這一過程需要相關的調(diào)度管理進行銜接和協(xié)作，如上圖右側(cè)所示。

以上內(nèi)容通過一個小案例講述了為什么需要數(shù)據(jù)庫分布式架構(gòu)，可能初聽“數(shù)據(jù)庫分布式架構(gòu)”有些拗口，下面將對分布式數(shù)據(jù)庫與數(shù)據(jù)庫分布式架構(gòu)這兩個概念進行區(qū)分。

2.概念邊界

這些年來分布式數(shù)據(jù)庫、云原生數(shù)據(jù)庫的概念都很火熱，同時分布式架構(gòu)、微服務架構(gòu)等在行業(yè)內(nèi)也有大量的落地場景和最佳實踐。我們通常所說的分布式數(shù)據(jù)庫和數(shù)據(jù)庫分布式架構(gòu)還是有一定的區(qū)別的，但是又存在一定的關聯(lián)，就好比如下的包含關系一樣，是一種層級遞進的關系。

對上面的圖我提煉出幾個要點：

• 分布式數(shù)據(jù)庫是分布式架構(gòu)的重要一環(huán)，但不是完全強依賴，也就意味著業(yè)務層的架構(gòu)設計好壞能夠直接影響整體的架構(gòu)質(zhì)量。
• 數(shù)據(jù)庫分布式架構(gòu)的發(fā)展空間相比于分布式數(shù)據(jù)庫更大，它更貼近于業(yè)務，分布式只是數(shù)據(jù)庫分布式架構(gòu)的一種演進策略。
• 云原生數(shù)據(jù)庫是分布式數(shù)據(jù)庫的一種演進形式，相對來說更為垂直。

如上圖左側(cè)圖形所示，做分布式涉及到的整體成本相對較高，并且在硬件、軟件、開發(fā)測試等方面存在差異。

目前分布式數(shù)據(jù)庫的版圖大體分為三類：基于分片模式的數(shù)據(jù)庫集群，基于NewSQL的分布式數(shù)據(jù)庫和云原生數(shù)據(jù)庫三大類，在不同的分類中都有相應的典型代表和頭部玩家，他們都有各自擅長的業(yè)務場景和領域，目前來看基于分片模式的數(shù)據(jù)庫集群的發(fā)展相對成熟，而基于NewSQL和云原生數(shù)據(jù)庫的發(fā)展這些年增長很快，目前已然是一種新的數(shù)據(jù)庫架構(gòu)演進趨勢。說到架構(gòu)，必然需要考慮架構(gòu)的考量維度。

3.通用架構(gòu)能力

通常會按照如下的三個維度來進行整體的架構(gòu)考量：彈性擴展，高可用和高性能，這三個維度能夠大體衡量架構(gòu)設計的目標是否滿足預期。

1）彈性擴展。原本的單機可能不夠用，我們可以通過彈性擴展方式將原來的水平擴展演進為彈性擴展。

2）高可用。通過架構(gòu)能力可以實現(xiàn)中間件節(jié)點高可用、數(shù)據(jù)節(jié)點高可用等整體的高可用。

3）高性能。架構(gòu)能力可以在讀寫性能方面做到更高能力支撐。

至此，我們從一些概念和架構(gòu)考量維度上有了一個整體的認識，那么前面說到架構(gòu)是需要持續(xù)演進的，那么到底有什么架構(gòu)策略，是否可以大一統(tǒng)呢？我打算從單機和數(shù)據(jù)兩個維度來推導架構(gòu)的策略。

二、從單機和數(shù)據(jù)維度推導架構(gòu)策略

架構(gòu)的演進通常是依據(jù)需求和業(yè)務的發(fā)展動態(tài)適配的，如果單機配置能夠滿足容量，性能等資源需求，在開發(fā)設計周期和系統(tǒng)復雜度層面都是一種比較理想的平衡狀態(tài)，也是比較建議的，但是很多業(yè)務發(fā)展趨勢不是線性的，而是指數(shù)級的變化和增長，這種情況下就需要在先期的架構(gòu)設計中進行預防性架構(gòu)設計，也就是我們在設計初期就不能從潛意識中偷懶，等到業(yè)務發(fā)展的速度和后端的改造能力不匹配的時候，問題就會接踵而至，而很多在前期沒有考慮到的問題在基于分布式設計時，無論是開發(fā)周期和系統(tǒng)復雜度都會難以接受。

1.單機維度推導架構(gòu)演進策略

單機模式下的分布式架構(gòu)可以拆分為三個維度：系統(tǒng)配置、數(shù)據(jù)庫配置和數(shù)據(jù)庫相關服務管理。

1）系統(tǒng)配置

系統(tǒng)配置包括CPU、內(nèi)存等，相對來說是一個固化的模式，對其進行擴展的難度較低，其成本也已經(jīng)隨著硬件的發(fā)展大幅度降低，簡單來說，如果在成本可控范圍內(nèi)，花錢升級硬件就能解決。

2）數(shù)據(jù)庫配置

數(shù)據(jù)庫配置包括單庫容量、單表容量、連接數(shù)和吞吐量等，其中單庫容量擴展存在一定瓶頸。綜合來看，對數(shù)據(jù)庫配置做擴展會有些難度，但是這個時候有些復雜度，不是單純升級硬件就能夠解決的，比如我曾經(jīng)管理過一張表，容量有1T，對于單機來說是需要相當謹慎的，這里的難度等級約為中等。

3）服務管理

服務管理包括負載管理、高可用管理、事務管理、運維管理等。在事務管理的復雜度方面，單機模式比分布式好一些。在管理模式上，單機模式使用了All In One模式，算是集中式管理，而分布式管理需要大量的自動化運維支撐。分布式管理在負載管理和高可用管理方面相比于單機管理有較大提升。在混合負載方面，原本的單機模式是整個服務的整體覆蓋，但在分布式架構(gòu)體系內(nèi)要考慮整體負載能力的提升，不能因為單一節(jié)點的短板導致整個集群被拖垮，整體的難度相對較高。

2.數(shù)據(jù)維度推導架構(gòu)演進策略

首先將數(shù)據(jù)分為以下三個維度：

1）流水型數(shù)據(jù)

流水型數(shù)據(jù)是無狀態(tài)的，多筆業(yè)務之間沒有關聯(lián)，每次業(yè)務過來的時候都會產(chǎn)生新的單據(jù)，比如交易流水，支付流水，只要能插入新單據(jù)就能完成業(yè)務，特點是后面的數(shù)據(jù)不依賴前面的數(shù)據(jù)，所有的數(shù)據(jù)按時間流水進入數(shù)據(jù)庫。

2）配置型數(shù)據(jù)

配置型數(shù)據(jù)即我們所說的配置中心字典，數(shù)據(jù)字典配置等。此類型數(shù)據(jù)數(shù)據(jù)量較小，而且結(jié)構(gòu)簡單，一般為靜態(tài)數(shù)據(jù)，變化頻率很低。 

3）狀態(tài)性數(shù)據(jù)

狀態(tài)型數(shù)據(jù)是有狀態(tài)的，多筆業(yè)務之間依賴于有狀態(tài)的數(shù)據(jù)，而且要保證數(shù)據(jù)的準確性，例如賬戶余額，做充值時必須要拿到原來的余額才能支付成功，因此狀態(tài)型數(shù)據(jù)整體的維護最復雜，是我們現(xiàn)在做分布式事務管理的核心部分。

基于以上數(shù)據(jù)類型分類我們可以延伸出三類表：字典表、日志表和狀態(tài)表。

在架構(gòu)設計上和演進方面，配置型和流水型數(shù)據(jù)的擴展方案相對比較豐富，通常不需要事務管理，所以擴展和性能方面表現(xiàn)都很出色，方案落地性更強，難度最大的是狀態(tài)型數(shù)據(jù)，因為它存在數(shù)據(jù)的關聯(lián)和依賴，所以需要事務管理，在擴展性和性能方面的解決方案不夠完美，需要做一定的取舍，如事務降維，或把數(shù)據(jù)強一致性的需求降為最終一致性等。

下面將對這三類表進行對比架構(gòu)演進策略的解讀。

① 數(shù)據(jù)量

字典表的數(shù)據(jù)量最小，日志表數(shù)據(jù)量極大，狀態(tài)表的數(shù)據(jù)量大小與業(yè)務規(guī)模相關。

② 數(shù)據(jù)依賴

字典表基本不存在事務依賴，即使有，也只存在于極少數(shù)的配置中；日志表沒有事務依賴，所以改造日志表的切入點比較好找；狀態(tài)表整體有事務依賴。

③ 業(yè)務特點

字典表整體上為讀多寫少的模式；日志表的著重點為大批量密集型讀寫，整體為讀少寫多的模式；狀態(tài)表整體為讀多寫多的模式。

④ 架構(gòu)策略

• 架構(gòu)1.0策略

我們通常基于讀寫分離的模式對字典表做擴展改進。對于日志表，我們需要考慮提前做拆庫、拆表，我們將這種模式稱為周期表。對于狀態(tài)表，我們可以通過讀寫分離的模式對讀這部分的流量做緩解，但并不能從根本上解決問題。

• 架構(gòu)2.0策略

對于字典表可以采用全局的分庫分表方式。對日志表主要使用業(yè)務路由和數(shù)據(jù)庫中間件。狀態(tài)表相較于前兩者更為復雜，其中一種方式是分庫分表，另一種方式是基于分庫分表模式做事務降維或整體的過程中直接做事務降維。事務降維包括兩種方式，一種是在整個的過程中根據(jù)業(yè)務的特點不啟用事務，另一種是在設計中將事務的維度或顆粒度降到最低，基于最小化的分片維度執(zhí)行操作。

⑤ 系統(tǒng)優(yōu)化策略

字典表的優(yōu)化比較清晰，我們可以通過緩存模式進行優(yōu)化，該方法可解決大部分問題。日志表在寫入過程中，實時延遲不會很高，我們可以基于隊列采用異步方式提升整個系統(tǒng)的吞吐量。狀態(tài)表主要對讀這部分的狀態(tài)因數(shù)據(jù)做緩存。在系統(tǒng)優(yōu)化策略維度，字典表和日志表比較容易進行優(yōu)化，狀態(tài)表的加工改造策略是重難點，而且整個過程中也無法徹底解決問題，對設計的整體要求也較高。

⑥ 建設目標

字典表適用于建設配置中心，日志表適用于建設賬單存儲平臺，狀態(tài)表適用于建設數(shù)據(jù)中臺。

三、架構(gòu)演進與案例分析 

這部分我將架構(gòu)的演進歷程分為1.0、2.0、3.0三個階段，便于下文講述，該劃分方式并無嚴格的優(yōu)劣之分。

架構(gòu)1.0階段的主要策略為垂直拆分、拆庫拆表以及讀寫分離。

架構(gòu)2.0階段的主要策略為基于數(shù)據(jù)庫中間件和業(yè)務路由的分布式方案。

架構(gòu)3.0階段的主要策略為基于云關系型數(shù)據(jù)庫和分布式關系型數(shù)據(jù)庫的方式。

在整個架構(gòu)以及架構(gòu)策略的演進過程中，整體模式與前文中提到的模式相似。單機模式通過業(yè)務拆分或者2.0階段的業(yè)務路由和數(shù)據(jù)庫中間件策略滿足業(yè)務需求。在3.0階段，通過存算分離以及調(diào)度層統(tǒng)籌滿足業(yè)務需求。以下對每個階段進行詳細解讀。

1.架構(gòu)1.0階段和案例

在這一階段，我們采用了拆庫拆表的方式將商業(yè)數(shù)據(jù)庫遷移到MySQL中。原本我們可能處于單機模式，在整個單機模式下，我們通過拆庫拆表方式將業(yè)務拆分到兩個相對獨立的服務器上，再實現(xiàn)日志數(shù)據(jù)的異步寫入。對于狀態(tài)型數(shù)據(jù)，我們可以做讀寫分離的改進。

在1.0階段，我們通過拆分隔離將業(yè)務進行拆分，包括兩種拆分方式：

1）將大的狀態(tài)型業(yè)務拆分為兩部分，一部分為全局型業(yè)務，另一部分為特定某個去向的業(yè)務。例如游戲公司有20款游戲，我們將這些游戲的公共屬性數(shù)據(jù)拆分出來在平臺層重組，再針對不同游戲的獨特屬性數(shù)據(jù)進行擴展。

2）在單機模式下將日志型數(shù)據(jù)和狀態(tài)型數(shù)據(jù)進行拆分。日志型數(shù)據(jù)拆分難度較低，通過數(shù)據(jù)庫中間件即可實現(xiàn)。拆分日志型數(shù)據(jù)的過程中，面對大量讀的要求可以通過一主多從的方式進行讀寫分離的改進。

在這一階段，對數(shù)據(jù)量極大的表進行變更很困難，簡單來說，單機數(shù)據(jù)庫中對于流水型數(shù)據(jù)存在明顯的瓶頸，比如一張表每天產(chǎn)生20G的日志，那么單機容量的規(guī)格假設是300G，就僅僅能夠保存2周左右的數(shù)據(jù)，而數(shù)據(jù)清理通常需要業(yè)務側(cè)寫相應的邏輯進行定時處理，在數(shù)據(jù)庫負載和查詢性能方面都有一定的隱患。為改善這一問題，我們提出了周期表的概念，根據(jù)時間將表分為日、周、月、年和幾年五個維度，日志數(shù)據(jù)都可以按照這五個維度進行拆分。將日志數(shù)據(jù)根據(jù)周期表進行拆分的好處是便于對數(shù)據(jù)進行清理，整個清理過程中維護代價也較低。我們?yōu)榱寺鋵崝?shù)據(jù)清理工作也做了一些狀況類化，例如DBA實現(xiàn)表的自動擴展與自動清理。對表進行清理并非對現(xiàn)有表直接清理，而是設置一個期限，例如一個月，超過期限后將表放入回收站中，再對表內(nèi)容進行操作，操作過后將表放置到另外的庫中，超過一定期限后逐步清理。這整個過程中，如果有一些數(shù)據(jù)需要恢復，我們可以快速重置。現(xiàn)在我們已經(jīng)接入了四五百個周期表，形成了自循環(huán)的管理模式，而對于公司整體業(yè)務來說，幾乎很難看看到一些數(shù)據(jù)量恐怖的表，因為這些都通過這種設計模式基本杜絕了。

2.架構(gòu)2.0演進和案例

1）消息業(yè)務路由改造

架構(gòu)2.0階段首先做業(yè)務路由的改造。早期我們做消息業(yè)務的改造，例如打開APP后的消息推送，整體的吞吐量較大。在早期的業(yè)務中，對于消息存儲的數(shù)據(jù)統(tǒng)計要求較高，我們希望能夠盡快將消息推送抵達用戶并獲得反饋，使得整個業(yè)務運營形成閉環(huán)。

如上圖右側(cè)所示，是數(shù)據(jù)庫側(cè)的I/O使用情況，在進行I/O優(yōu)化的過程中，一個主節(jié)點難以承載負荷，所以我們將查詢需求擴展到了從節(jié)點做了讀寫分離，后期發(fā)現(xiàn)仍不能滿足要求，統(tǒng)計查詢還是非常卡頓，I/O使用率還是被打滿。我們進行了列式存儲擴展，將統(tǒng)計查詢遷移過去后提高了查詢效率，算是解決了查詢瓶頸問題，原服務的I/O使用率一下子降低了60%以上，再后來通過業(yè)務路由將一個節(jié)點動態(tài)擴展為三個節(jié)點，如上圖左側(cè)所示，性能又有了明顯改善，提升了20%左右，整個過程是一個循序漸進的優(yōu)化過程。 

2）數(shù)據(jù)庫中間件

第二類是基于數(shù)據(jù)庫中間件的模式，數(shù)據(jù)庫中間件方式需要考慮數(shù)據(jù)的重分布、數(shù)據(jù)的可用性和同城異地容災等。

基于這種架構(gòu)模式，我們也做了一些特色化的服務，主要有4點：

• 中間件負載均衡

數(shù)據(jù)庫集群架構(gòu)模式通過Consul服務把原來的三層結(jié)構(gòu)改成了兩層，實現(xiàn)了中間件層的負載均衡。

• 配置化建表

對于線上數(shù)據(jù)庫集群創(chuàng)建表的需求，我們通過配置實現(xiàn)數(shù)據(jù)表的定制化創(chuàng)建。比如我們需要我們創(chuàng)建一張表時，只需要在配置表里寫一條配置信息，之后我們會通過服務掃描配置變化，如果發(fā)生變化，就會在線上創(chuàng)建相關的表，保證業(yè)務的連續(xù)性，這個過程看似簡單，實際上對于集群的結(jié)構(gòu)設計要求是很高的。

• 數(shù)據(jù)流轉(zhuǎn)

對于集群的數(shù)據(jù)流轉(zhuǎn)，是數(shù)據(jù)分分合合的難點，我們通過流轉(zhuǎn)程序來實現(xiàn)，如DataX來進行數(shù)據(jù)聚合，為此我們構(gòu)建了一個中間層來統(tǒng)一流轉(zhuǎn)，后續(xù)的思路是直接將賬單存儲改造為NewSQL數(shù)據(jù)庫，直接提供實時數(shù)據(jù)交付。

• 只讀查詢

一些線上數(shù)據(jù)的復雜查詢也可以通過只讀中間件去做，把它掛載到一個只讀的中間件節(jié)點上可以平滑實現(xiàn)在線的數(shù)據(jù)查詢，后續(xù)打算通過雙集群模式（中間件+NewSQL集群）來提供平滑的讀寫需求。如果這4點的力道不足，那么中間件架構(gòu)還存在如下的兩個典型優(yōu)勢可以補充，分別是數(shù)據(jù)重分布和分布式集群組的存儲模式。

① 數(shù)據(jù)重分布

第一個優(yōu)勢數(shù)據(jù)重分布，因為中間件架構(gòu)優(yōu)缺點并存，我們在實踐過程中經(jīng)歷了很多考驗，對于中間件架構(gòu)來說，個人覺得它的一大特色就是拓撲結(jié)構(gòu)的可擴展性。比如硬件服務器在多年后需要過保替換，逐個服務器替換還是會產(chǎn)生系統(tǒng)抖動，如果有幾十個節(jié)點，這種替換其實會存在一定的風險，基于中間件架構(gòu)可以快速實現(xiàn)拓撲結(jié)構(gòu)擴展，如上圖所示，可以補充一套從庫節(jié)點，然后將中間件收縮，再將3層拓撲切換為兩層，對于幾十上百個節(jié)點的快速切換，這是一種很優(yōu)雅的模式，整個切換過程在3.5秒左右，當業(yè)務服務具備重連機制，集群內(nèi)部其實已經(jīng)發(fā)生了質(zhì)的變化。

② 優(yōu)勢分布式集群組/通用存儲方案設計

第二個優(yōu)勢分布式集群組/通用存儲方案設計，比如我們所說的數(shù)據(jù)庫分布式架構(gòu)整體需要去滿足業(yè)務需求，發(fā)現(xiàn)有很多數(shù)據(jù)表結(jié)構(gòu)都是相似的，在這種情況下，我們就可以實現(xiàn)動態(tài)、靈活的存儲管理模式。

主要分為兩個維度：第一，通用存儲意味著我們原來的一套集群不夠，我們可以再補一套集群實現(xiàn)，這樣就是集群組的模式。在這個層面上，我們就把集群下沉一層，在上層進行配置化的管理，在上層有一個全局配置；第二，我們通過全局配置可以快速靈活地生成一些定制化的表結(jié)構(gòu)，比如有的業(yè)務對于數(shù)據(jù)的存儲需求是varchar(32)，而有的是varchar(256)或者bigint，這些都可以在集群組中動態(tài)配置，從而適配不同的模板，通過這種靈活的配置管理的方式實現(xiàn)整個集群組數(shù)據(jù)的存儲管理。

3.架構(gòu)3.0演進和技術(shù)分析

我們經(jīng)常聽到云關系型數(shù)據(jù)庫和分布式關系型數(shù)據(jù)庫等概念。

個人經(jīng)過整理發(fā)現(xiàn)數(shù)據(jù)庫的整個演進過程中有許多故事。Google很早就開始在內(nèi)部孵化Spanner，2011年左右發(fā)布論文，論文發(fā)布后形成了兩個分支，一個分支對原本的模式不滿，另一分支從原本的模式中受到啟發(fā)對其進行了改進。以上兩種分支延伸出兩大派別，一種是基于Aurora模式，并基于此思想產(chǎn)生了Aurora數(shù)據(jù)庫，例如騰訊的CynosDB和阿里云的PolarDB等。另一種是受Spanner論文思想影響下產(chǎn)生基于另一體系的TiDB等數(shù)據(jù)庫。

從整體上看，兩大派別較大的差異在于Aurora等數(shù)據(jù)庫與MySQL沒有太大差異，整體采用了存算分離的架構(gòu)，而另一派別的數(shù)據(jù)庫是以NewSQL全新的設計體系，兼容MySQL協(xié)議的形式出現(xiàn)，兩者屬于不同的體系，在數(shù)據(jù)庫分布式架構(gòu)策略方面也有不同的實現(xiàn)，從早期的讀寫分離模式到周期表、中間件，后續(xù)還會有新型中間件等。

1）數(shù)據(jù)庫分布式架構(gòu)策略對比

其實云原生數(shù)據(jù)庫從某種概念上來說是彎道超車，云原生數(shù)據(jù)庫中以Aurora為典型代表的數(shù)據(jù)庫，其底層設計本質(zhì)為讀寫分離模式，但核心技術(shù)是分布式共享存儲，它是從讀寫分離的模式經(jīng)歷了大跨越的更新。

① 云原生數(shù)據(jù)庫-Aurora

我們簡單來看一下具有代表性的Aurora數(shù)據(jù)庫，是AWS在MySQL的基礎上進行了魔改，因為AWS對Spanner的事務處理能力不滿意，提出日志即數(shù)據(jù)庫，并重新設計讀寫分離集群，延伸出Aurora數(shù)據(jù)庫，其整體為6副本，底層基于S3，整體采用讀寫分離模式。

② CynosDB，PolarDB

CynosDB和Aurora有一些差異，但其整體還是存儲計算分離的結(jié)構(gòu)，基于Raft,將redo下推至存儲管理。PolarDB基于RDMA，沒有將redo下推至存儲，其本質(zhì)還是基于存儲計算分離的模式。

③ TiDB體系結(jié)構(gòu)

我們TiDB的調(diào)研時間較早，在早期也是在測試環(huán)境中沉淀了許久，然后逐步從日志型數(shù)據(jù)庫改造開始，逐步引入更多的業(yè)務范圍。

4.數(shù)據(jù)庫分布式架構(gòu)演進小結(jié)

通過總結(jié)我們在分布式架構(gòu)方面的實踐，我把整個分布式架構(gòu)分兩個維度，一個維度是從水平擴展的能力考量，另一個維度是從吞吐量這個方面考慮。如果原來的單機處于起點，垂直拆分可能有較大提升。

我們在2018年時已經(jīng)大量使用讀寫分離模式，當然讀寫分離模式對于很多敏感的業(yè)務不是那么嚴謹，但在很多數(shù)據(jù)不是那么敏感或者延遲不那么敏感的情況下，是一個相對簡單的架構(gòu)改進。

在演進過程中我們少走了一些彎路。我們對很多賬單表的數(shù)據(jù)提前做了布局和拆分，把它改造成周期表模式，周期表模式改造好后，我們目前為止很少見到數(shù)據(jù)量非常大的表，基于此，我們自然的引入了中間件的分庫分表方案。對于中間件集群的方案，我們后續(xù)有兩種模式，一種是做業(yè)務拆分，另一種是套入原來的通用存儲方案，通過配置化的方式實現(xiàn)集群組的管理。

這個階段后會有一個分界點，也是關于數(shù)據(jù)庫最后一個非常核心的點——事務管理。事務管理方面，一種方式是復雜的管理模式，另一種是最小顆粒度的事務管理。之后的新型的中間件還有NewSQL體系，我們都進行了嘗試，并在2021年落地了技術(shù)棧。

在此，我補充一些數(shù)據(jù)來對不同的架構(gòu)策略做一些對比。

從整個分布式體系來看，各方面有利有弊，我們要去理性看待一項技術(shù)，不一定NewSQL體系就是最好的。為保證觀點的嚴謹，我通過雷達圖從以下幾個方面進行了對標準版實例、數(shù)據(jù)庫中間件和NewSQL三者進行了評估。

• 事務管理

基于單機模式長周期的驗證，標準實例在事務管理方面最有優(yōu)勢。中間件在事務管理方面存在瓶頸。NewSQL集群的思路模型依托的是另一種體系，需要時間周期的驗證以及業(yè)務場景的匹配，所以其介于兩者之間。

• 驗證周期

單機模式有長時間的驗證周期。

• 遷移升級

三者在遷移方面都有相對成熟的體系。

• 高可用

相較于其他二者，NewSQL在高可用方面具有明顯優(yōu)勢。

• 擴縮容

在擴縮容方面單機模式相對受限。NewSQL在擴縮容方面最有優(yōu)勢，能夠?qū)崿F(xiàn)某種程度的彈性擴縮容。

• 性能

中間件的方案對于一些性能極度敏感，在有良好設計的情況下，其整體性能更有優(yōu)勢。

綜上所述，應該根據(jù)不同的場景選擇適合的方案，切勿一刀切。

四、技術(shù)展望和小結(jié)

1.數(shù)據(jù)庫架構(gòu)演進趨勢分析

1）數(shù)據(jù)庫生態(tài)之國產(chǎn)化

從整個數(shù)據(jù)庫架構(gòu)的演進過程來看，現(xiàn)在的數(shù)據(jù)庫生態(tài)變得越來越多元化，同時也存在一定的差異化和風險，在此我想多提一下國產(chǎn)化數(shù)據(jù)庫，因為這是生態(tài)中不可或缺的。

目前國內(nèi)的數(shù)據(jù)庫國產(chǎn)化程度還是比較高的，如果從近些年來研發(fā)技術(shù)和數(shù)據(jù)庫的緊密結(jié)合來看，很明顯研發(fā)方向是在降低對于數(shù)據(jù)庫的重邏輯依賴，轉(zhuǎn)而通過分布式技術(shù)架構(gòu)來滿足性能和擴展性等強烈需求，而互聯(lián)網(wǎng)作為開源技術(shù)的試驗田，提供了大量的業(yè)務場景使得開源軟件能夠不斷成熟迭代。在功能實現(xiàn)上，國產(chǎn)數(shù)據(jù)庫也更為貼合國內(nèi)用戶的使用需求和體驗。從這個層面來看，國產(chǎn)化數(shù)據(jù)庫通常都具有分布式的成長基因。

但是，在行業(yè)中也在短時間內(nèi)產(chǎn)生了大量的數(shù)據(jù)庫定制化產(chǎn)品，這些都是在核心組件和底層服務之外的偏個性化定制，使得用戶在林林總總的國產(chǎn)化數(shù)據(jù)庫中容易迷茫，另外國產(chǎn)數(shù)據(jù)庫如果僅僅是為了對標和其他商業(yè)數(shù)據(jù)庫的兼容度，個人感覺會受到過多束縛和限制，因為過多的泛應用化會讓數(shù)據(jù)庫技術(shù)的基礎沉淀不夠扎實，而過度迎合用戶使用體驗而在設計理念上妥協(xié)，會讓數(shù)據(jù)庫技術(shù)難以聚焦，限制更大的發(fā)揮潛力。

2）做得更少 vs 做得更多

在數(shù)據(jù)庫分布式架構(gòu)的改造中，做得更少對我來說是顛覆認知的收獲。我們早期做分布式架構(gòu)性能提升時希望做得更多，支撐更高的OPS，提供更高更強的性能，但我們做架構(gòu)改造的過程中發(fā)現(xiàn)有些情況卻恰恰相反，基于業(yè)務的視角去做一些架構(gòu)優(yōu)化反而能夠取得更好的效果，最后發(fā)現(xiàn)原來支撐了幾十萬的OPS,經(jīng)過優(yōu)化幾萬OPS就足夠了，從這個層面來說，數(shù)據(jù)庫分布式架構(gòu)的發(fā)展空間很大。

3）分布式共享存儲

云原生數(shù)據(jù)庫有共享存儲的影子，例如Aurora是基于讀寫分離模式，它之所以在分布式方向?qū)崿F(xiàn)彎道超車，是因為其核心部分是分布式共享存儲技術(shù)，在云原生數(shù)據(jù)庫中，原來看起來“土味的”共享存儲模式其實玩出了新的花樣。

4）HTAP需要理性

原本單一的OLTP和OLAP業(yè)務，在開發(fā)和管理中存在諸多不便，而HTAP在一定程度上能夠有效的結(jié)合兩者的優(yōu)勢，從而提供更為統(tǒng)一高效的數(shù)據(jù)服務，我想這應該是近些年來HTAP大火的原因，在這個基礎上我建議要警示數(shù)據(jù)膨脹的問題，ALL IN的問題帶來的隱患會隨著時間的增長而變得更加棘手。

所以對于HTAP方案，我并不十分認可All In One 的模式，或者說存在一些擔心，我們需要理性看待HTAP方案。

2.基于機器學習的數(shù)據(jù)庫監(jiān)控異常預測研究

近些年來AIOps還是很火的，數(shù)據(jù)庫也會搭上這輛便車。我前段時間進行了一些機器學習相關的研究，將成百上千的服務器通過機器學習的方式做相關監(jiān)控數(shù)據(jù)的預測，如上圖我們基于回歸模型和時序模型進行了預測，整體上基本實現(xiàn)了對某些指標的周期性預測。

那么問題來了，機器學習異常預測與分布式架構(gòu)有何關系呢？根據(jù)我的理解，原本數(shù)據(jù)庫的負載預測是基于單機模式，而我們在考量集群分布式架構(gòu)時，需要從更全局的集群角度看待，定位短板，和單機模式是有很大的差別。從這個層面來說，如果我們有一些分布式體系的異常預測模型，我們就可以在此基礎上做更多工作。

?楊建榮?

競技世界 數(shù)據(jù)庫專家

dbaplus社群聯(lián)合發(fā)起人，騰訊云TVP，Oracle ACE，《Oracle DBA工作筆記》和《MySQL DBA工作筆記》作者；

現(xiàn)就職于競技世界，擅長數(shù)據(jù)管理、數(shù)據(jù)遷移、性能優(yōu)化，目前專注于開源技術(shù)、運維自動化和性能優(yōu)化，堅持寫技術(shù)博客，已堅持2400多天。?