建站
咨詢
售后
建站咨詢
新聞中心
作者：phoenixxliu，騰訊 TEG 后臺(tái)開(kāi)發(fā)工程師
10年的西藏網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開(kāi)發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。網(wǎng)絡(luò)營(yíng)銷推廣的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整西藏建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無(wú)論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)從事“西藏網(wǎng)站設(shè)計(jì)”,“西藏網(wǎng)站推廣”以來(lái)，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。
目錄：
- 導(dǎo)語(yǔ)
- 一、背景
- 二、競(jìng)品分析
- 三、需求和挑戰(zhàn)
- 四、架構(gòu)和方案
- 五、總結(jié)和展望
導(dǎo)語(yǔ)
小程序云開(kāi)發(fā)(Tencent CloudBase)擁有易接入、高性能、高可用等特性，其中云數(shù)據(jù)庫(kù)作為核心組件之一，可以有效降低運(yùn)維成本，幫助開(kāi)發(fā)者實(shí)現(xiàn)業(yè)務(wù)快速上線與迭代。本文將簡(jiǎn)要介紹如何通過(guò) TEG 云架構(gòu)平臺(tái)部的高性能分布式 NoSQL 數(shù)據(jù)庫(kù)，為近百萬(wàn)小程序云開(kāi)發(fā)用戶提供完整的原生云端數(shù)據(jù)庫(kù)能力支持。
一、背景
要理解小程序云開(kāi)發(fā)，不妨將之從字面上拆解為小程序和云開(kāi)發(fā)兩個(gè)部分。本節(jié)部分我們也將嘗試從這兩個(gè)方面帶大家一起簡(jiǎn)要梳理下相關(guān)的背景知識(shí)。
1.1 云開(kāi)發(fā)
從軟件工程的角度來(lái)看，軟件開(kāi)發(fā)經(jīng)歷了如下三個(gè)階段：傳統(tǒng)開(kāi)發(fā)-->敏捷迭代-->serverless。傳統(tǒng)的開(kāi)發(fā)模式和敏捷開(kāi)發(fā)模式除了需要開(kāi)發(fā)者編寫(xiě)核心的業(yè)務(wù)邏輯外，都不可避免地需要對(duì)后端的基礎(chǔ)設(shè)施進(jìn)行管控和優(yōu)化。比如，一個(gè)應(yīng)用的邏輯可以很簡(jiǎn)單，可一旦涉及到應(yīng)用的發(fā)布部署，就需要開(kāi)發(fā)者花費(fèi)大量精力進(jìn)行服務(wù)器、數(shù)據(jù)庫(kù)、網(wǎng)絡(luò)等基礎(chǔ)設(shè)施的申請(qǐng)和搭建，還要考慮這些后端基礎(chǔ)設(shè)施的穩(wěn)定性、可用性和監(jiān)控指標(biāo)。這一切耗時(shí)耗力又與產(chǎn)品的核心功能無(wú)關(guān)，對(duì)于需要快速開(kāi)發(fā)和試錯(cuò)的產(chǎn)品，傳統(tǒng)的模式開(kāi)發(fā)速度慢、部署和運(yùn)維成本較高。
開(kāi)發(fā)趨勢(shì)
隨著 serverless 概念的火熱，越來(lái)越多的開(kāi)發(fā)開(kāi)始轉(zhuǎn)向 serverless 架構(gòu)發(fā)展?！皊erverless”并不是指后端沒(méi)有服務(wù)器，而是將后端服務(wù)器及相關(guān)運(yùn)維操作變得對(duì)上層應(yīng)用開(kāi)發(fā)者不可見(jiàn)和透明。用戶無(wú)需關(guān)心后端的基礎(chǔ)設(shè)施，直接通過(guò)云 API 一鍵接入云函數(shù)、云數(shù)據(jù)庫(kù)和云存儲(chǔ)來(lái)獲取算力、數(shù)據(jù)庫(kù)、存儲(chǔ)等基礎(chǔ)的后端能力。這種隨用隨取的開(kāi)發(fā)模式，不但可以讓開(kāi)發(fā)者能更專注于自身的業(yè)務(wù)邏輯，還具有低成本、開(kāi)發(fā)速度快以及免運(yùn)維等諸多優(yōu)勢(shì)。
1.2 小程序
小程序應(yīng)該不用過(guò)多介紹，相信現(xiàn)在每一個(gè)使用智能手機(jī)的人都已經(jīng)在日常生活中或多或少地使用到了各種各樣的小程序：點(diǎn)餐、外賣(mài)、打車(chē)、購(gòu)物等等。為了嚴(yán)謹(jǐn)起見(jiàn)，還是按張小龍朋友圈的介紹給出一個(gè)簡(jiǎn)單的定義：小程序是一種不需要下載安裝即可使用的應(yīng)用，它實(shí)現(xiàn)了應(yīng)用“觸手可及”的夢(mèng)想，用戶掃一掃或者搜一下即可打開(kāi)應(yīng)用。也體現(xiàn)了“用完即走”的理念，用戶不用關(guān)心是否安裝太多應(yīng)用的問(wèn)題。應(yīng)用將無(wú)處不在，隨時(shí)可用，但又無(wú)需安裝卸載。
自 2017 年 1 月 9 日微信發(fā)布小程序以來(lái)(十年前正好是喬布斯發(fā)布首款 iphone，有媒體解讀，這是張小龍的致敬以及野心的表現(xiàn))，小程序在這幾年的發(fā)展中已經(jīng)形成了完整的生態(tài)系統(tǒng)，用戶數(shù)和小程序數(shù)量也有了非常顯著的進(jìn)步和發(fā)展，其他主流互聯(lián)網(wǎng)企業(yè)也開(kāi)始紛紛布局小程序平臺(tái)，如支付寶小程序、百度小程序、抖音小程序、今日頭條小程序等等。據(jù)微信提供的數(shù)據(jù)，在 2019 年微信小程序全球交易額達(dá)到了 8000 多億，同比增長(zhǎng) 160%，日活躍用戶超過(guò) 3 億，截至目前，微信上線的小程序超過(guò) 100 萬(wàn)個(gè)，擁有超過(guò) 150 萬(wàn)開(kāi)發(fā)者、8200 多個(gè)第三方平臺(tái)，小程序在電商，零售行業(yè)同比去年有爆發(fā)式增長(zhǎng)。到 2020 年微信公開(kāi)課 PRO(同樣是 1 月 9 日)，全網(wǎng)的小程序數(shù)量已經(jīng)超過(guò) 450 萬(wàn)。可以說(shuō)，我們已經(jīng)進(jìn)入了一個(gè)“全民小程序”的時(shí)代。
受到今年新冠疫情的影響，由于小程序開(kāi)發(fā)相較于 app 開(kāi)發(fā)更加輕量和低門(mén)檻，同時(shí)也能觸達(dá)到更多的人群，各種健康碼、申報(bào)、信息核實(shí)等大部分都采用小程序的形式上線。類似的，線下實(shí)體店客流受阻，越來(lái)越多的商家和店鋪將自己的銷售轉(zhuǎn)移到線上來(lái)保證疫情期間的現(xiàn)金流，小程序同樣也是這一場(chǎng)景的不二選擇。
附近的小程序
越來(lái)越多樣化和越來(lái)越火爆的小程序也就意味著會(huì)有越來(lái)越多的小程序開(kāi)發(fā)者入場(chǎng)，如何服務(wù)好這些基于小程序生態(tài)的開(kāi)發(fā)者們就成為了一件必須要解決的事情。于是小程序云開(kāi)發(fā)問(wèn)世，可以說(shuō)小程序需求 + serverless 理念 = 小程序云開(kāi)發(fā)。小程序云開(kāi)發(fā)以微信作為小程序前端運(yùn)行的依托，同時(shí)又通過(guò)接入云函數(shù)、云數(shù)據(jù)庫(kù)和云存儲(chǔ)等云服務(wù)，來(lái)達(dá)到對(duì)后端基礎(chǔ)設(shè)施的“開(kāi)箱即用”。這些特性可以在很大程度上解放小程序開(kāi)發(fā)者的生產(chǎn)力，大大降低開(kāi)發(fā)的成本和難度。
二、競(jìng)品分析
事實(shí)上，互聯(lián)網(wǎng)巨頭們很早就看上了這一塊市場(chǎng)。以 google 為例，自從 2014 年 10 月收購(gòu) filebase，google 將自身已有的云端服務(wù)與工具一并整合進(jìn) filebase，使之成為專門(mén)為 app 開(kāi)發(fā)者提供一站式的BaaS(Backend as a service，后端即服務(wù))產(chǎn)品，涵蓋了開(kāi)發(fā)、質(zhì)量、分析與發(fā)展著四個(gè)主要的模塊，提供了認(rèn)證、數(shù)據(jù)庫(kù)、存儲(chǔ)、云函數(shù)、機(jī)器學(xué)習(xí)等服務(wù)以及一系列性能和數(shù)據(jù)分析工具。
filebase-cloud filestore
如果重點(diǎn)看它的數(shù)據(jù)庫(kù)產(chǎn)品的話，filebase 提供了兩個(gè)選項(xiàng)：Cloud Filestore和實(shí)時(shí)數(shù)據(jù)庫(kù)。雖然他們都是 NoSQL 數(shù)據(jù)庫(kù),但官方更推薦使用前者，因?yàn)樗梢蕴峁└咝阅?、良好的可擴(kuò)展性以及其他更多的高級(jí)功能。參考官網(wǎng)的介紹，cloud filestore的主要功能如下：
- 靈活性——支持靈活的分層數(shù)據(jù)結(jié)構(gòu)，文檔型;
- 富有表現(xiàn)力的查詢——支持過(guò)濾/排序等功能，自動(dòng)家索引，查詢性能與結(jié)果集的大小(而不是整個(gè)數(shù)據(jù)集的大小)成比例;
- 實(shí)時(shí)更新——支持實(shí)時(shí)數(shù)據(jù)同步;
- 離線支持——緩存離線狀態(tài)的寫(xiě)入、讀取、查詢，待恢復(fù)在線時(shí)，同步本地更改;
- 可擴(kuò)展涉及——基礎(chǔ)架構(gòu)支持自動(dòng)多區(qū)域數(shù)據(jù)復(fù)制，強(qiáng)大一致性保證、原子批量操作以及事務(wù)支持;
另外，filestore是支持按量收費(fèi)的，可支持按數(shù)據(jù)存儲(chǔ)量、流量以及文檔的讀(query)，寫(xiě)(insert/update)，刪除(delete)操作次數(shù)來(lái)收費(fèi)。并且對(duì)外提供了多個(gè)客戶端和開(kāi)發(fā)語(yǔ)言版本的 sdk。
其他為人熟知的 BaaS 產(chǎn)品還有Parse，最早被 Facebook 收編，但沒(méi)多久就停止了運(yùn)行。目前以開(kāi)源產(chǎn)品的形態(tài)運(yùn)行在 github 上，需要開(kāi)發(fā)者自行下載源碼并部署和維護(hù)，已經(jīng)失去了 BaaS 的意義。
類似的，國(guó)內(nèi)也有不少提供一站式后端服務(wù)(BaaS)的產(chǎn)品，包括：LeanCloud，Bmob，willddog野狗云服務(wù)、知曉云等。騰訊云推出的小程序云開(kāi)發(fā)(Tencent CloudBase，TCB)也是屬于同一賽道的產(chǎn)品，即采用 serverless 架構(gòu)的一體化后端云服務(wù)。
三、需求和挑戰(zhàn)
那么，小程序云開(kāi)發(fā)對(duì)于數(shù)據(jù)庫(kù)提出了哪些基本需求?又有哪些挑戰(zhàn)呢?
我們認(rèn)為應(yīng)該主要有以下五個(gè)方面的需求：
- 安全性：對(duì)于數(shù)據(jù)庫(kù)而言，數(shù)據(jù)安全是第一位的;
- 易用性：與小程序的特征類似，“開(kāi)箱即用，用完即走”，簡(jiǎn)單上手，免運(yùn)維;
- 低成本：按量收費(fèi)，精細(xì)化成本控制;
- 高性能：Nosql，支持高并發(fā)讀寫(xiě);
- 靈活性：無(wú)固定的數(shù)據(jù)庫(kù)表模式(no-schema)，支持彈性伸縮;
顯而易見(jiàn)，最大的挑戰(zhàn)就是如何利用已有的技術(shù)來(lái)同時(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)解，讀者可以帶著自己的思考來(lái)看待，我們是如何做取舍的)
四、架構(gòu)和方案
圍繞前面提到的 5 個(gè)主要需求，我們從架構(gòu)設(shè)計(jì)等方面對(duì)云開(kāi)發(fā)數(shù)據(jù)庫(kù)進(jìn)行了相應(yīng)的改造及優(yōu)化，其架構(gòu)圖如下：
云數(shù)據(jù)庫(kù)架構(gòu)v2
最上面是小程序的接入客戶端，中間部分是接入層，底層是數(shù)據(jù)庫(kù)的存儲(chǔ)層。當(dāng)然，還有周邊的管控、告警、備份、元數(shù)據(jù)管理等模塊。
開(kāi)發(fā)者通過(guò)云開(kāi)發(fā)提供的 SDK，可以在微信小程序和 qq 小程序中一鍵獲取云數(shù)據(jù)庫(kù)的登錄態(tài)，然后將數(shù)據(jù)讀寫(xiě)請(qǐng)求發(fā)送給接入層。接入層收到用戶的讀寫(xiě)請(qǐng)求后，由 keeper 和 agent 這兩個(gè)無(wú)狀態(tài)的模塊對(duì)接入的讀寫(xiě)請(qǐng)求進(jìn)行相關(guān)處理。其中 keeper 主要負(fù)責(zé)請(qǐng)求的鑒權(quán)、認(rèn)證緩存，以及讀寫(xiě)請(qǐng)求數(shù)的統(tǒng)計(jì)，是云數(shù)據(jù)庫(kù)權(quán)限校驗(yàn)，負(fù)載均衡和計(jì)費(fèi)功能實(shí)現(xiàn)的核心模塊。agent 模塊主要有以下幾個(gè)功能：1)維護(hù)接入層到底層數(shù)據(jù)庫(kù)實(shí)例的連接池，通過(guò)復(fù)用已建立的連接來(lái)減少請(qǐng)求鑒權(quán)和連接創(chuàng)建的耗時(shí);2)統(tǒng)計(jì)請(qǐng)求的并發(fā)數(shù)，對(duì)讀寫(xiě)請(qǐng)求的 QPS 進(jìn)行平滑處理，避免短時(shí)間的毛刺影響數(shù)據(jù)庫(kù)性能和可用性;3)在熱遷移切換數(shù)據(jù)庫(kù)實(shí)例時(shí)，將請(qǐng)求掛起，切換后再將請(qǐng)求恢復(fù)，來(lái)實(shí)現(xiàn)熱遷移過(guò)程對(duì)用戶的全程無(wú)感知。
最后，讀寫(xiě)請(qǐng)求通過(guò)了接入層，再接下來(lái)會(huì)到達(dá)存儲(chǔ)層進(jìn)行數(shù)據(jù)庫(kù)實(shí)例的讀寫(xiě)。鑒于本文的關(guān)注點(diǎn)主要集中在數(shù)據(jù)庫(kù)層面，接下來(lái)將嘗試從四個(gè)方面對(duì)其進(jìn)行描述。為了避免本文篇幅過(guò)長(zhǎng)，部分內(nèi)容并不會(huì)給出細(xì)節(jié)實(shí)現(xiàn)，只是淺析，感興趣的讀者可以留言或者找我們討論。
4.1 訪問(wèn)控制
權(quán)限控制
首先，用戶只能訪問(wèn)自己的數(shù)據(jù)庫(kù)，無(wú)法訪問(wèn)其他用戶的數(shù)據(jù)庫(kù)，不同用戶的數(shù)據(jù)庫(kù)之間是相互隔離的，所有連接也必須認(rèn)證。默認(rèn)情況下，用戶是擁有數(shù)據(jù)庫(kù)的讀寫(xiě)權(quán)限的，也支持在數(shù)據(jù)庫(kù)上建立多個(gè)不同權(quán)限的賬戶(比如一個(gè)只讀的賬戶)。在小程序云開(kāi)發(fā)的場(chǎng)景下，利用微信全鏈路免鑒權(quán)的特性，用戶完全不需要太關(guān)心認(rèn)證相關(guān)的問(wèn)題。
訪問(wèn)控制
連接數(shù)控制
其次是連接數(shù)控制方面，我們會(huì)分兩層進(jìn)行控制：1)在接入層進(jìn)行客戶端連接控制，根據(jù)初始化時(shí)實(shí)例類型(免費(fèi)/付費(fèi)等)進(jìn)行不同的初始化限制，如果超過(guò)限制則提示相應(yīng)的用戶;2)接入層到存儲(chǔ)層也有相應(yīng)的連接數(shù)控制，會(huì)池化到后端數(shù)據(jù)庫(kù)所有主從節(jié)點(diǎn)的鏈接，避免因過(guò)多鏈接而導(dǎo)致的數(shù)據(jù)庫(kù)性能問(wèn)題。
流量&QPS 控制
最后是機(jī)器層面的出入流量控制以及資源使用限制，原理與連接數(shù)控制類似，用戶所有的請(qǐng)求都會(huì)經(jīng)過(guò)接入層，因此可以在接入層控制 QPS 進(jìn)而實(shí)現(xiàn)后續(xù)的按量付費(fèi)功能。QPS 超過(guò)閾值后可以提示用戶或者在接入層做排隊(duì)處理。
這里有人可能會(huì)質(zhì)疑了，云開(kāi)發(fā)數(shù)據(jù)庫(kù)不是彈性伸縮的嘛?為何還有 qps 的限制呢?不應(yīng)該是我 qps 越來(lái)越高，后端的數(shù)據(jù)庫(kù)資源也跟著不斷擴(kuò)容嘛?答：是的，默認(rèn)的配置下會(huì)有一定彈性擴(kuò)展空間，但是會(huì)有一個(gè)限制。當(dāng)然，這里限制具體多少跟產(chǎn)品策略有關(guān)。
4.2 數(shù)據(jù)安全
數(shù)據(jù)安全是數(shù)據(jù)庫(kù)最重要的特性之一，畢竟一個(gè)存在數(shù)據(jù)丟失風(fēng)險(xiǎn)的數(shù)據(jù)庫(kù)并不能夠在激烈的市場(chǎng)競(jìng)爭(zhēng)中存活下來(lái)。那么云數(shù)據(jù)庫(kù)是如何保證數(shù)據(jù)安全的呢?
數(shù)據(jù)冗余
要解決數(shù)據(jù)不丟失的問(wèn)題，首先就是要避免數(shù)據(jù)庫(kù)的單點(diǎn)問(wèn)題，也就是要有數(shù)據(jù)冗余。一般而言，工業(yè)界認(rèn)為比較安全的備份數(shù)為三份。因此，云數(shù)據(jù)庫(kù)默認(rèn)是三副本分布式存儲(chǔ)，即一份數(shù)據(jù)會(huì)存儲(chǔ)三份放在不同的機(jī)器上，同時(shí)機(jī)器也要分布在不同的機(jī)房中。節(jié)點(diǎn)區(qū)分主從狀態(tài)，主節(jié)點(diǎn)可以接受讀寫(xiě)請(qǐng)求，從節(jié)點(diǎn)只能接受讀請(qǐng)求。副本集內(nèi)的存儲(chǔ)節(jié)點(diǎn)之間采用 raft-like 的副本集協(xié)議來(lái)實(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ù)庫(kù)的備份對(duì)用戶完全透明，后臺(tái)根據(jù)數(shù)據(jù)庫(kù)的狀態(tài)自動(dòng)選擇性地進(jìn)行全量以及增量備份。詳細(xì)來(lái)說(shuō)就是用戶的寫(xiě)入越快，后臺(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ù)庫(kù)默認(rèn)跨三機(jī)房(AZ, Availability Zone)部署，也對(duì)用戶透明，任意一個(gè)機(jī)房掛掉也不會(huì)對(duì)服務(wù)產(chǎn)生任何影響;同時(shí)也可以支持跨多地域，兩地三中心等模式。比如北京、上海、深圳各有一個(gè)節(jié)點(diǎn)，業(yè)務(wù)采取就近接入的方式來(lái)降低業(yè)務(wù)訪問(wèn)云數(shù)據(jù)庫(kù)的時(shí)延。
兩地三中心
另外，所有到數(shù)據(jù)庫(kù)的連接必須認(rèn)證以及所有數(shù)據(jù)均加密壓縮存儲(chǔ)，這兩點(diǎn)保證了數(shù)據(jù)的鏈路安全以及存儲(chǔ)安全。
4.3 彈性伸縮
彈性伸縮
很多時(shí)候，業(yè)務(wù)的訪問(wèn)模式會(huì)呈現(xiàn)很明顯的周期性或者不均勻的特征，比如外賣(mài)類業(yè)務(wù)的高峰期出現(xiàn)在用餐時(shí)段，其他時(shí)段訪問(wèn)較少;游戲類業(yè)務(wù)的高峰期出現(xiàn)在晚上或周末，上班時(shí)間較少;還有一些電商類業(yè)務(wù)的高峰期出現(xiàn)在特殊時(shí)間點(diǎn)(雙十一，618 等)。
周期性規(guī)律
如果按照傳統(tǒng)的數(shù)據(jù)庫(kù)運(yùn)維模式，需要提前預(yù)估量級(jí)，然后運(yùn)維執(zhí)行擴(kuò)容，等活動(dòng)結(jié)束后再縮容回來(lái)(不然成本是個(gè)問(wèn)題)。那么在小程序的場(chǎng)景，既然要做到用戶對(duì)后端服務(wù)無(wú)感知，那么資源的擴(kuò)縮容也應(yīng)當(dāng)不被感受到。
基于這個(gè)出發(fā)點(diǎn)，我們實(shí)現(xiàn)了云數(shù)據(jù)庫(kù)的彈性伸縮。依賴管控系統(tǒng)的負(fù)載監(jiān)控模塊，我們可以根據(jù)數(shù)據(jù)庫(kù)的實(shí)時(shí)負(fù)載情況動(dòng)態(tài)地調(diào)整數(shù)據(jù)庫(kù)的資源，并且自動(dòng)調(diào)整敏感度，從而來(lái)有效地應(yīng)對(duì)數(shù)據(jù)庫(kù)負(fù)載突增的情況，在負(fù)載低的時(shí)候也可以將資源釋放提供給其他更需要的實(shí)例。其次，為了避免單個(gè)大查詢引起的頻繁調(diào)整，我們?cè)O(shè)置了滑動(dòng)窗口和“去毛刺”機(jī)制，保證了彈性伸縮盡可能平滑地進(jìn)行。
數(shù)據(jù)庫(kù)熱遷移
當(dāng)實(shí)例狀態(tài)發(fā)生變更(比如免費(fèi)-->付費(fèi)，冷-->熱)的時(shí)候，可能會(huì)需要進(jìn)行數(shù)據(jù)遷移，比如從性能較差的機(jī)器遷移到性能較好的機(jī)器。有了接入層的配合，我們實(shí)現(xiàn)了用戶無(wú)感知的數(shù)據(jù)庫(kù)熱遷移，可以在不停服的情況下將用戶的數(shù)據(jù)從一個(gè)數(shù)據(jù)庫(kù)無(wú)損遷移到另一個(gè)數(shù)據(jù)庫(kù)。
熱遷移
整體來(lái)看，數(shù)據(jù)庫(kù)熱遷移主要分為三個(gè)部分：
- 數(shù)據(jù)同步(Data Sync)
- 割接(Cutover)
- 狀態(tài)變更(Status Change)
第一階段，高性能數(shù)據(jù)同步的能力完全由底層數(shù)據(jù)庫(kù)提供支持，需要先同步全量數(shù)據(jù)，再同步全量階段新產(chǎn)生的操作記錄(operation log)，然后不斷循環(huán)這個(gè)過(guò)程，直到源數(shù)據(jù)庫(kù)和目標(biāo)數(shù)據(jù)庫(kù)的差距非常小，實(shí)現(xiàn)方式非常類似于一個(gè)副本集內(nèi)的主從同步。在這一階段中，源數(shù)據(jù)庫(kù)是可讀可寫(xiě)的。第二階段，也就是當(dāng)兩邊數(shù)據(jù)庫(kù)的差距非常小時(shí)、進(jìn)行熱遷移的割接過(guò)程，將源數(shù)據(jù)庫(kù)變?yōu)椴豢勺x不可寫(xiě)，接入層臨時(shí) hold 住用戶的請(qǐng)求，并不返回錯(cuò)誤;數(shù)據(jù)同步這邊，在目標(biāo)數(shù)據(jù)庫(kù)補(bǔ)齊了所有的操作記錄并且校驗(yàn)兩邊數(shù)據(jù)完全一致之后，進(jìn)行割接，其中包括用戶的拷貝及一系列元數(shù)據(jù)變更。第三階段，割接完成后，將目標(biāo)集群變?yōu)榭捎脿顟B(tài)，之前由接入層 block 住的請(qǐng)求可以釋放并繼續(xù)執(zhí)行。由于割接的過(guò)程非常迅速(秒級(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ù)熱遷移要做到用戶完全無(wú)感知，主要有以下幾個(gè)難點(diǎn)：
- 強(qiáng)一致性感知集群變更;
- 高性能割接;
- 割接狀態(tài)持久化以及超時(shí)控制;
- 對(duì)于用戶請(qǐng)求的臨時(shí)處理;
在我們的架構(gòu)中，底層數(shù)據(jù)庫(kù)提供了高性能數(shù)據(jù)同步的基本能力;由于有接入層 agent 的存在，可以很方便地實(shí)現(xiàn) agent 之間的強(qiáng)一致性感知以及對(duì)于用戶請(qǐng)求的臨時(shí)處理(比如 block 住);引入了分布式 KV 存儲(chǔ)系統(tǒng) etcd 來(lái)實(shí)現(xiàn)割接狀態(tài)的持久化和超時(shí)控制，如下圖所示：
熱遷移狀態(tài)轉(zhuǎn)移圖
經(jīng)過(guò)線上環(huán)境測(cè)試，當(dāng)數(shù)據(jù)庫(kù)梳理維持在 3k 左右的 QPS(100% write)時(shí)，熱遷移成功，從前端看用戶請(qǐng)求在遷移過(guò)程中成功率一直維持 100%，也就是做到了熱遷移對(duì)用戶的完全透明。
微信讀書(shū)每日一答
我們不妨舉個(gè)例子來(lái)說(shuō)明數(shù)據(jù)庫(kù)熱遷移的應(yīng)用。微信讀書(shū)業(yè)務(wù)就使用了小程序云開(kāi)發(fā)，微信讀書(shū)小程序中的“每日一答”模塊完全使用云數(shù)據(jù)庫(kù)作為底層支撐?！皢?wèn)答 PK”，“每日一答”以及不同類別的題目都分別存儲(chǔ)存在不同的表中，峰值(夜間 0 點(diǎn)左右)QPS 接近 10k，自業(yè)務(wù)上線以來(lái)一直平穩(wěn)運(yùn)行。有一段時(shí)間我們發(fā)現(xiàn)共享資源池內(nèi)的一個(gè)用戶的訪問(wèn)量有明顯增大的趨勢(shì)，彈性伸縮后仍不能完全滿足其需求，為避免其對(duì)微信讀書(shū)實(shí)例產(chǎn)生影響，決定將其整個(gè)數(shù)據(jù)庫(kù)實(shí)例通過(guò)熱遷移的方式移動(dòng)到我們的熱資源池中。由于數(shù)據(jù)量并不大(10G)，在短短幾分鐘之內(nèi)就完成了數(shù)據(jù)的遷移和割接(秒級(jí))工作，整個(gè)過(guò)程對(duì)用戶完全透明，當(dāng)然也沒(méi)有對(duì)微信讀書(shū)實(shí)例產(chǎn)生任何影響。
4.4 智能 DBA
智能 DBA 是一個(gè)非常大的話題，涉及各個(gè)方面，分層級(jí)來(lái)看主要包含以下三層：應(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)。通過(guò)對(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)維操作(比如磁盤(pán)只讀了則強(qiáng)制切主)同時(shí)也會(huì)告警給運(yùn)維人員，確保自動(dòng)化運(yùn)維結(jié)果正確。
自動(dòng)化運(yùn)維平臺(tái)
對(duì)于一部分自動(dòng)化運(yùn)維沒(méi)辦法覆蓋的問(wèn)題，我們有各個(gè)層面和維度(機(jī)器、實(shí)例、節(jié)點(diǎn)等)全套的秒級(jí)監(jiān)控，各項(xiàng)指標(biāo)共計(jì)69+項(xiàng)，后端可以實(shí)時(shí)感知到數(shù)據(jù)庫(kù)的狀態(tài);發(fā)現(xiàn)問(wèn)題盡早處理。
索引優(yōu)化
索引是數(shù)據(jù)庫(kù)中非常重要的概念，用于加速數(shù)據(jù)庫(kù)的查找。在小程序的場(chǎng)景下，我們希望將用戶對(duì)于后端的數(shù)據(jù)庫(kù)的認(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é)果。重要的是，這一過(guò)程用戶同樣也是無(wú)感知的。
我們認(rèn)為自動(dòng)建索引要做到用戶完全無(wú)感知需要考慮以下幾個(gè)主要問(wèn)題：
- 同步 VS.異步?建索引過(guò)程應(yīng)該是異步的，否則將會(huì)阻塞用戶的正常請(qǐng)求。
- 如何控制建索引的風(fēng)險(xiǎn)?主要分為兩個(gè)方向：1)首先需要控制自動(dòng)建索引的頻率。建索引是 cpu 消耗型任務(wù)，如果數(shù)據(jù)庫(kù)一直處于建索引的過(guò)程中很明顯是不可接受的;2)其次需要控制自動(dòng)建索引的數(shù)量，使之在一個(gè)相對(duì)合理的范圍。對(duì)于一般的表不會(huì)有問(wèn)題，但是如果數(shù)據(jù)庫(kù)中的某個(gè)表包含多個(gè)字段，且用戶會(huì)根據(jù)這些字段進(jìn)行不同的查詢，那么不加限制的索引會(huì)導(dǎo)致索引數(shù)量特別多，嚴(yán)重影響用戶的更新效率(因?yàn)楦聲r(shí)除了會(huì)更新數(shù)據(jù)外還會(huì)更新相應(yīng)的索引)。
- 索引該如何實(shí)現(xiàn)動(dòng)態(tài)更新?用戶的查詢并不是一成不變的，伴隨的業(yè)務(wù)的發(fā)展或者變換，對(duì)于同一個(gè)表的查詢很有可能也會(huì)發(fā)生變化。那么之前自動(dòng)建立的索引也需要自動(dòng)刪除，否則長(zhǎng)期下去將成為數(shù)據(jù)庫(kù)的負(fù)擔(dān)和瓶頸。需要根據(jù)用戶查詢條件的變化來(lái)動(dòng)態(tài)更新已有的索引。這里關(guān)于索引的最左匹配原則也值得考慮進(jìn)來(lái)。
- 如何做到對(duì)用戶透明?不僅僅是建索引時(shí)不影響用戶的正常請(qǐng)求，而且需要讓用戶能直接感受到查詢走索引的速度。當(dāng)表內(nèi)數(shù)據(jù)量比較大時(shí)，一次索引的變更操作(比如復(fù)合索引字段順序的變化)可能會(huì)導(dǎo)致用戶的同樣一條查詢存在顯著的耗時(shí)差距，除了向用戶解釋外，我們也可以考慮將索引的變更做得更平滑一些，并提供一系列的查詢優(yōu)化建議。這樣可以幫助用戶更好地使用數(shù)據(jù)庫(kù)。
自動(dòng)建索引功能上線后，數(shù)據(jù)庫(kù)實(shí)例的請(qǐng)求平均耗時(shí)大幅下降，整個(gè)小程序云開(kāi)發(fā)數(shù)據(jù)庫(kù)的大盤(pán)的平均耗時(shí)也減少了50%以上，如下圖所示。
自動(dòng)加索引上線后的效果
誠(chéng)然，自動(dòng)建索引還有一定的局限性，比如使用不等于和正則匹配等復(fù)雜查詢方式時(shí)。此時(shí)就需要其他方式來(lái)處理，比如前臺(tái)提示用戶應(yīng)該如何優(yōu)化查詢語(yǔ)句;或者根據(jù)云數(shù)據(jù)庫(kù)提供的慢日志分析工具來(lái)分析慢日志并針對(duì)性地給出解決方案。
五、總結(jié)和展望
小程序云開(kāi)發(fā)可以大大解放小程序開(kāi)發(fā)者的生產(chǎn)力，降低開(kāi)發(fā)的成本和難度。其中，云數(shù)據(jù)庫(kù)扮演了舉足輕重的角色。針對(duì)小程序云開(kāi)發(fā)對(duì)云數(shù)據(jù)庫(kù)提出的 5 大需求：安全性、易用性、低成本、高性能、靈活性，我們從數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)等方面做了諸多改造和優(yōu)化，使得云數(shù)據(jù)庫(kù)可以更加貼合小程序的使用場(chǎng)景。
面向未來(lái)，在云數(shù)據(jù)庫(kù)的管控層我們也將提供更加細(xì)粒度的監(jiān)控(當(dāng)然，是給我們自己看的，用戶無(wú)需關(guān)注)，更智能的 DBA 和更高效的彈性伸縮能力(比如基于 k8s 的云數(shù)據(jù)庫(kù));在云數(shù)據(jù)庫(kù)的內(nèi)核層，我們將封裝更多的底層存儲(chǔ)引擎能力暴露給 API 層，并深度結(jié)合小程序的使用場(chǎng)景來(lái)進(jìn)行定制化開(kāi)發(fā)(比如調(diào)研發(fā)現(xiàn)很多小程序是答題相關(guān)的，那么我們可以提供更優(yōu)的中文文本索引能力)，進(jìn)一步提升事務(wù)的性能等。
我們有理由相信，云開(kāi)發(fā)數(shù)據(jù)庫(kù)將在 serverless 理念的指導(dǎo)下不斷完善自己，和小程序一起發(fā)展得越來(lái)越好。
參考資料
- Filebase
- Filebase pricing
- Cloud Filestore
- Introducing Cloud Filestore
- rtdv-vs-filestore
- Parse
- LeanCloud
- Bmob
- 知曉云
- Tencent CloudBase
文章標(biāo)題：解密小程序云開(kāi)發(fā)數(shù)據(jù)庫(kù)
網(wǎng)站路徑：http://m.5511xx.com/article/djedidd.html
