無感平滑遷移：海量高并發數據庫如何進行國產化改造？

　　作者簡介：鄭鴻健，中國移動通信集團信息技術公司政企業務支撐中心，數據庫專家，主要負責政企業務支撐中心數據層高性能、高可靠架構的設計、優化以及國產化的落地。

　　歷任騰訊DBA、樂信數據SRE負責人、業務SRE中心總監，有豐富的數據庫、大數據、中間件及業務運維經驗，主導過多種業務場景下高性能、高可用架構設計、業務全鏈路容災體系建設、SRE體系落地等大型項目。

　　今天分享的主題是“無感平滑遷移：海量高并發數據庫國產化改造及應用”。

　　首先，講一下數據庫國產化的大背景。

　　國家戰略方面的，隨著外部形勢的日益復雜，核心技術急需實現自主可控、安全可靠、高效開放；另一個要求是業務方面的，當業務高速發展后各種問題會接踵而至，單機數據庫達到瓶頸，業務拆分、垂直拆分、水平拆分等，都需要花費大量的研發時間。

　　首先和大家分享一下目前主流的數據庫架構。目前業內主流的數據庫架構大體分為三類：Shared-Everything、Shared-Nothing，Shared-Storage。

　　Shared-Everything

　　這一種架構可能大家都比較熟悉，是很經典的一個架構，主機上的所有進程共享CPU、內存、IO，任意一個硬件達到了瓶頸，也就意味著數據庫達到了瓶頸。Shared-Nothing

　　這里可以再細分出兩個架構，一種是基于 Proxy 的架構，這個架構由傳統的單機數據庫演變而來，當我們單機數據庫達到瓶頸以后，我們再往上加一層 Proxy，通過 Proxy 把我們的數據打散到不同的節點上，以此來解決數據擴展性問題；另一種 Shared-Nothing 架構，是目前在國內比較火的像 TiDB、OB 這樣的數據庫。

　　Shared-Storage

　　這種架構在業內比較有名的是的 Aurora，還有目前在國內也比較火的阿里的 PolarDB。首先，先詳細介紹一下 Shared-Everything 架構。這個架構可能大家都比較熟悉，它是一種傳統的單機數據庫架構，當我們的數據庫達到瓶頸以后，我們通常會采用各種各樣的方式把我們的數據打散到各個 set 里面去，以此來解決數據庫當地容量上限的問題。

　　有很多公司會通過這種方式來實現，把應用層、接入層、網關層都根據同樣的分片邏輯，把數據整合到一個 set 里面，從而實現數據在 set 里面的閉環。通過這樣的一套架構能做非常多有意思的事情。比如一些全鏈路在線的壓測，因為數據已經在一個 set 里面不閉環了，如果我在一個測試 set 里面做數據壓測，它不會污染到線上真實的數據，還可以做一些向線上的灰度引流、灰度發版等。Shared-Storage 架構中，目前在國外做得特別好的是 AWS 的Aurora，在國內做得比較好的是阿里的 PolarDB。因為它對數據庫研發投入非常高，同時需要依托底層一個非常強大的底座，所以一開始這些數據庫推出來之后，像 Aurora 至今都是只支持在云上部署。Shared-Nothing 架構，大家已經比較熟悉了，我們傳統的數據庫達到瓶頸演進后，單機解決不了性能、容量問題，于是就加一層Proxy，在 Proxy 上做各種各樣的路由，這樣的架構慢慢地演進到現在。國內有非常多基于這樣的架構去演化出來的數據庫，目前移動用的比較多的數據庫都是類似的架構。

