《當(dāng)容器遇上數(shù)據(jù)庫……》要點(diǎn):
本文介紹了當(dāng)容器遇上數(shù)據(jù)庫……,希望對(duì)您有用。如果有疑問,可以聯(lián)系我們。
任何通用的技術(shù),都承載著一定的技術(shù)使命,有其歷史背景和最終目標(biāo).評(píng)價(jià)其價(jià)值是要思考它的使命和目標(biāo),不能單純的從自己的個(gè)例出發(fā).
這篇文章 http://t.cn/RpZVr3Q(后簡(jiǎn)稱 7 文),本文章寫的原因就是反駁該文,同時(shí)也想說說應(yīng)用容器化以及云化的價(jià)值.閱讀本文時(shí)建議先閱讀一下本人寫的 以及我之前 http://t.cn/RpZVQCw(后面簡(jiǎn)稱容文),本文中會(huì)直接引用該文的一些觀點(diǎn).
總結(jié)了兩點(diǎn):
容器化數(shù)據(jù)庫沒有帶來太多額外價(jià)值,數(shù)據(jù)庫不需要經(jīng)常構(gòu)建和部署,也不需要經(jīng)常升級(jí),數(shù)據(jù)庫實(shí)例的環(huán)境也不需要經(jīng)常變,用 Ansible 也可以輕松部署和設(shè)置.
引入容器帶來的,平安,IO,網(wǎng)絡(luò)等方面的技術(shù)成本和風(fēng)險(xiǎn),如非必要,勿增實(shí)體.
如何對(duì)一項(xiàng)通用技術(shù)做價(jià)值評(píng)估
任何通用的技術(shù),都承載著一定的技術(shù)使命,有其歷史背景和最終目標(biāo).評(píng)價(jià)其價(jià)值是要思考它的使命和目標(biāo),不能單純的從自己的個(gè)例出發(fā).
比如以該文中提到的 Ansible 來說,一次我給一技術(shù)負(fù)責(zé)人推薦 Ansible 的時(shí)候,他說 Ansible 的功能我們自己用 shell 寫的一套框架已經(jīng)搞定了,完全沒必要引入額外的工具增加復(fù)雜度.
我說 Ansible 可以屏蔽操作系統(tǒng)的細(xì)節(jié),容易些寫出跨操作系統(tǒng)的通用配置腳本,他說我們的操作系統(tǒng)都是 Ubuntu ,這個(gè)功能對(duì)我們沒價(jià)值. 我說 Ansible 可以把變量和配置腳本分離,提高腳本的復(fù)用程度,他說我們的腳本也一定程度上做了變量分離,我們只分離必要的,滿足我們當(dāng)前的項(xiàng)目了.我說 Ansible 文檔詳細(xì),學(xué)習(xí)成本低,他說 shell 腳本看看源碼就會(huì)了,并且改起來也容易.最后這個(gè)爭(zhēng)論沒有任何結(jié)果,誰都沒說服誰.
后來我也一直在思考,到底問題在哪兒?
其實(shí)每種技術(shù)的推廣時(shí),無論是工具,框架還是語言,都會(huì)遇到類似的爭(zhēng)論.后來我想明白了,任何通用的技術(shù)的最重要的目標(biāo)其實(shí)是增加軟件的復(fù)用能力,無論是該技術(shù)本身還是由該技術(shù)衍生出來的產(chǎn)物,但如果不考慮復(fù)用,應(yīng)用到具體的場(chǎng)景時(shí)效果都會(huì)打折,所以不能只用具體的場(chǎng)景去評(píng)估通用技術(shù)的價(jià)值.
再拿前面的 Ansible 為例,Ansible 本身是一個(gè)服務(wù)器配置管理工具,它的目標(biāo)是讓服務(wù)器的配置變更代碼化(Configuration management Infrastructure as Code),然后讓應(yīng)用的安裝以及配置的能力組件化,它稱之為 Playbook,然后可以共享復(fù)用.
所以你可以在網(wǎng)上搜索到各種 Ansible 的 Playbook,比如數(shù)據(jù)庫集群的安裝配置等. 它為了實(shí)現(xiàn)這個(gè)目標(biāo),抽象了一套配置語法,通過聲明式的配置來定義服務(wù)器上的基礎(chǔ)設(shè)施狀態(tài),也一定程度上屏蔽了操作系統(tǒng)細(xì)節(jié)(實(shí)在屏蔽不了的,也可以通過簡(jiǎn)單的配置規(guī)則來適配),同時(shí)做了變量和配置的分離,避免和具體的環(huán)境的耦合.
也就是說,只有能接受它的核心思想 —— 服務(wù)器基礎(chǔ)設(shè)施變更代碼化,然后考慮到復(fù)用價(jià)值,復(fù)用別人的 Playbook 或者將自己的 Playbook 復(fù)用到更多的項(xiàng)目或者團(tuán)隊(duì),Ansible 的價(jià)值才會(huì)體現(xiàn)出來. 比如前面爭(zhēng)論的那個(gè)案例,如果考慮到以后會(huì)有更復(fù)雜的操作系統(tǒng)環(huán)境,可能有更多的,更復(fù)雜的項(xiàng)目需要管理,避免運(yùn)維手動(dòng)操作引入不預(yù)期的變更,導(dǎo)致無法追蹤,才值得引入 Ansible.
所以,不要僅僅從自己當(dāng)前的業(yè)務(wù)需求來斷定一個(gè)通用技術(shù)的價(jià)值,比如該文章的標(biāo)題如果改成《我們當(dāng)前的數(shù)據(jù)庫不適合 Docker 以及容器化的 7 大原因》,爭(zhēng)議就小很多.看一個(gè)文章要搞清楚它是在做具體的選型分析還是通用的價(jià)值判斷.
數(shù)據(jù)庫容器化的目標(biāo)和價(jià)值
我們?cè)購臄?shù)據(jù)庫容器化這個(gè)場(chǎng)景分析一下.
當(dāng)前我們開發(fā)出的任何軟件,到用戶部署運(yùn)行變成一個(gè)服務(wù),之間是有巨大的鴻溝的. 比如以數(shù)據(jù)庫(MySQL/PostgreSQL)為例,廠商交付給用戶的是一個(gè)安裝包,而用戶期望得到的是一個(gè)主從的數(shù)據(jù)庫集群,能支持故障主從切換,自動(dòng)遷移恢復(fù),自動(dòng)備份,還要能監(jiān)控報(bào)警,當(dāng)然要是有個(gè) Dashboard 來通過界面操作,實(shí)現(xiàn)自動(dòng)升級(jí),就更好了,更復(fù)雜的需求可能還需要支持讀寫分離和自動(dòng)數(shù)據(jù)庫切分. 可以看出,二者之間是有巨大的鴻溝的,而這個(gè)鴻溝當(dāng)前是靠用戶的運(yùn)維人員來填充的.
運(yùn)維人員如何填充呢?
先從網(wǎng)上找到一些技術(shù)資料,怎么做 MySQL 主從復(fù)制,怎么做高可用(keepalived,虛IP等),怎么做雙主,怎么通過代理做讀寫分離,然后將這些組件用腳本粘結(jié)起來,部署到服務(wù)器上. 當(dāng)然這還是運(yùn)維實(shí)例比較強(qiáng)的,如果運(yùn)維實(shí)力不夠(大多數(shù)創(chuàng)業(yè)公司不可能在這種基礎(chǔ)設(shè)施上投入研發(fā)精力的)可能連主從和備份都做不好,即便是自己用腳本寫了一些簡(jiǎn)單的工具,由于測(cè)試不夠充分,環(huán)境異常考慮不周,正式用的時(shí)候可能就出錯(cuò)了,比如前一段時(shí)間的 gitlab 刪庫事件.
簡(jiǎn)單回顧下 gitlab 事件,本來單節(jié)點(diǎn)的數(shù)據(jù)刪除是不應(yīng)該影響整個(gè)集群的,但因?yàn)閺膸鞌?shù)據(jù)同步不完備(所以可以推斷從庫應(yīng)該是沒有啟用過,沒有做讀寫分離),不能直接升級(jí)從庫為主庫,而其他的多種備份工具都沒生效.
這大概是大多數(shù)公司的現(xiàn)狀,有一些基礎(chǔ)設(shè)施工具,但基本都是和環(huán)境耦合的腳本,也正如《7 文》中所說,數(shù)據(jù)庫等基礎(chǔ)服務(wù)部署后很少需要去做變動(dòng),并且隨著數(shù)據(jù)越來越多,越來越不敢動(dòng),每次變更,比如升級(jí)等,就是一個(gè)復(fù)雜的工程,差不多要發(fā)起一場(chǎng)戰(zhàn)役,但一旦出現(xiàn)預(yù)期外的故障,就缺少必要的工具和經(jīng)驗(yàn)去應(yīng)對(duì). 那如何避免這種問題呢?左耳朵耗子的文章《從 GITLAB 誤刪除數(shù)據(jù)庫想到的》提出了一個(gè)建議:「設(shè)計(jì)出一個(gè)高可用的系統(tǒng),通過自動(dòng)化的方式去處理問題」.
但是這個(gè)基礎(chǔ)設(shè)施的自動(dòng)化高可用系統(tǒng),有那么容易設(shè)計(jì)么?一方面大多數(shù)公司受限于研發(fā)實(shí)力,沒時(shí)間和精力做這種系統(tǒng),另外一方面即便是有研發(fā)實(shí)力,這種系統(tǒng)并不能直接產(chǎn)生價(jià)值,如何得到高層的支持?能得到多大資源支持?那數(shù)據(jù)庫廠商或者其他商業(yè)公司能否提供這樣一個(gè)數(shù)據(jù)庫服務(wù),再或者能否通過開源項(xiàng)目打造出一個(gè)數(shù)據(jù)庫服務(wù),用戶可以一鍵部署呢?這樣就能將各公司的運(yùn)維經(jīng)驗(yàn)沉淀成具體的工具和組件,而不是像現(xiàn)在,運(yùn)維經(jīng)驗(yàn)的沉淀和傳播基本都只能通過技術(shù)分享或者人員流動(dòng),這對(duì)業(yè)界是一種很大的浪費(fèi).
那我們?cè)O(shè)想一下,如果要做前面描述的這樣一個(gè)系統(tǒng),都需要什么條件.首先,得有一種應(yīng)用的安裝包的環(huán)境無關(guān)的封裝,如果要適配不同的操作系統(tǒng),辦理不同的環(huán)境異構(gòu)問題,就很難了. 其次,基礎(chǔ)環(huán)境可編程化,可以在程序中實(shí)現(xiàn)網(wǎng)絡(luò),存儲(chǔ)等環(huán)境的動(dòng)態(tài)適配.再次,要有一個(gè)調(diào)度層,可以做動(dòng)態(tài)遷移.最后,需要一個(gè)編排文件來定義各種組件,以及一種打包格式,將多個(gè)組件封裝到同一個(gè)包中做分發(fā).
Ansible/Puppet 等配置管理工具一直想做這個(gè)事情,并想封裝成可復(fù)用的組件,可惜由于基礎(chǔ)設(shè)施的環(huán)境不統(tǒng)一,不可編程化,而配置管理工具只能一定程度辦理部署時(shí)的復(fù)雜性,應(yīng)對(duì)不了動(dòng)態(tài)的故障,基本很難達(dá)到這個(gè)目標(biāo).
IaaS 云實(shí)現(xiàn)了基礎(chǔ)設(shè)施的標(biāo)準(zhǔn)化,可編程化,可動(dòng)態(tài)調(diào)度.所以現(xiàn)在 IaaS 云基本都有 RDS(Relational Database Service),功能和前面的描述的用戶需求非常類似.但 IaaS 的問題是當(dāng)前 IaaS 的 API 基本都是指令式的,是面向資源的,不是面向應(yīng)用的,第三方很難通過這種 API 來調(diào)度應(yīng)用,所以這種服務(wù)第三方很難實(shí)現(xiàn),基本都是云廠商自己定制(IaaS 上也有鏡像市場(chǎng),但只能是單個(gè)鏡像的應(yīng)用,不能實(shí)現(xiàn)復(fù)雜的應(yīng)用),同時(shí) IaaS 的鏡像都是 VM,很難實(shí)現(xiàn)跨云的分發(fā).
Docker 的鏡像,幾乎完美實(shí)現(xiàn)了前面提到的安裝包的環(huán)境無關(guān)的封裝,也就是大家說的集裝箱能力,又通過鏡像倉庫提供了分發(fā)機(jī)制.上面封裝一層編排調(diào)度系統(tǒng)(Swarm,Kubernetes,Mesos),再加上標(biāo)準(zhǔn)化的網(wǎng)絡(luò)和存儲(chǔ),于是基本達(dá)到了我們上面所描述的條件.
容器平臺(tái)的最終目標(biāo)其實(shí)是屏蔽分布式系統(tǒng)的資源管理細(xì)節(jié),提供分布式應(yīng)用的標(biāo)準(zhǔn)運(yùn)行環(huán)境,同時(shí)定義一種分布式應(yīng)用的 package,對(duì)開發(fā)者來說降低分布式系統(tǒng)的開發(fā)成本,對(duì)用戶來說降低分布式應(yīng)用的維護(hù)成本,對(duì)廠商來說降低分布式應(yīng)用的分發(fā)成本,也就是 DataCenter OS 或 Distributed OS,可簡(jiǎn)稱 DCOS.
也就是說,僅僅把數(shù)據(jù)庫弄成容器鏡像,這僅僅是第一步,是為了后面的目的服務(wù)的.有了這一步,才有可能依托容器編排調(diào)度系統(tǒng)封裝更高級(jí)的通用服務(wù).
有了這種能力后,運(yùn)維的經(jīng)驗(yàn)就可以沉淀成代碼,積累成具體的工具和服務(wù).軟件的價(jià)值在于復(fù)用,可復(fù)用的頻次越高范圍越廣,產(chǎn)生的價(jià)值越大,越值得投入.比如 RDS 這種服務(wù),研發(fā)本身的復(fù)雜度本來不高,關(guān)鍵在對(duì)各種異常情況的處理方案的經(jīng)驗(yàn)積累. 一個(gè)公司遇到的異常狀況肯定有限,只有放在社區(qū)中逐漸積累改進(jìn)才會(huì)逐漸完備.
IaaS 云的 RDS 的優(yōu)勢(shì)其實(shí)也是這一點(diǎn),積累了云上的各種用戶的各種使用場(chǎng)景和異常處理經(jīng)驗(yàn),無論是業(yè)務(wù)增長(zhǎng)還是錯(cuò)誤使用帶來的異常.前兩天 Instapaper 由于 MySQL 數(shù)據(jù)文件過大、達(dá)到 ext3 的 2TB 文件大小限制,而導(dǎo)致其數(shù)據(jù)庫故障,業(yè)務(wù)中斷 31 個(gè)小時(shí),用的就是 AWS 上的 RDS . 雖然使用 RDS 并不能避免故障,但經(jīng)過這次故障之后,AWS 肯定會(huì)改進(jìn) RDS, 將這種故障的應(yīng)對(duì)經(jīng)驗(yàn)沉淀到產(chǎn)品中去,其他用戶就可以避免再次踩坑了.
當(dāng)然還會(huì)有人問,我們當(dāng)前沒有任何精力做更高級(jí)的封裝,只是把數(shù)據(jù)庫簡(jiǎn)單的用容器鏡像跑起來,還有意義么?
也正如我在 《容文》中說的,對(duì)容器技術(shù)可以做漸進(jìn)式的接納,第一步先當(dāng)做安裝包使用,第二步考慮隔離,引入網(wǎng)絡(luò)辦理混合部署帶來的網(wǎng)絡(luò)沖突,第三步再考慮調(diào)度編排系統(tǒng).
《7 文》中也承認(rèn)了容器在開發(fā)測(cè)試環(huán)境中的意義,既然開發(fā)測(cè)試環(huán)境中可以接納容器,保持環(huán)境的一致性不更好么?我在文章《基礎(chǔ)設(shè)施服務(wù)的微服務(wù)化》中分析了為什么應(yīng)該將基礎(chǔ)服務(wù)也作為微服務(wù)的組件,一體化管理.
只有將數(shù)據(jù)庫等基礎(chǔ)設(shè)施作為微服務(wù)的一個(gè)組件,和業(yè)務(wù)應(yīng)用的微服務(wù)互相可以感知,才能實(shí)現(xiàn)最終意義上的全自動(dòng)化.
當(dāng)然,只是有了標(biāo)準(zhǔn)化的運(yùn)行環(huán)境,并不一定能帶來豐富的應(yīng)用,還得依賴商業(yè)模式.這種基礎(chǔ)設(shè)施服務(wù)原來的商業(yè)模式基本只能是 on-premise 私有部署模式,銷售和實(shí)施成本非常高. 企業(yè)應(yīng)用領(lǐng)域是否可能出現(xiàn)一個(gè)類似于 Apple 的 AppStore 的市場(chǎng)來降低銷售和實(shí)施成本? 這方面很多廠商都在嘗試,各容器平臺(tái)都在嘗試推出自己的應(yīng)用規(guī)范,IaaS 廠商也在考慮提供聲明式的編排 API,讓渡出基礎(chǔ)設(shè)施服務(wù),由第三方實(shí)現(xiàn),比如 QingCloud 已經(jīng)發(fā)布的 AppCenter.
如果這個(gè)商業(yè)模式成熟,不僅獨(dú)立的基礎(chǔ)設(shè)施服務(wù)以及中間件公司會(huì)涌現(xiàn)出來,同時(shí)各公司的基礎(chǔ)研發(fā)部門可能會(huì)從原來的支撐部門,變?yōu)?2B 業(yè)務(wù)的營收部門.
引入容器帶來的技術(shù)成本和風(fēng)險(xiǎn)
引入任何技術(shù)都會(huì)帶來技術(shù)成本和風(fēng)險(xiǎn),當(dāng)然容器也不例外.但成本和風(fēng)險(xiǎn)是可以評(píng)估的.
平安 經(jīng)常有人拿容器和虛擬機(jī)的平安做比較,然后說明容器的平安有問題. 但實(shí)際上,大多數(shù)場(chǎng)景下容器并不是用來替代虛擬機(jī)的.如果用戶只是用容器來封裝原來直接運(yùn)行在宿主機(jī)上的服務(wù)進(jìn)程,那平安系數(shù)是增加了呢還是降低了?肯定是增加了啊,因?yàn)槿萜鞫嗔艘粚踊?cgroup 和 namespace 的隔離,最差的情況是這層隔離沒有生效,那也和進(jìn)程直接運(yùn)行在宿主機(jī)上的平安效果一樣.
容器也并沒有額外對(duì)外暴露端口等增加網(wǎng)絡(luò)接觸面,如果不是將容器直接暴露出去讓第三方用戶當(dāng)虛擬機(jī)一樣部署應(yīng)用程序,容器并沒有額外增加平安性問題.
IO 性能影響 容器默認(rèn)情況下一般都不會(huì)對(duì) IO 進(jìn)行限制,并且經(jīng)過很多測(cè)試,基本上容器中的 IO 和宿主機(jī)基本沒有差距,影響甚微,基本可以忽略.至于 《7 文》中所說的丟數(shù)據(jù)的影響,明顯是一個(gè)錯(cuò)誤的表述,Docker 中持久化數(shù)據(jù),一般是通過 volume 或者和宿主機(jī)目錄映射,并不會(huì)直接直接寫到鏡像的 AUFS 上.
網(wǎng)絡(luò)性能影響 首先不確定《7 文》中所說的 Docker 1.9 版本中依然存在的網(wǎng)絡(luò)問題是什么問題,該文也沒給出 issue 鏈接.即便是容器的網(wǎng)絡(luò)方案不成熟, 但 Docker 的網(wǎng)絡(luò)標(biāo)準(zhǔn) libnetwork 以及 Kubernetes 的容器網(wǎng)絡(luò)標(biāo)準(zhǔn) CNI,都是插件式的,用戶可以選擇更成熟的.
如果服務(wù)已經(jīng)運(yùn)行在云上,容器一般都是可以復(fù)用云的 SDN 來實(shí)現(xiàn)網(wǎng)絡(luò)的,比如 AWS 上的基于 VPC 路由的容器網(wǎng)絡(luò)方案,QingCloud 上的 SDN 網(wǎng)絡(luò)直通(SDN Passthrough)方案,和直接使用宿主機(jī)網(wǎng)絡(luò)效果差距很小或者基本一樣.再退一步說,如果網(wǎng)絡(luò)性能真那么重要,并且一臺(tái)服務(wù)器只運(yùn)行一個(gè)服務(wù),那可以直接用 host 模式么.
成本 容器的接納成本已經(jīng)非常小了,即便是復(fù)雜一些的 Kubernetes,相對(duì)于 OpenStack 也簡(jiǎn)單許多,所以才有人通過 Kubernetes 去部署 OpenStack .所以說,容器引入的成本和風(fēng)險(xiǎn)相對(duì)于收益來說,絕對(duì)是可以接受的,即便是它現(xiàn)在存在著許多問題,但絕對(duì)是一個(gè)潛力股,值得投入.
總結(jié)下,對(duì)技術(shù)的接納很多情況下其實(shí)是純粹的觀念問題.最初 IaaS 出來的時(shí)候,不也有很多人說,數(shù)據(jù)庫服務(wù)不適合跑在虛擬機(jī)上了,大數(shù)據(jù)服務(wù)不適合跑在虛擬機(jī)上了,現(xiàn)在不也有很多用戶用的很好.
合適不合適,脫離具體的業(yè)務(wù)場(chǎng)景和需求,是說不清楚的,對(duì)于大多數(shù)用戶和產(chǎn)品來說,數(shù)據(jù)庫的易用性,易維護(hù)性,可用性,要大于性能等其他方面的要求的,對(duì)另外一部分用戶來說,數(shù)據(jù)庫肯定要跑到物理機(jī)上,甚至 PC 服務(wù)器都不能滿足.
所以還是不要僅僅從自己的當(dāng)前的業(yè)務(wù)需求來斷定一個(gè)技術(shù)通用價(jià)值.技術(shù)人喜歡僅僅從自己的角度去進(jìn)行價(jià)值判斷,我個(gè)人也是這樣.最近也在反思,技術(shù)人要突破,無論是創(chuàng)業(yè),還是設(shè)計(jì)對(duì)客戶有價(jià)值的產(chǎn)品,都需要把視角放寬一些,謹(jǐn)以此文與各位共勉.
http://coolshell.cn/articles/17680.html 《從 GITLAB 誤刪除數(shù)據(jù)庫想到的》
http://jolestar.com/infrastructure-service-as-microservice/ 《基礎(chǔ)設(shè)施服務(wù)的微服務(wù)化》
如果你也想像其他 80,000 + 用戶一樣,嘗試在公有云上部署 Docker 方案,不妨在 QingCloud 控制臺(tái)上試用這項(xiàng) SDN 網(wǎng)絡(luò)直通服務(wù),它可以贊助你大幅提升 Docker 性能及網(wǎng)絡(luò)配置易用性.SDN 網(wǎng)絡(luò)直通的所有組件及功能均不計(jì)費(fèi).
歡迎參與《當(dāng)容器遇上數(shù)據(jù)庫……》討論,分享您的想法,維易PHP學(xué)院為您提供專業(yè)教程。
轉(zhuǎn)載請(qǐng)注明本頁網(wǎng)址:
http://www.fzlkiss.com/jiaocheng/9154.html