作者：phoenixxliu，騰訊 TEG 后臺開發工程師

目錄：

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

導語

小程序云開發(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 等)。

周期性規律

 

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

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

數據庫熱遷移

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

熱遷移

 

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

1. 數據同步(Data Sync)
2. 割接(Cutover)
3. 狀態變更(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 具體字段進行對應索引的添加工作。等到索引建立完成，用戶就可以直接享受優化后的查詢結果。重要的是，這一過程用戶同樣也是無感知的。

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

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

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

自動加索引上線后的效果

 

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

五、總結和展望

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

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

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

參考資料

• Filebase
• Filebase pricing
• Cloud Filestore
• Introducing Cloud Filestore
• rtdv-vs-filestore
• Parse
• LeanCloud
• Bmob
• 知曉云
• Tencent CloudBase