　　這套架構主要可以分成三類組件：GTM 組件負責全局的協調，主要用來取協調分布式事務的管理，包括全局 ID 的生成活躍，GTE ID 的快照等等。Proxy/計算節點。一開始 Proxy 這一層可能只是簡單做數據的路由，但是后面隨著整個數據庫架構的演進，Proxy 這一層也承擔起一定的計算能力，包括分布式事務的優化、計算的下推，還有一些 SQL 解析等。底層的存儲節點，大多數目前都是基于開源的數據庫去做二次開發，目前比較常見的就是 MySQL 和 PostgreSQL。它的架構的好處就是比較成熟穩定。但是它的壞處就是整個改造的過程非常痛苦，因為我們在整個改造的過程中，第一步需要去選取分片鍵，然后根據我們的分片鍵把數據打散到不同的節點上去，這一步就足以讓業務抓狂。Shared-Nothing 的另外一種架構是剛剛提到的OB、TiDB。這里以TiDB為例， TiDB是基于谷歌的論文去開發的一套分布式數據庫。這個數據庫它分成三層，調度層PD，計算節點TiDB，然后是底層的存儲節點TiKV。但是TiDB它在使用的過程中不需要顯式地去指定分片鍵，它數據的分片拆分都是與依托于底下的數據庫自動去完成的，所以采用這樣的架構的話，改造成本可能會相對于低一些。小結，以上提到的四種數據庫架構，可以看到它們在擴展性層面，除了第一種沒辦法做到動態橫向擴容，后面的三種其實只要改造完了，基本上都能做到數據層的橫向擴容。在一致性方面，第一種和最后一種基本上都是依托于半同步去保證各個節點之間的一致性。中間這兩類數據庫一般都是用了分布式一致性協議，目前用的比較多的是 Paxio協議，還有的 Raft 協議。

　　下面，跟大家分享我們在數據庫國產化挑戰與探索上的一些實踐經驗。業務邏輯和數據層的深度綁定是我們整個數據庫改造過程中最頭疼的一個點，于是出現了各種各樣的數據庫遷移方案，總結下來無非是以下七步：選型、測試、同步、改造、灰度、上線、保障。

　　首先是選型階段，我們關注更多的是穩定性、效率、成本以及生態。選型階段是一個很重要的階段，因為如果選型選得好，可以極大地降低我們在后面數據庫國產化改造的過程中的成本。但是很多時候我們在做數據庫改造的過程中，選型階段除了考慮技術的因素外，還有很多非技術的因素需要去考慮，所以最后我們只能在有限的范圍內選出最優解。不能指望在選型階段就把整個數據庫國產化改造中的所有問題都一并解決掉。緊接著是測試階段，我們拿到一塊數據庫之后，可能會做各種各樣的測試，比如基礎功能測試、可用性測試、可維護性測試，還有一些基礎的性能測試等。但是哪怕我們做了這樣的測試以后，也不能保證這套數據庫可以滿足業務的需求，更多的是我們在做完這樣的一些測試之后，淘汰一些不滿足我們需求的一些數據庫。如果我們想篩選出哪些數據庫能基本符合我們的要求，可能還要結合一些線上的流量錄制以及流量回放的一些東西。數據同步這里可以稍微展開講一下，這一塊主要是分為全量數據同步和增量數據同步，我強烈建議大家在做這種大數據量的遷移時候，不要上來就去研究全備要用物理備份還是邏輯備份，哪個工具強，哪個工具差。第一步更多的是需要去分析一下自己的業務，分析自己的庫表、業務邏輯是怎樣的、數據到底是怎么分布的，哪些是歷史數據、熱數據、冷數據，哪些數據是可以現在立馬要遷移的、哪些數據是可以放到放到后面慢慢遷的……在做完這樣的數據分析之后，再來做全量和增量的數據遷移，往往可以做到事半功倍。

　　在增量同步這一塊，我們內部也開發了類似的一個增量數據的同步工具。它是去監聽了數據庫變化的日志，然后把這些變化通過通過中間件的方式寫到像 Kafka 這樣的消息中間件，然后有需求的業務再去定從我們的中間件里面去訂閱。通過這樣的一個工具能做非常多有意思的事情。像我們剛剛提到的數據遷移，那么可以通過這些工具的來做異構數據的同步，還可以做一些像數據庫當緩存之間的同步，或者是說 OLTP 向 OlAP之間的同步等等。通過這個工具能解決非常多的業務的痛點。業務改造這一塊也是非常痛苦的一個點。我們改造的關鍵點主要分兩塊，一塊是應用，應用這一塊更多的是關注一些驅動程序、語法兼容、數據對象等等、API、 SQL 等等的一些東西。數據庫這一層更多的是關注一些像數據分片、冷熱分離、輕重隔離、SQL優化、讀寫分離等等這一些的東西。

