作者：phoenixxliu，騰訊 TEG 后臺(tái)開發(fā)工程師

目錄：

• 導(dǎo)語
• 一、背景
• 二、競(jìng)品分析
• 三、需求和挑戰(zhàn)
• 四、架構(gòu)和方案
• 五、總結(jié)和展望

導(dǎo)語

小程序云開發(fā)(Tencent CloudBase)擁有易接入、高性能、高可用等特性，其中云數(shù)據(jù)庫作為核心組件之一，可以有效降低運(yùn)維成本，幫助開發(fā)者實(shí)現(xiàn)業(yè)務(wù)快速上線與迭代。本文將簡(jiǎn)要介紹如何通過 TEG 云架構(gòu)平臺(tái)部的高性能分布式 NoSQL 數(shù)據(jù)庫，為近百萬小程序云開發(fā)用戶提供完整的原生云端數(shù)據(jù)庫能力支持。

一、背景

要理解小程序云開發(fā)，不妨將之從字面上拆解為小程序和云開發(fā)兩個(gè)部分。本節(jié)部分我們也將嘗試從這兩個(gè)方面帶大家一起簡(jiǎn)要梳理下相關(guān)的背景知識(shí)。

1.1 云開發(fā)

從軟件工程的角度來看，軟件開發(fā)經(jīng)歷了如下三個(gè)階段：傳統(tǒng)開發(fā)-->敏捷迭代-->serverless。傳統(tǒng)的開發(fā)模式和敏捷開發(fā)模式除了需要開發(fā)者編寫核心的業(yè)務(wù)邏輯外，都不可避免地需要對(duì)后端的基礎(chǔ)設(shè)施進(jìn)行管控和優(yōu)化。比如，一個(gè)應(yīng)用的邏輯可以很簡(jiǎn)單，可一旦涉及到應(yīng)用的發(fā)布部署，就需要開發(fā)者花費(fèi)大量精力進(jìn)行服務(wù)器、數(shù)據(jù)庫、網(wǎng)絡(luò)等基礎(chǔ)設(shè)施的申請(qǐng)和搭建，還要考慮這些后端基礎(chǔ)設(shè)施的穩(wěn)定性、可用性和監(jiān)控指標(biāo)。這一切耗時(shí)耗力又與產(chǎn)品的核心功能無關(guān)，對(duì)于需要快速開發(fā)和試錯(cuò)的產(chǎn)品，傳統(tǒng)的模式開發(fā)速度慢、部署和運(yùn)維成本較高。

開發(fā)趨勢(shì)

 

隨著 serverless 概念的火熱，越來越多的開發(fā)開始轉(zhuǎn)向 serverless 架構(gòu)發(fā)展。“serverless”并不是指后端沒有服務(wù)器，而是將后端服務(wù)器及相關(guān)運(yùn)維操作變得對(duì)上層應(yīng)用開發(fā)者不可見和透明。用戶無需關(guān)心后端的基礎(chǔ)設(shè)施，直接通過云 API 一鍵接入云函數(shù)、云數(shù)據(jù)庫和云存儲(chǔ)來獲取算力、數(shù)據(jù)庫、存儲(chǔ)等基礎(chǔ)的后端能力。這種隨用隨取的開發(fā)模式，不但可以讓開發(fā)者能更專注于自身的業(yè)務(wù)邏輯，還具有低成本、開發(fā)速度快以及免運(yùn)維等諸多優(yōu)勢(shì)。

1.2 小程序

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

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

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

附近的小程序

 

越來越多樣化和越來越火爆的小程序也就意味著會(huì)有越來越多的小程序開發(fā)者入場(chǎng)，如何服務(wù)好這些基于小程序生態(tài)的開發(fā)者們就成為了一件必須要解決的事情。于是小程序云開發(fā)問世，可以說小程序需求 + serverless 理念 = 小程序云開發(fā)。小程序云開發(fā)以微信作為小程序前端運(yùn)行的依托，同時(shí)又通過接入云函數(shù)、云數(shù)據(jù)庫和云存儲(chǔ)等云服務(wù)，來達(dá)到對(duì)后端基礎(chǔ)設(shè)施的“開箱即用”。這些特性可以在很大程度上解放小程序開發(fā)者的生產(chǎn)力，大大降低開發(fā)的成本和難度。

二、競(jìng)品分析

