解密小程式雲開發資料庫_ZenDei技術網路在線

小程式雲開發（Tencent CloudBase）擁有易接入、高性能、高可用等特性，其中雲資料庫作為核心組件之一，可以有效降低運維成本，幫助開發者實現業務快速上線與迭代。本文將簡要介紹如何通過 TEG 雲架構平臺部的高性能分散式 NoSQL 資料庫，為近百萬小程式雲開發用戶提供完整的原生雲端資料庫能... ...

導語
一、背景
二、競品分析
三、需求和挑戰
四、架構和方案
五、總結和展望

導語

小程式雲開發（Tencent CloudBase）擁有易接入、高性能、高可用等特性，其中雲資料庫作為核心組件之一，可以有效降低運維成本，幫助開發者實現業務快速上線與迭代。本文將簡要介紹如何通過 TEG 雲架構平臺部的高性能分散式 NoSQL 資料庫，為近百萬小程式雲開發用戶提供完整的原生雲端資料庫能力支持。

一、背景

要理解小程式雲開發，不妨將之從字面上拆解為小程式和雲開發兩個部分。本節部分我們也將嘗試從這兩個方面帶大家一起簡要梳理下相關的背景知識。

1.1 雲開發

從軟體工程的角度來看，軟體開發經歷瞭如下三個階段：傳統開發-->敏捷迭代-->serverless。傳統的開發模式和敏捷開發模式除了需要開發者編寫核心的業務邏輯外，都不可避免地需要對後端的基礎設施進行管控和優化。比如，一個應用的邏輯可以很簡單，可一旦涉及到應用的發佈部署，就需要開發者花費大量精力進行伺服器、資料庫、網路等基礎設施的申請和搭建，還要考慮這些後端基礎設施的穩定性、可用性和監控指標。這一切耗時耗力又與產品的核心功能無關，對於需要快速開發和試錯的產品，傳統的模式開發速度慢、部署和運維成本較高。

開發趨勢

隨著 serverless 概念的火熱，越來越多的開發開始轉向 serverless 架構發展。“serverless”並不是指後端沒有伺服器，而是將後端伺服器及相關運維操作變得對上層應用開發者不可見和透明。用戶無需關心後端的基礎設施，直接通過雲 API 一鍵接入雲函數、雲資料庫和雲存儲來獲取算力、資料庫、存儲等基礎的後端能力。這種隨用隨取的開發模式，不但可以讓開發者能更專註於自身的業務邏輯，還具有低成本、開發速度快以及免運維等諸多優勢。

1.2 小程式

小程式應該不用過多介紹，相信現在每一個使用智能手機的人都已經在日常生活中或多或少地使用到了各種各樣的小程式：點餐、外賣、打車、購物等等。為了嚴謹起見，還是按張小龍朋友圈的介紹給出一個簡單的定義：小程式是一種不需要下載安裝即可使用的應用，它實現了應用“觸手可及”的夢想，用戶掃一掃或者搜一下即可打開應用。也體現了“用完即走”的理念，用戶不用關心是否安裝太多應用的問題。應用將無處不在，隨時可用，但又無需安裝卸載。

自 2017 年 1 月 9 日微信發佈小程式以來（十年前正好是喬布斯發佈首款 iphone，有媒體解讀，這是張小龍的致敬以及野心的表現），小程式在這幾年的發展中已經形成了完整的生態系統，用戶數和小程式數量也有了非常顯著的進步和發展，其他主流互聯網企業也開始紛紛佈局小程式平臺，如支付寶小程式、百度小程式、抖音小程式、今日頭條小程式等等。據微信提供的數據，在 2019 年微信小程式全球交易額達到了 8000 多億，同比增長 160%，日活躍用戶超過 3 億，截至目前，微信上線的小程式超過 100 萬個，擁有超過 150 萬開發者、8200 多個第三方平臺，小程式在電商，零售行業同比去年有爆髮式增長。到 2020 年微信公開課 PRO（同樣是 1 月 9 日），全網的小程式數量已經超過 450 萬。可以說，我們已經進入了一個“全民小程式”的時代。

受到今年新冠疫情的影響，由於小程式開發相較於 app 開發更加輕量和低門檻，同時也能觸達到更多的人群，各種健康碼、申報、信息核實等大部分都採用小程式的形式上線。類似的，線下實體店客流受阻，越來越多的商家和店鋪將自己的銷售轉移到線上來保證疫情期間的現金流，小程式同樣也是這一場景的不二選擇。

附近的小程式