　　這個適配改造我們目前改造的積累下來的需要關注的點，已經到大幾十項了，所以這里我也沒有詳細地列出來，只是稍微地把它匯總了一下。我剛剛在前面幾頁提到的就是數據庫國產化改造中最大的一個痛點就是業務邏輯和數據庫的深度耦合，把這個問題給解決掉。所以我們在改造的過程中逐步地把那個 DB 給弱化成一個簡單的存儲，然后明確應用和數據之間的一個邊界，然后再去做各種各樣的適配改造。通過這一系列操作把數據庫國產化的這件事情，也作為我們整一個架構的梳理和優化。切換方案這里可以稍微簡單地提一下。我們的切換方案主要有兩種，目前這兩種方案都有在用：第一種是基于數據層的中間件的方案，這種方案相對而言會比較簡單一些，另一種方案是基于應用的雙寫方案，這種方案可能相對比較復雜，但是這種穩定性和安全性要求會對穩定性和要求的保障會更好一些。

　　我先簡單介紹一下基于數據層的切換，一開始我們的應用可能都是直接連到我們的 DB，中間有一些 VIP 的東西，我直接給它省略掉。開始我們給它加了一層中間件，從第一步到第二步之間，因為中間件指向的也是我們的這個DB，所以研發可以慢慢地去改。這個改造的過程耗費十天半個月都沒有關系，這它對業務是不會有任何的影響的。當我們把所有的流量都切到中間件以后，我們在數據庫這一層去抓包，確保我們的那個請求全部都是通過中間件來的。等到應用全部改造完成了之后，我們把數據全量地同步到新的數據庫去，然后可以把我們的讀流量放到新數據庫上。因為應用已經通過我們的中間件過來的，所以我們在中間件上做讀寫分離，對到應用來說是完全透明的。我們把我們的讀流量打到我們的新的數據庫上來，以此去驗證新的數據庫是否能夠滿足業務的要求，當然通過這樣的架構其實是沒有辦法做到寫流量的驗證的。在切換過程，對業務的影響就只是那么零點幾秒的閃斷，替換完之后我們再把數據往回同步，如果真的出現了問題，我們還有一個退路可以往回退。第二種方案是業務雙寫的方案，這一個方案可能會相對于上一個方案來說更穩妥，但是也更復雜一些。首先我們準備一套新的數據庫，先做全量同步，再做增量同步，保證兩邊的數據是追平的。然后我們再找一個時間窗口，當然前提是我們就上一步已經執行完了，就是我們應用的適配卡照已經執行完了，然后通過我們的應用去開啟我們的雙寫，然后保證兩邊的數據都寫一致，這個時候我再去把增量同步給停掉，然后底下再開啟一個腳本，異步地去對比兩邊的數據，保證兩邊的數據是一致的。對賬的過程中如果發現不一致的東西，就打日志出來，然后人工分析，當保證兩邊是一致以后，就可以開始去分析一下。因為這個時候我們的業務是以老庫為主，新庫為輔，這個時候新庫它是既有讀又有寫的，我們可以從業務上去觀察到新庫的各種解指標，包括耗時、錯誤率等等，如果新庫是有問題的，在這個階段基本上都能發現，而且對業務是毫無影響的。足夠穩定之后我們再進行雙寫扭轉，把新庫為主，舊庫為輔，然后這樣再持續穩運行一段時間。當我們發現用新的庫足夠穩定之后，再把雙寫給下掉。做完了上面那一步，就到了上線后的保障階段。這里主要分兩塊來做，一塊是可觀致性，另外一塊是可控性、可觀測性，保證了我們在出現故障的時候能夠快速地發現，快速地定位，可控性保證了我們在出現故障之后可以快速地響應以及快速地恢復。可觀測性這一塊loging、 tracing、metric 這三個大家都經常聽到，就不細說了。在我們內部其實也針對剛剛的那幾個點做了對應的建設，包括底層資源的監控，業務層的監控、日志采集平臺、調用鏈路分析平臺。在可恢復這一塊，其實我們通過過往的故障可以發現就是故障的時候，故障恢復的時間大多數并不是花在就是故障的修復的那一刻，時間更多的是花在信息的溝通人員的分工上，就從故障的出現到協調到對應的人，然后再把信對應的信息同步，再到決策要做怎么樣的操作。我們對時間分布做了一整套應急響應體系。我們把故障分為輕微問題、中等問題、還有重大問題，以此打造了一個預案管理平臺，平時運維可能更多的只需要在上面建立我們的原子化的一些預案能力。舉個例子，SQL 的kill，數據庫的主從切換等等這樣的一些原子能力。然后我們把這樣各種各樣的非常成熟的原子能力整合到那個預案平臺，然后在預案平臺上做各種各樣的故障預案的編排，結合AI，在出現故障的時候，自動地去推薦預案再輔以人為的判斷。通過把這樣的一些智能化的預案推送到我們的移動端，那么人可能需要做的事情只是在移動端上點一點，那么它就可以自動化地去執行我們的預案。像遇到一些在改造過程中遇到的比較簡單的問題，就執行降級操作，降級包括業務降級、請求降級、底層的資源降級，技術層面可能我們還會做一些架構的降級。