事實(shí)上，互聯(lián)網(wǎng)巨頭們很早就看上了這一塊市場(chǎng)。以 google 為例，自從 2014 年 10 月收購 filebase，google 將自身已有的云端服務(wù)與工具一并整合進(jìn) filebase，使之成為專門為 app 開發(fā)者提供一站式的BaaS(Backend as a service，后端即服務(wù))產(chǎn)品，涵蓋了開發(fā)、質(zhì)量、分析與發(fā)展著四個(gè)主要的模塊，提供了認(rèn)證、數(shù)據(jù)庫、存儲(chǔ)、云函數(shù)、機(jī)器學(xué)習(xí)等服務(wù)以及一系列性能和數(shù)據(jù)分析工具。

filebase-cloud filestore

 

如果重點(diǎn)看它的數(shù)據(jù)庫產(chǎn)品的話，filebase 提供了兩個(gè)選項(xiàng)：Cloud Filestore和實(shí)時(shí)數(shù)據(jù)庫。雖然他們都是 NoSQL 數(shù)據(jù)庫,但官方更推薦使用前者，因?yàn)樗梢蕴峁└咝阅堋⒘己玫目蓴U(kuò)展性以及其他更多的高級(jí)功能。參考官網(wǎng)的介紹，cloud filestore的主要功能如下：

• 靈活性——支持靈活的分層數(shù)據(jù)結(jié)構(gòu)，文檔型;
• 富有表現(xiàn)力的查詢——支持過濾/排序等功能，自動(dòng)家索引，查詢性能與結(jié)果集的大小(而不是整個(gè)數(shù)據(jù)集的大小)成比例;
• 實(shí)時(shí)更新——支持實(shí)時(shí)數(shù)據(jù)同步;
• 離線支持——緩存離線狀態(tài)的寫入、讀取、查詢，待恢復(fù)在線時(shí)，同步本地更改;
• 可擴(kuò)展涉及——基礎(chǔ)架構(gòu)支持自動(dòng)多區(qū)域數(shù)據(jù)復(fù)制，強(qiáng)大一致性保證、原子批量操作以及事務(wù)支持;

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

其他為人熟知的 BaaS 產(chǎn)品還有Parse，最早被 Facebook 收編，但沒多久就停止了運(yùn)行。目前以開源產(chǎn)品的形態(tài)運(yùn)行在 github 上，需要開發(fā)者自行下載源碼并部署和維護(hù)，已經(jīng)失去了 BaaS 的意義。

類似的，國(guó)內(nèi)也有不少提供一站式后端服務(wù)(BaaS)的產(chǎn)品，包括：LeanCloud，Bmob，willddog野狗云服務(wù)、知曉云等。騰訊云推出的小程序云開發(fā)(Tencent CloudBase，TCB)也是屬于同一賽道的產(chǎn)品，即采用 serverless 架構(gòu)的一體化后端云服務(wù)。

三、需求和挑戰(zhàn)

那么，小程序云開發(fā)對(duì)于數(shù)據(jù)庫提出了哪些基本需求?又有哪些挑戰(zhàn)呢?

我們認(rèn)為應(yīng)該主要有以下五個(gè)方面的需求：

• 安全性：對(duì)于數(shù)據(jù)庫而言，數(shù)據(jù)安全是第一位的;
• 易用性：與小程序的特征類似，“開箱即用，用完即走”，簡(jiǎn)單上手，免運(yùn)維;
• 低成本：按量收費(fèi)，精細(xì)化成本控制;
• 高性能：Nosql，支持高并發(fā)讀寫;
• 靈活性：無固定的數(shù)據(jù)庫表模式(no-schema)，支持彈性伸縮;

顯而易見，最大的挑戰(zhàn)就是如何利用已有的技術(shù)來同時(shí)滿足這五個(gè)需求并且能在它們其中達(dá)成良好的 trade-off。畢竟大多數(shù)情況下我們并不是提出了一種新的架構(gòu)，而是在多種方案和組件之間進(jìn)行取舍，正如分布式系統(tǒng)里大名鼎鼎的 CAP 理論，一致性/可用性/分區(qū)容忍性你只能選擇其中的兩個(gè)。

下面將首先介紹我們所使用的架構(gòu)，然后闡述在這樣的一個(gè)架構(gòu)下有什么挑戰(zhàn)以及我們所采取的相應(yīng)對(duì)的方案。(并不一定是最優(yōu)解，讀者可以帶著自己的思考來看待，我們是如何做取舍的)

四、架構(gòu)和方案