越來越多樣化和越來越火爆的小程式也就意味著會有越來越多的小程式開發者入場，如何服務好這些基於小程式生態的開發者們就成為了一件必須要解決的事情。於是小程式雲開發問世，可以說小程式需求 + serverless 理念 = 小程式雲開發。小程式雲開發以微信作為小程式前端運行的依托，同時又通過接入雲函數、雲資料庫和雲存儲等雲服務，來達到對後端基礎設施的“開箱即用”。這些特性可以在很大程度上解放小程式開發者的生產力，大大降低開發的成本和難度。

二、競品分析

事實上，互聯網巨頭們很早就看上了這一塊市場。以 google 為例，自從 2014 年 10 月收購 filebase，google 將自身已有的雲端服務與工具一併整合進 filebase，使之成為專門為 app 開發者提供一站式的BaaS(Backend as a service，後端即服務)產品，涵蓋了開發、質量、分析與發展著四個主要的模塊，提供了認證、資料庫、存儲、雲函數、機器學習等服務以及一系列性能和數據分析工具。

filebase-cloud filestore

如果重點看它的資料庫產品的話，filebase 提供了兩個選項：Cloud Filestore和實時資料庫。雖然他們都是 NoSQL 資料庫,但官方更推薦使用前者，因為它可以提供高性能、良好的可擴展性以及其他更多的高級功能。參考官網的介紹，cloud filestore的主要功能如下：

靈活性——支持靈活的分層數據結構，文檔型；
富有表現力的查詢——支持過濾/排序等功能，自動家索引，查詢性能與結果集的大小（而不是整個數據集的大小）成比例；
實時更新——支持實時數據同步；
離線支持——緩存離線狀態的寫入、讀取、查詢，待恢覆在線時，同步本地更改；
可擴展涉及——基礎架構支持自動多區域數據複製，強大一致性保證、原子批量操作以及事務支持；

另外，filestore是支持按量收費的，可支持按數據存儲量、流量以及文檔的讀(query)，寫(insert/update)，刪除(delete)操作次數來收費。並且對外提供了多個客戶端和開發語言版本的 sdk。

其他為人熟知的 BaaS 產品還有Parse，最早被 Facebook 收編，但沒多久就停止了運行。目前以開源產品的形態運行在 github 上，需要開發者自行下載源碼並部署和維護，已經失去了 BaaS 的意義。

類似的，國內也有不少提供一站式後端服務（BaaS）的產品，包括：LeanCloud，Bmob，willddog野狗雲服務、知曉雲等。騰訊雲推出的小程式雲開發（Tencent CloudBase，TCB）也是屬於同一賽道的產品，即採用 serverless 架構的一體化後端雲服務。

三、需求和挑戰

那麼，小程式雲開發對於資料庫提出了哪些基本需求？又有哪些挑戰呢？

我們認為應該主要有以下五個方面的需求：

安全性：對於資料庫而言，數據安全是第一位的；
易用性：與小程式的特征類似，“開箱即用，用完即走”，簡單上手，免運維；
低成本：按量收費，精細化成本控制；
高性能：Nosql，支持高併發讀寫；
靈活性：無固定的資料庫表模式(no-schema)，支持彈性伸縮；

顯而易見，最大的挑戰就是如何利用已有的技術來同時滿足這五個需求並且能在它們其中達成良好的 trade-off。畢竟大多數情況下我們並不是提出了一種新的架構，而是在多種方案和組件之間進行取捨，正如分散式系統里大名鼎鼎的 CAP 理論，一致性/可用性/分區容忍性你只能選擇其中的兩個。

下麵將首先介紹我們所使用的架構，然後闡述在這樣的一個架構下有什麼挑戰以及我們所採取的相應對的方案。（並不一定是最優解，讀者可以帶著自己的思考來看待，我們是如何做取捨的）

四、架構和方案

圍繞前面提到的 5 個主要需求，我們從架構設計等方面對雲開發資料庫進行了相應的改造及優化，其架構圖如下：

雲資料庫架構v2

最上面是小程式的接入客戶端，中間部分是接入層，底層是資料庫的存儲層。當然，還有周邊的管控、告警、備份、元數據管理等模塊。

開發者通過雲開發提供的 SDK，可以在微信小程式和 qq 小程式中一鍵獲取雲資料庫的登錄態，然後將數據讀寫請求發送給接入層。接入層收到用戶的讀寫請求後，由 keeper 和 agent 這兩個無狀態的模塊對接入的讀寫請求進行相關處理。其中 keeper 主要負責請求的鑒權、認證緩存，以及讀寫請求數的統計，是雲資料庫許可權校驗，負載均衡和計費功能實現的核心模塊。agent 模塊主要有以下幾個功能：1）維護接入層到底層資料庫實例的連接池，通過復用已建立的連接來減少請求鑒權和連接創建的耗時；2）統計請求的併發數，對讀寫請求的 QPS 進行平滑處理，避免短時間的毛刺影響資料庫性能和可用性；3）在熱遷移切換資料庫實例時，將請求掛起，切換後再將請求恢復，來實現熱遷移過程對用戶的全程無感知。

