解密小程式云開發資料庫

目錄：

• 導語

• 一、背景

• 二、競品分析

• 三、需求和挑戰

• 四、架構和方案

• 五、總結和展望

導語

小程式云開發（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

作者：phoenixxliu

本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/Decrypt-the-applet-cloud-development-database.html

標籤：其他

上一篇：一文掌握MyBatis的動態SQL使用與原理

下一篇：CloudCanal實戰-五分鐘搞定Oracle到StarRocks資料遷移與同步