圍繞前面提到的 5 個(gè)主要需求，我們從架構(gòu)設(shè)計(jì)等方面對(duì)云開發(fā)數(shù)據(jù)庫進(jìn)行了相應(yīng)的改造及優(yōu)化，其架構(gòu)圖如下：

云數(shù)據(jù)庫架構(gòu)v2

 

最上面是小程序的接入客戶端，中間部分是接入層，底層是數(shù)據(jù)庫的存儲(chǔ)層。當(dāng)然，還有周邊的管控、告警、備份、元數(shù)據(jù)管理等模塊。

開發(fā)者通過云開發(fā)提供的 SDK，可以在微信小程序和 qq 小程序中一鍵獲取云數(shù)據(jù)庫的登錄態(tài)，然后將數(shù)據(jù)讀寫請(qǐng)求發(fā)送給接入層。接入層收到用戶的讀寫請(qǐng)求后，由 keeper 和 agent 這兩個(gè)無狀態(tài)的模塊對(duì)接入的讀寫請(qǐng)求進(jìn)行相關(guān)處理。其中 keeper 主要負(fù)責(zé)請(qǐng)求的鑒權(quán)、認(rèn)證緩存，以及讀寫請(qǐng)求數(shù)的統(tǒng)計(jì)，是云數(shù)據(jù)庫權(quán)限校驗(yàn)，負(fù)載均衡和計(jì)費(fèi)功能實(shí)現(xiàn)的核心模塊。agent 模塊主要有以下幾個(gè)功能：1)維護(hù)接入層到底層數(shù)據(jù)庫實(shí)例的連接池，通過復(fù)用已建立的連接來減少請(qǐng)求鑒權(quán)和連接創(chuàng)建的耗時(shí);2)統(tǒng)計(jì)請(qǐng)求的并發(fā)數(shù)，對(duì)讀寫請(qǐng)求的 QPS 進(jìn)行平滑處理，避免短時(shí)間的毛刺影響數(shù)據(jù)庫性能和可用性;3)在熱遷移切換數(shù)據(jù)庫實(shí)例時(shí)，將請(qǐng)求掛起，切換后再將請(qǐng)求恢復(fù)，來實(shí)現(xiàn)熱遷移過程對(duì)用戶的全程無感知。

最后，讀寫請(qǐng)求通過了接入層，再接下來會(huì)到達(dá)存儲(chǔ)層進(jìn)行數(shù)據(jù)庫實(shí)例的讀寫。鑒于本文的關(guān)注點(diǎn)主要集中在數(shù)據(jù)庫層面，接下來將嘗試從四個(gè)方面對(duì)其進(jìn)行描述。為了避免本文篇幅過長(zhǎng)，部分內(nèi)容并不會(huì)給出細(xì)節(jié)實(shí)現(xiàn)，只是淺析，感興趣的讀者可以留言或者找我們討論。

4.1 訪問控制

權(quán)限控制

首先，用戶只能訪問自己的數(shù)據(jù)庫，無法訪問其他用戶的數(shù)據(jù)庫，不同用戶的數(shù)據(jù)庫之間是相互隔離的，所有連接也必須認(rèn)證。默認(rèn)情況下，用戶是擁有數(shù)據(jù)庫的讀寫權(quán)限的，也支持在數(shù)據(jù)庫上建立多個(gè)不同權(quán)限的賬戶(比如一個(gè)只讀的賬戶)。在小程序云開發(fā)的場(chǎng)景下，利用微信全鏈路免鑒權(quán)的特性，用戶完全不需要太關(guān)心認(rèn)證相關(guān)的問題。

訪問控制

 

連接數(shù)控制

其次是連接數(shù)控制方面，我們會(huì)分兩層進(jìn)行控制：1)在接入層進(jìn)行客戶端連接控制，根據(jù)初始化時(shí)實(shí)例類型(免費(fèi)/付費(fèi)等)進(jìn)行不同的初始化限制，如果超過限制則提示相應(yīng)的用戶;2)接入層到存儲(chǔ)層也有相應(yīng)的連接數(shù)控制，會(huì)池化到后端數(shù)據(jù)庫所有主從節(jié)點(diǎn)的鏈接，避免因過多鏈接而導(dǎo)致的數(shù)據(jù)庫性能問題。

流量&QPS 控制

最后是機(jī)器層面的出入流量控制以及資源使用限制，原理與連接數(shù)控制類似，用戶所有的請(qǐng)求都會(huì)經(jīng)過接入層，因此可以在接入層控制 QPS 進(jìn)而實(shí)現(xiàn)后續(xù)的按量付費(fèi)功能。QPS 超過閾值后可以提示用戶或者在接入層做排隊(duì)處理。