最後，讀寫請求通過了接入層，再接下來會到達存儲層進行資料庫實例的讀寫。鑒於本文的關註點主要集中在資料庫層面，接下來將嘗試從四個方面對其進行描述。為了避免本文篇幅過長，部分內容並不會給出細節實現，只是淺析，感興趣的讀者可以留言或者找我們討論。

4.1 訪問控制

許可權控制

首先，用戶只能訪問自己的資料庫，無法訪問其他用戶的資料庫，不同用戶的資料庫之間是相互隔離的，所有連接也必須認證。預設情況下，用戶是擁有資料庫的讀寫許可權的，也支持在資料庫上建立多個不同許可權的賬戶（比如一個只讀的賬戶）。在小程式雲開發的場景下，利用微信全鏈路免鑒權的特性，用戶完全不需要太關心認證相關的問題。

訪問控制

連接數控制

其次是連接數控制方面，我們會分兩層進行控制：1）在接入層進行客戶端連接控制，根據初始化時實例類型（免費/付費等）進行不同的初始化限制，如果超過限制則提示相應的用戶；2）接入層到存儲層也有相應的連接數控制，會池化到後端資料庫所有主從節點的鏈接，避免因過多鏈接而導致的資料庫性能問題。

流量&QPS 控制

最後是機器層面的出入流量控制以及資源使用限制，原理與連接數控制類似，用戶所有的請求都會經過接入層，因此可以在接入層控制 QPS 進而實現後續的按量付費功能。QPS 超過閾值後可以提示用戶或者在接入層做排隊處理。

這裡有人可能會質疑了，雲開發資料庫不是彈性伸縮的嘛？為何還有 qps 的限制呢？不應該是我 qps 越來越高，後端的資料庫資源也跟著不斷擴容嘛？

答：是的，預設的配置下會有一定彈性擴展空間，但是會有一個限制。當然，這裡限制具體多少跟產品策略有關。

4.2 數據安全

數據安全是資料庫最重要的特性之一，畢竟一個存在數據丟失風險的資料庫並不能夠在激烈的市場競爭中存活下來。那麼雲資料庫是如何保證數據安全的呢？

數據冗餘

要解決數據不丟失的問題，首先就是要避免資料庫的單點問題，也就是要有數據冗餘。一般而言，工業界認為比較安全的備份數為三份。因此，雲資料庫預設是三副本分散式存儲，即一份數據會存儲三份放在不同的機器上，同時機器也要分佈在不同的機房中。節點區分主從狀態，主節點可以接受讀寫請求，從節點只能接受讀請求。副本集內的存儲節點之間採用 raft-like 的副本集協議來實現三副本數據的最終一致性。

高可用

當機器發生故障時副本集內的數據節點會自動切換（FailOver），從節點變為主節點繼續提供服務，從而把對業務的影響降到最低。

數據安全

備份回檔

雲資料庫的備份對用戶完全透明，後臺根據資料庫的狀態自動選擇性地進行全量以及增量備份。詳細來說就是用戶的寫入越快，後臺的備份頻率也會相應增高，這樣做的目的是為了減少回檔時需要回放的數據，提升回檔性能。

支持 7 天內任意時間回檔，可以選擇只回檔單個表，進一步減少回檔所需的時間。

另外，如果節點故障需要新加一個節點到副本集中，可選擇從備份文件中進行恢復，從而減少對源集群的侵入性。

基於冷備恢復

多可用區容災

雲資料庫預設跨三機房（AZ, Availability Zone）部署，也對用戶透明，任意一個機房掛掉也不會對服務產生任何影響；同時也可以支持跨多地域，兩地三中心等模式。比如北京、上海、深圳各有一個節點，業務採取就近接入的方式來降低業務訪問雲資料庫的時延。

兩地三中心

另外，所有到資料庫的連接必須認證以及所有數據均加密壓縮存儲，這兩點保證了數據的鏈路安全以及存儲安全。

4.3 彈性伸縮

彈性伸縮

很多時候，業務的訪問模式會呈現很明顯的周期性或者不均勻的特征，比如外賣類業務的高峰期出現在用餐時段，其他時段訪問較少；游戲類業務的高峰期出現在晚上或周末，上班時間較少；還有一些電商類業務的高峰期出現在特殊時間點（雙十一，618 等）。

