昨天談到關(guān)于serverless database的問題，我的觀點(diǎn)是公有云上使用serverless database我是持正面態(tài)度的，但是對于一般企業(yè)來說，不太建議在私有云搞serverless database,除非是在測試與開發(fā)環(huán)境中，對于數(shù)據(jù)一致性要求沒那么高的場景中使用。昨天有朋友問我如何看待數(shù)據(jù)庫上容器云的問題，數(shù)據(jù)庫容器云實(shí)際上也是一種serverless database，我個(gè)人的觀點(diǎn)，其使用場景也是有一定的限制的。在后面我將會(huì)談?wù)勎覍erverless database應(yīng)用場景的一些個(gè)人看法。

除了應(yīng)用場景的限制外，團(tuán)隊(duì)的技術(shù)能力也是決定組織是否使用serverless database的很重要的因素。可能你會(huì)看到某些互聯(lián)網(wǎng)企業(yè)在這方面用得很溜，你也想去學(xué)他們，不過如果你自己的技術(shù)能力不足，簡單的模仿很可能會(huì)編程東施效顰。如果你的核心業(yè)務(wù)依賴于數(shù)據(jù)庫容器云，而當(dāng)容器云出現(xiàn)故障的時(shí)候，你無法解決這些故障，那么后果如何，是可以想象的見的。

在討論這些問題之前，我們首先要來弄清楚你把數(shù)據(jù)庫遷移到容器云而不選擇云主機(jī)的原因。如果你僅僅是因?yàn)橛X得容器比VM具有更小的開銷（OVERLOAD），那么我建議你要再慎重考慮一下。適當(dāng)節(jié)約IT資源是很合理的，不過目前的數(shù)據(jù)庫服務(wù)器資源與數(shù)據(jù)庫所承載的企業(yè)關(guān)鍵數(shù)據(jù)相比，并不算昂貴。如果你是為了百分之幾的資源消耗差異而選擇將數(shù)據(jù)庫運(yùn)行在容器里，那么就真的可以放棄這個(gè)想法了。

將數(shù)據(jù)庫放在容器云里運(yùn)行，其終極目的都是serverless database，讓數(shù)據(jù)庫這種IT基礎(chǔ)設(shè)施變得很簡單，這才是數(shù)據(jù)庫上容器云的最合理的需求。2年多前，我寫過一篇關(guān)于數(shù)據(jù)庫上容器云的文章，其中對VM還是容器的選擇用一張圖示做了分析。這張圖是我在medium上看到的，是谷歌云解決方案架構(gòu)師本杰明.古德畫的。覺得挺有道理，就抄了下來。

圖片

第一個(gè)選項(xiàng)要回答你的數(shù)據(jù)庫是不是k8s友好的。由于容器較物理機(jī)、虛擬機(jī)等環(huán)境是更容易出現(xiàn)故障的基礎(chǔ)設(shè)施，因此故障自動(dòng)轉(zhuǎn)移事件的發(fā)生可能性比傳統(tǒng)托管或完全托管的數(shù)據(jù)庫高。數(shù)據(jù)庫中包含分片、故障轉(zhuǎn)移選擇、自動(dòng)副本復(fù)制功能的數(shù)據(jù)庫都是屬于k8s友好的數(shù)據(jù)庫，比如ElasticSearch，Cassandra或MongoDB等。而Mysql、Pg、Oracle等數(shù)據(jù)庫則是非k8s友好的數(shù)據(jù)庫。

對于非k8s友好的數(shù)據(jù)庫，如果具有較好的k8s上的運(yùn)行支撐，比如借助于一些Operator來實(shí)現(xiàn)數(shù)據(jù)自動(dòng)復(fù)制/備份，故障自動(dòng)轉(zhuǎn)移等特性，并且組織能夠提供足夠的運(yùn)維支撐，那么也是可以轉(zhuǎn)回使用k8s這條線的。然后我們要回答下面的一個(gè)選項(xiàng)，就是數(shù)據(jù)庫的工作負(fù)載是不是適合k8s，如果這個(gè)數(shù)據(jù)庫是一個(gè)負(fù)載不高，并且隨著應(yīng)用上線后，負(fù)載增加不是很大（如果有較大的負(fù)載，可以通過橫向擴(kuò)展，而不是增加在一個(gè)獨(dú)立的數(shù)據(jù)庫上），那么這個(gè)工作負(fù)載就是k8s友好的，可以使用k8s。反之，如果這個(gè)數(shù)據(jù)庫工作負(fù)載很大，或者存在十分高的高峰，或者隨著上線時(shí)間推移，數(shù)據(jù)量增長很快，負(fù)載會(huì)越來越大，而且無法很好的橫向擴(kuò)展，那么這個(gè)工作負(fù)載是非K8S友好的。