這里有人可能會(huì)質(zhì)疑了，云開發(fā)數(shù)據(jù)庫不是彈性伸縮的嘛?為何還有 qps 的限制呢?不應(yīng)該是我 qps 越來越高，后端的數(shù)據(jù)庫資源也跟著不斷擴(kuò)容嘛?答：是的，默認(rèn)的配置下會(huì)有一定彈性擴(kuò)展空間，但是會(huì)有一個(gè)限制。當(dāng)然，這里限制具體多少跟產(chǎn)品策略有關(guān)。

4.2 數(shù)據(jù)安全

數(shù)據(jù)安全是數(shù)據(jù)庫最重要的特性之一，畢竟一個(gè)存在數(shù)據(jù)丟失風(fēng)險(xiǎn)的數(shù)據(jù)庫并不能夠在激烈的市場(chǎng)競(jìng)爭(zhēng)中存活下來。那么云數(shù)據(jù)庫是如何保證數(shù)據(jù)安全的呢?

數(shù)據(jù)冗余

要解決數(shù)據(jù)不丟失的問題，首先就是要避免數(shù)據(jù)庫的單點(diǎn)問題，也就是要有數(shù)據(jù)冗余。一般而言，工業(yè)界認(rèn)為比較安全的備份數(shù)為三份。因此，云數(shù)據(jù)庫默認(rèn)是三副本分布式存儲(chǔ)，即一份數(shù)據(jù)會(huì)存儲(chǔ)三份放在不同的機(jī)器上，同時(shí)機(jī)器也要分布在不同的機(jī)房中。節(jié)點(diǎn)區(qū)分主從狀態(tài)，主節(jié)點(diǎn)可以接受讀寫請(qǐng)求，從節(jié)點(diǎn)只能接受讀請(qǐng)求。副本集內(nèi)的存儲(chǔ)節(jié)點(diǎn)之間采用 raft-like 的副本集協(xié)議來實(shí)現(xiàn)三副本數(shù)據(jù)的最終一致性。

高可用

當(dāng)機(jī)器發(fā)生故障時(shí)副本集內(nèi)的數(shù)據(jù)節(jié)點(diǎn)會(huì)自動(dòng)切換(FailOver)，從節(jié)點(diǎn)變?yōu)橹鞴?jié)點(diǎn)繼續(xù)提供服務(wù)，從而把對(duì)業(yè)務(wù)的影響降到最低。

數(shù)據(jù)安全

 

備份回檔

云數(shù)據(jù)庫的備份對(duì)用戶完全透明，后臺(tái)根據(jù)數(shù)據(jù)庫的狀態(tài)自動(dòng)選擇性地進(jìn)行全量以及增量備份。詳細(xì)來說就是用戶的寫入越快，后臺(tái)的備份頻率也會(huì)相應(yīng)增高，這樣做的目的是為了減少回檔時(shí)需要回放的數(shù)據(jù)，提升回檔性能。

支持 7 天內(nèi)任意時(shí)間回檔，可以選擇只回檔單個(gè)表，進(jìn)一步減少回檔所需的時(shí)間。

另外，如果節(jié)點(diǎn)故障需要新加一個(gè)節(jié)點(diǎn)到副本集中，可選擇從備份文件中進(jìn)行恢復(fù)，從而減少對(duì)源集群的侵入性。

基于冷備恢復(fù)

 

多可用區(qū)容災(zāi)

云數(shù)據(jù)庫默認(rèn)跨三機(jī)房(AZ, Availability Zone)部署，也對(duì)用戶透明，任意一個(gè)機(jī)房掛掉也不會(huì)對(duì)服務(wù)產(chǎn)生任何影響;同時(shí)也可以支持跨多地域，兩地三中心等模式。比如北京、上海、深圳各有一個(gè)節(jié)點(diǎn)，業(yè)務(wù)采取就近接入的方式來降低業(yè)務(wù)訪問云數(shù)據(jù)庫的時(shí)延。

兩地三中心

 

另外，所有到數(shù)據(jù)庫的連接必須認(rèn)證以及所有數(shù)據(jù)均加密壓縮存儲(chǔ)，這兩點(diǎn)保證了數(shù)據(jù)的鏈路安全以及存儲(chǔ)安全。

4.3 彈性伸縮

彈性伸縮