周期性規律

如果按照傳統的資料庫運維模式，需要提前預估量級，然後運維執行擴容，等活動結束後再縮容回來（不然成本是個問題）。那麼在小程式的場景，既然要做到用戶對後端服務無感知，那麼資源的擴縮容也應當不被感受到。

基於這個出發點，我們實現了雲資料庫的彈性伸縮。依賴管控系統的負載監控模塊，我們可以根據資料庫的實時負載情況動態地調整資料庫的資源，並且自動調整敏感度，從而來有效地應對資料庫負載突增的情況，在負載低的時候也可以將資源釋放提供給其他更需要的實例。其次，為了避免單個大查詢引起的頻繁調整，我們設置了滑動視窗和“去毛刺”機制，保證了彈性伸縮儘可能平滑地進行。

資料庫熱遷移

當實例狀態發生變更（比如免費-->付費，冷-->熱）的時候，可能會需要進行數據遷移，比如從性能較差的機器遷移到性能較好的機器。有了接入層的配合，我們實現了用戶無感知的資料庫熱遷移，可以在不停服的情況下將用戶的數據從一個資料庫無損遷移到另一個資料庫。

熱遷移

整體來看，資料庫熱遷移主要分為三個部分：

數據同步（Data Sync）
割接（Cutover）
狀態變更（Status Change）

第一階段，高性能數據同步的能力完全由底層資料庫提供支持，需要先同步全量數據，再同步全量階段新產生的操作記錄（operation log），然後不斷迴圈這個過程，直到源資料庫和目標資料庫的差距非常小，實現方式非常類似於一個副本集內的主從同步。在這一階段中，源資料庫是可讀可寫的。第二階段，也就是當兩邊資料庫的差距非常小時、進行熱遷移的割接過程，將源資料庫變為不可讀不可寫，接入層臨時 hold 住用戶的請求，並不返回錯誤；數據同步這邊，在目標資料庫補齊了所有的操作記錄並且校驗兩邊數據完全一致之後，進行割接，其中包括用戶的拷貝及一系列元數據變更。第三階段，割接完成後，將目標集群變為可用狀態，之前由接入層 block 住的請求可以釋放並繼續執行。由於割接的過程非常迅速（秒級），這些請求並不會返回類似超時之類的失敗。當然這裡只考慮了最一般的情況，當某個環節出現異常時需要考慮到相應部分的回滾和應對邏輯，涉及狀態機的變化，這相對比較複雜，在此不多贅述。

我們認為數據熱遷移要做到用戶完全無感知，主要有以下幾個難點：

強一致性感知集群變更；
高性能割接；
割接狀態持久化以及超時控制；
對於用戶請求的臨時處理；

在我們的架構中，底層資料庫提供了高性能數據同步的基本能力；由於有接入層 agent 的存在，可以很方便地實現 agent 之間的強一致性感知以及對於用戶請求的臨時處理（比如 block 住）；引入了分散式 KV 存儲系統 etcd 來實現割接狀態的持久化和超時控制，如下圖所示：

熱遷移狀態轉移圖

經過線上環境測試，當資料庫梳理維持在 3k 左右的 QPS（100% write）時，熱遷移成功，從前端看用戶請求在遷移過程中成功率一直維持 100%，也就是做到了熱遷移對用戶的完全透明。

微信讀書每日一答

我們不妨舉個例子來說明資料庫熱遷移的應用。微信讀書業務就使用了小程式雲開發，微信讀書小程式中的“每日一答”模塊完全使用雲資料庫作為底層支撐。“問答 PK”，“每日一答”以及不同類別的題目都分別存儲存在不同的表中，峰值(夜間 0 點左右)QPS 接近 10k，自業務上線以來一直平穩運行。有一段時間我們發現共用資源池內的一個用戶的訪問量有明顯增大的趨勢，彈性伸縮後仍不能完全滿足其需求，為避免其對微信讀書實例產生影響，決定將其整個資料庫實例通過熱遷移的方式移動到我們的熱資源池中。由於數據量並不大（10G），在短短幾分鐘之內就完成了數據的遷移和割接（秒級）工作，整個過程對用戶完全透明，當然也沒有對微信讀書實例產生任何影響。

4.4 智能 DBA

智能 DBA 是一個非常大的話題，涉及各個方面，分層級來看主要包含以下三層：應用層，處理層和採集層。採集層負責從多個數據源採集需要的數據和指標；處理層對採集到的數據進行預處理和分析並產生相應的決策和建議；應用層則會根據不同的應用場景進行不同的處理，比如自動化運維模塊需要進行異常處理，而巡檢模塊只需要進行巡檢和告警即可。