然后進(jìn)入第三個(gè)選項(xiàng)環(huán)節(jié)，你的工作負(fù)載能支撐多大的并發(fā)量，如果你可以完全控制并發(fā)量，讓k8s能夠承受合理的工作負(fù)載，那么你就放心的在k8s上跑你的數(shù)據(jù)庫吧，否則還是讓數(shù)據(jù)庫跑在一個(gè)完全受控的環(huán)境下。

從上面的分析可以看出，判斷數(shù)據(jù)庫是否能上容器云，主要要考慮兩方面的因素，一個(gè)是你的應(yīng)用負(fù)載是否是可控的，數(shù)據(jù)庫的規(guī)模與負(fù)載是否完全受控，不會(huì)因?yàn)闃I(yè)務(wù)發(fā)展和數(shù)據(jù)量的增長而導(dǎo)致數(shù)據(jù)庫規(guī)模和負(fù)載不可控從而引發(fā)性能問題，這一點(diǎn)是數(shù)據(jù)庫在容器中運(yùn)行的最基本的條件。

第二個(gè)因素是數(shù)據(jù)庫本身是否是容器友好的，其架構(gòu)本身就不怕容器這種不夠穩(wěn)定的基礎(chǔ)設(shè)施出現(xiàn)問題，如果你的數(shù)據(jù)庫本身必須依賴于穩(wěn)定的IT基礎(chǔ)設(shè)施，那么你的數(shù)據(jù)庫上容器云的前提是你的技術(shù)足夠好，能夠提供能力強(qiáng)大的operator，從而讓數(shù)據(jù)庫能夠在容器云中免維護(hù)運(yùn)行。

上面的問題只是回答了能不能在容器云中運(yùn)行數(shù)據(jù)庫而已，而要不要讓的數(shù)據(jù)庫在容器云中跑是另外一個(gè)問題了。我覺得在讓自己的數(shù)據(jù)庫上容器云之前有幾個(gè)問題需要再思考一下。如果你覺得上容器云的最主要的目的是為了節(jié)約計(jì)算資源，那么我建議你立馬放棄這個(gè)想法。對于絕大多數(shù)企業(yè)的幾百個(gè)或者千把個(gè)數(shù)據(jù)庫來說，上容器云節(jié)約的成本，還不夠搞出一套靠譜的operator來。

如果你上容器云的目的是為了簡化運(yùn)維和運(yùn)營，那么還是有點(diǎn)靠譜的。不過你也要考慮一下，你的應(yīng)用是否能將數(shù)據(jù)庫都控制在類似規(guī)模上，確保自動(dòng)化運(yùn)維能夠很好的管理這些數(shù)據(jù)庫，不需要進(jìn)行額外的管理與優(yōu)化。如果你的應(yīng)用無法很好的控制數(shù)據(jù)庫的規(guī)模，那么可能就會(huì)上云一時(shí)爽，爽后一世忙了。

另外一點(diǎn)要考慮的是，你的企業(yè)中是否有數(shù)十個(gè)甚至上百個(gè)規(guī)模相當(dāng)，可以使用同樣鏡像模板的數(shù)據(jù)庫，如果是這樣，用容器云還是挺省事的。而如果你的每個(gè)數(shù)據(jù)庫的參數(shù)都需要定制化，那么使用容器云和用虛擬機(jī)就沒啥區(qū)別了。

最后要提醒的還是那個(gè)最初說的問題，你的IT能力是否能夠駕馭好運(yùn)行了成百上千個(gè)小型數(shù)據(jù)庫的容器云，當(dāng)云平臺本身出問題的時(shí)候，你是否能夠很快的解決這些問題。當(dāng)數(shù)據(jù)庫因?yàn)镮T基礎(chǔ)設(shè)施不夠穩(wěn)定而產(chǎn)生切換，丟失部分?jǐn)?shù)據(jù)的時(shí)候，你的業(yè)務(wù)是否能夠承受，也是你需要事先考慮好的問題。