很多時(shí)候，業(yè)務(wù)的訪問模式會(huì)呈現(xiàn)很明顯的周期性或者不均勻的特征，比如外賣類業(yè)務(wù)的高峰期出現(xiàn)在用餐時(shí)段，其他時(shí)段訪問較少;游戲類業(yè)務(wù)的高峰期出現(xiàn)在晚上或周末，上班時(shí)間較少;還有一些電商類業(yè)務(wù)的高峰期出現(xiàn)在特殊時(shí)間點(diǎn)(雙十一，618 等)。

周期性規(guī)律

 

如果按照傳統(tǒng)的數(shù)據(jù)庫運(yùn)維模式，需要提前預(yù)估量級(jí)，然后運(yùn)維執(zhí)行擴(kuò)容，等活動(dòng)結(jié)束后再縮容回來(不然成本是個(gè)問題)。那么在小程序的場(chǎng)景，既然要做到用戶對(duì)后端服務(wù)無感知，那么資源的擴(kuò)縮容也應(yīng)當(dāng)不被感受到。

基于這個(gè)出發(fā)點(diǎn)，我們實(shí)現(xiàn)了云數(shù)據(jù)庫的彈性伸縮。依賴管控系統(tǒng)的負(fù)載監(jiān)控模塊，我們可以根據(jù)數(shù)據(jù)庫的實(shí)時(shí)負(fù)載情況動(dòng)態(tài)地調(diào)整數(shù)據(jù)庫的資源，并且自動(dòng)調(diào)整敏感度，從而來有效地應(yīng)對(duì)數(shù)據(jù)庫負(fù)載突增的情況，在負(fù)載低的時(shí)候也可以將資源釋放提供給其他更需要的實(shí)例。其次，為了避免單個(gè)大查詢引起的頻繁調(diào)整，我們?cè)O(shè)置了滑動(dòng)窗口和“去毛刺”機(jī)制，保證了彈性伸縮盡可能平滑地進(jìn)行。

數(shù)據(jù)庫熱遷移

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

熱遷移

 

整體來看，數(shù)據(jù)庫熱遷移主要分為三個(gè)部分：

1. 數(shù)據(jù)同步(Data Sync)
2. 割接(Cutover)
3. 狀態(tài)變更(Status Change)

第一階段，高性能數(shù)據(jù)同步的能力完全由底層數(shù)據(jù)庫提供支持，需要先同步全量數(shù)據(jù)，再同步全量階段新產(chǎn)生的操作記錄(operation log)，然后不斷循環(huán)這個(gè)過程，直到源數(shù)據(jù)庫和目標(biāo)數(shù)據(jù)庫的差距非常小，實(shí)現(xiàn)方式非常類似于一個(gè)副本集內(nèi)的主從同步。在這一階段中，源數(shù)據(jù)庫是可讀可寫的。第二階段，也就是當(dāng)兩邊數(shù)據(jù)庫的差距非常小時(shí)、進(jìn)行熱遷移的割接過程，將源數(shù)據(jù)庫變?yōu)椴豢勺x不可寫，接入層臨時(shí) hold 住用戶的請(qǐng)求，并不返回錯(cuò)誤;數(shù)據(jù)同步這邊，在目標(biāo)數(shù)據(jù)庫補(bǔ)齊了所有的操作記錄并且校驗(yàn)兩邊數(shù)據(jù)完全一致之后，進(jìn)行割接，其中包括用戶的拷貝及一系列元數(shù)據(jù)變更。第三階段，割接完成后，將目標(biāo)集群變?yōu)榭捎脿顟B(tài)，之前由接入層 block 住的請(qǐng)求可以釋放并繼續(xù)執(zhí)行。由于割接的過程非常迅速(秒級(jí))，這些請(qǐng)求并不會(huì)返回類似超時(shí)之類的失敗。當(dāng)然這里只考慮了最一般的情況，當(dāng)某個(gè)環(huán)節(jié)出現(xiàn)異常時(shí)需要考慮到相應(yīng)部分的回滾和應(yīng)對(duì)邏輯，涉及狀態(tài)機(jī)的變化，這相對(duì)比較復(fù)雜，在此不多贅述。

我們認(rèn)為數(shù)據(jù)熱遷移要做到用戶完全無感知，主要有以下幾個(gè)難點(diǎn)：

• 強(qiáng)一致性感知集群變更;
• 高性能割接;
• 割接狀態(tài)持久化以及超時(shí)控制;
• 對(duì)于用戶請(qǐng)求的臨時(shí)處理;