智能DBA

自動化運維

為了進一步減少後臺側的運維操作，我們實現了自動化運維平臺。通過對運行時的存儲節點狀態的監控，對每個節點進行探活及故障判斷，然後在決策中心根據故障的統計結果進行相應的自動化運維操作（比如磁碟只讀了則強制切主）同時也會告警給運維人員，確保自動化運維結果正確。

自動化運維平臺

對於一部分自動化運維沒辦法覆蓋的問題，我們有各個層面和維度（機器、實例、節點等）全套的秒級監控，各項指標共計69+項，後端可以實時感知到資料庫的狀態；發現問題儘早處理。

索引優化

索引是資料庫中非常重要的概念，用於加速資料庫的查找。在小程式的場景下，我們希望將用戶對於後端的資料庫的認知降低到越少越好。於是實現了一系列查詢優化的功能，比如自動建索引。當我們的接入層和存儲層發現用戶有很多查詢到後端都是全表掃描時，就會根據用戶的 query 具體欄位進行對應索引的添加工作。等到索引建立完成，用戶就可以直接享受優化後的查詢結果。重要的是，這一過程用戶同樣也是無感知的。

我們認為自動建索引要做到用戶完全無感知需要考慮以下幾個主要問題：

同步 VS.非同步？建索引過程應該是非同步的，否則將會阻塞用戶的正常請求。
如何控制建索引的風險？主要分為兩個方向：1）首先需要控制自動建索引的頻率。建索引是 cpu 消耗型任務，如果資料庫一直處於建索引的過程中很明顯是不可接受的；2）其次需要控制自動建索引的數量，使之在一個相對合理的範圍。對於一般的表不會有問題，但是如果資料庫中的某個表包含多個欄位，且用戶會根據這些欄位進行不同的查詢，那麼不加限制的索引會導致索引數量特別多，嚴重影響用戶的更新效率（因為更新時除了會更新數據外還會更新相應的索引）。
索引該如何實現動態更新？用戶的查詢並不是一成不變的，伴隨的業務的發展或者變換，對於同一個表的查詢很有可能也會發生變化。那麼之前自動建立的索引也需要自動刪除，否則長期下去將成為資料庫的負擔和瓶頸。需要根據用戶查詢條件的變化來動態更新已有的索引。這裡關於索引的最左匹配原則也值得考慮進來。
如何做到對用戶透明？不僅僅是建索引時不影響用戶的正常請求，而且需要讓用戶能直接感受到查詢走索引的速度。當表內數據量比較大時，一次索引的變更操作（比如複合索引欄位順序的變化）可能會導致用戶的同樣一條查詢存在顯著的耗時差距，除了向用戶解釋外，我們也可以考慮將索引的變更做得更平滑一些，並提供一系列的查詢優化建議。這樣可以幫助用戶更好地使用資料庫。

自動建索引功能上線後，資料庫實例的請求平均耗時大幅下降，整個小程式雲開發資料庫的大盤的平均耗時也減少了50%以上，如下圖所示。

自動加索引上線後的效果

誠然，自動建索引還有一定的局限性，比如使用不等於和正則匹配等複雜查詢方式時。此時就需要其他方式來處理，比如前臺提示用戶應該如何優化查詢語句；或者根據云資料庫提供的慢日誌分析工具來分析慢日誌並針對性地給出解決方案。

五、總結和展望

小程式雲開發可以大大解放小程式開發者的生產力，降低開發的成本和難度。其中，雲資料庫扮演了舉足輕重的角色。針對小程式雲開發對雲資料庫提出的 5 大需求：安全性、易用性、低成本、高性能、靈活性，我們從資料庫架構設計等方面做了諸多改造和優化，使得雲資料庫可以更加貼合小程式的使用場景。

面向未來，在雲資料庫的管控層我們也將提供更加細粒度的監控（當然，是給我們自己看的，用戶無需關註），更智能的 DBA 和更高效的彈性伸縮能力（比如基於 k8s 的雲資料庫）；在雲資料庫的內核層，我們將封裝更多的底層存儲引擎能力暴露給 API 層，並深度結合小程式的使用場景來進行定製化開發（比如調研發現很多小程式是答題相關的，那麼我們可以提供更優的中文文本索引能力），進一步提升事務的性能等。

我們有理由相信，雲開發資料庫將在 serverless 理念的指導下不斷完善自己，和小程式一起發展得越來越好。

參考資料