　　最后我們還有我們的兜底方案，前面提到的切換方案中，不管是我們的雙寫方案，還是我們基于數據庫中間件切換的方案，都能保證我們在秒級內做那個數據庫的回退。像雙寫方案，因為我們把那個雙寫作為做一個配置項存的一個開關里面，我們做回退只需要修改一下那個數據庫切換的一個開關，像中間件的方案，我們只需要切換一下后端的指向。最后，對我們在數據庫國產化改造的經驗做個小結。第一是合適就好。其實大多數時候，集中式的數據庫仍然是當前的一個最優解，如果你的數據可能只有幾百G，甚至可能就兩三個T，那么集中式數據庫可能仍是當前最好的選擇，因為你不需要去承擔數據分片，還有這種各種的各樣跨節點同步的耗時這樣一系列的問題。第二是沒有銀彈，但不要指望用一種數據庫去解決所有的問題。過去我們在用 Oracle 的時候，然后 Oracle 承擔了太多不應該他承擔的東西了。現在我們在做的數據庫改造的過程中，慢慢的我們也在解決這樣的一個問題，像該扛量的我們用 Redis，像即席查詢，那么用 clickhouse 這樣的一些數據庫去扛，然后做一些大的一些報表分析的這樣的一些東西。可能我們會通過我們的同步工具同步到我們的大數據平臺，通過大數據平臺去做這樣的一些分析。第三是拆掉運維里的墻，打破技術和業務的壁壘。技術只有服務于業務、和業務結合，而運維只有跳出自己的框框，站到全局的視角去看待問題，那么才能真正做到的事半功倍，才能稱之為真正的技術運營。以上是我這次的分享，非常感謝大家。還不過癮？還想了解更多國產數據庫改造的精彩話題？6月29-6月30，DevOps 國際峰會（DOIS） 2023 · 北京站，BizDevOps、精益/敏捷、信創、SRE 穩定性、技術運營，關于運維、DevOps 的精彩內容，都在這里！

　　長按圖片二維碼，訪問大會官網！近期好文：運維人如何少背鍋？這 7 種常見監控工具，你是否全用過？投稿郵箱：jiachen@greatops.net，或添加聯系人微信：greatops1118。點個“在看”，一年不宕機