在我們的架構(gòu)中，底層數(shù)據(jù)庫提供了高性能數(shù)據(jù)同步的基本能力;由于有接入層 agent 的存在，可以很方便地實(shí)現(xiàn) agent 之間的強(qiáng)一致性感知以及對(duì)于用戶請(qǐng)求的臨時(shí)處理(比如 block 住);引入了分布式 KV 存儲(chǔ)系統(tǒng) etcd 來實(shí)現(xiàn)割接狀態(tài)的持久化和超時(shí)控制，如下圖所示：

熱遷移狀態(tài)轉(zhuǎn)移圖

 

經(jīng)過線上環(huán)境測(cè)試，當(dāng)數(shù)據(jù)庫梳理維持在 3k 左右的 QPS(100% write)時(shí)，熱遷移成功，從前端看用戶請(qǐng)求在遷移過程中成功率一直維持 100%，也就是做到了熱遷移對(duì)用戶的完全透明。

微信讀書每日一答

 

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

4.4 智能 DBA

智能 DBA 是一個(gè)非常大的話題，涉及各個(gè)方面，分層級(jí)來看主要包含以下三層：應(yīng)用層，處理層和采集層。采集層負(fù)責(zé)從多個(gè)數(shù)據(jù)源采集需要的數(shù)據(jù)和指標(biāo);處理層對(duì)采集到的數(shù)據(jù)進(jìn)行預(yù)處理和分析并產(chǎn)生相應(yīng)的決策和建議;應(yīng)用層則會(huì)根據(jù)不同的應(yīng)用場(chǎng)景進(jìn)行不同的處理，比如自動(dòng)化運(yùn)維模塊需要進(jìn)行異常處理，而巡檢模塊只需要進(jìn)行巡檢和告警即可。

智能DBA

 

自動(dòng)化運(yùn)維

為了進(jìn)一步減少后臺(tái)側(cè)的運(yùn)維操作，我們實(shí)現(xiàn)了自動(dòng)化運(yùn)維平臺(tái)。通過對(duì)運(yùn)行時(shí)的存儲(chǔ)節(jié)點(diǎn)狀態(tài)的監(jiān)控，對(duì)每個(gè)節(jié)點(diǎn)進(jìn)行探活及故障判斷，然后在決策中心根據(jù)故障的統(tǒng)計(jì)結(jié)果進(jìn)行相應(yīng)的自動(dòng)化運(yùn)維操作(比如磁盤只讀了則強(qiáng)制切主)同時(shí)也會(huì)告警給運(yùn)維人員，確保自動(dòng)化運(yùn)維結(jié)果正確。

自動(dòng)化運(yùn)維平臺(tái)

 

對(duì)于一部分自動(dòng)化運(yùn)維沒辦法覆蓋的問題，我們有各個(gè)層面和維度(機(jī)器、實(shí)例、節(jié)點(diǎn)等)全套的秒級(jí)監(jiān)控，各項(xiàng)指標(biāo)共計(jì)69+項(xiàng)，后端可以實(shí)時(shí)感知到數(shù)據(jù)庫的狀態(tài);發(fā)現(xiàn)問題盡早處理。

索引優(yōu)化

索引是數(shù)據(jù)庫中非常重要的概念，用于加速數(shù)據(jù)庫的查找。在小程序的場(chǎng)景下，我們希望將用戶對(duì)于后端的數(shù)據(jù)庫的認(rèn)知降低到越少越好。于是實(shí)現(xiàn)了一系列查詢優(yōu)化的功能，比如自動(dòng)建索引。當(dāng)我們的接入層和存儲(chǔ)層發(fā)現(xiàn)用戶有很多查詢到后端都是全表掃描時(shí)，就會(huì)根據(jù)用戶的 query 具體字段進(jìn)行對(duì)應(yīng)索引的添加工作。等到索引建立完成，用戶就可以直接享受優(yōu)化后的查詢結(jié)果。重要的是，這一過程用戶同樣也是無感知的。

我們認(rèn)為自動(dòng)建索引要做到用戶完全無感知需要考慮以下幾個(gè)主要問題：

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

自動(dòng)建索引功能上線后，數(shù)據(jù)庫實(shí)例的請(qǐng)求平均耗時(shí)大幅下降，整個(gè)小程序云開發(fā)數(shù)據(jù)庫的大盤的平均耗時(shí)也減少了50%以上，如下圖所示。

自動(dòng)加索引上線后的效果

 

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

五、總結(jié)和展望

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

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

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

參考資料

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