任何通用的技術,都承載著一定的技術使命,有其歷史背景和最終目標.評價其價值是要思考它的使命和目標,不能單純的從自己的個例出發.

這篇文章 http://t.cn/RpZVr3Q(后簡稱 7 文),本文章寫的原因就是反駁該文,同時也想說說應用容器化以及云化的價值.閱讀本文時建議先閱讀一下本人寫的 以及我之前 http://t.cn/RpZVQCw(后面簡稱容文),本文中會直接引用該文的一些觀點.

總結了兩點：

1. 容器化數據庫沒有帶來太多額外價值,數據庫不需要經常構建和部署,也不需要經常升級,數據庫實例的環境也不需要經常變,用 Ansible 也可以輕松部署和設置.

2. 引入容器帶來的,平安,IO,網絡等方面的技術成本和風險,如非必要,勿增實體.

如何對一項通用技術做價值評估

任何通用的技術,都承載著一定的技術使命,有其歷史背景和最終目標.評價其價值是要思考它的使命和目標,不能單純的從自己的個例出發.

比如以該文中提到的 Ansible 來說,一次我給一技術負責人推薦 Ansible 的時候,他說 Ansible 的功能我們自己用 shell 寫的一套框架已經搞定了,完全沒必要引入額外的工具增加復雜度.

我說 Ansible 可以屏蔽操作系統的細節,容易些寫出跨操作系統的通用配置腳本,他說我們的操作系統都是 Ubuntu ,這個功能對我們沒價值. 我說 Ansible 可以把變量和配置腳本分離,提高腳本的復用程度,他說我們的腳本也一定程度上做了變量分離,我們只分離必要的,滿足我們當前的項目了.我說 Ansible 文檔詳細,學習成本低,他說 shell 腳本看看源碼就會了,并且改起來也容易.最后這個爭論沒有任何結果,誰都沒說服誰.

后來我也一直在思考,到底問題在哪兒?

其實每種技術的推廣時,無論是工具,框架還是語言,都會遇到類似的爭論.后來我想明白了,任何通用的技術的最重要的目標其實是增加軟件的復用能力,無論是該技術本身還是由該技術衍生出來的產物,但如果不考慮復用,應用到具體的場景時效果都會打折,所以不能只用具體的場景去評估通用技術的價值.

再拿前面的 Ansible 為例,Ansible 本身是一個服務器配置管理工具,它的目標是讓服務器的配置變更代碼化(Configuration management Infrastructure as Code),然后讓應用的安裝以及配置的能力組件化,它稱之為 Playbook,然后可以共享復用.

所以你可以在網上搜索到各種 Ansible 的 Playbook,比如數據庫集群的安裝配置等. 它為了實現這個目標,抽象了一套配置語法,通過聲明式的配置來定義服務器上的基礎設施狀態,也一定程度上屏蔽了操作系統細節(實在屏蔽不了的,也可以通過簡單的配置規則來適配),同時做了變量和配置的分離,避免和具體的環境的耦合.

也就是說,只有能接受它的核心思想 —— 服務器基礎設施變更代碼化,然后考慮到復用價值,復用別人的 Playbook 或者將自己的 Playbook 復用到更多的項目或者團隊,Ansible 的價值才會體現出來. 比如前面爭論的那個案例,如果考慮到以后會有更復雜的操作系統環境,可能有更多的,更復雜的項目需要管理,避免運維手動操作引入不預期的變更,導致無法追蹤,才值得引入 Ansible.

所以,不要僅僅從自己當前的業務需求來斷定一個通用技術的價值,比如該文章的標題如果改成《我們當前的數據庫不適合 Docker 以及容器化的 7 大原因》,爭議就小很多.看一個文章要搞清楚它是在做具體的選型分析還是通用的價值判斷.

數據庫容器化的目標和價值

我們再從數據庫容器化這個場景分析一下.

當前我們開發出的任何軟件,到用戶部署運行變成一個服務,之間是有巨大的鴻溝的. 比如以數據庫(MySQL/PostgreSQL)為例,廠商交付給用戶的是一個安裝包,而用戶期望得到的是一個主從的數據庫集群,能支持故障主從切換,自動遷移恢復,自動備份,還要能監控報警,當然要是有個 Dashboard 來通過界面操作,實現自動升級,就更好了,更復雜的需求可能還需要支持讀寫分離和自動數據庫切分. 可以看出,二者之間是有巨大的鴻溝的,而這個鴻溝當前是靠用戶的運維人員來填充的.

運維人員如何填充呢?

先從網上找到一些技術資料,怎么做 MySQL 主從復制,怎么做高可用(keepalived,虛IP等),怎么做雙主,怎么通過代理做讀寫分離,然后將這些組件用腳本粘結起來,部署到服務器上. 當然這還是運維實例比較強的,如果運維實力不夠(大多數創業公司不可能在這種基礎設施上投入研發精力的)可能連主從和備份都做不好,即便是自己用腳本寫了一些簡單的工具,由于測試不夠充分,環境異常考慮不周,正式用的時候可能就出錯了,比如前一段時間的 gitlab 刪庫事件.

簡單回顧下 gitlab 事件,本來單節點的數據刪除是不應該影響整個集群的,但因為從庫數據同步不完備(所以可以推斷從庫應該是沒有啟用過,沒有做讀寫分離),不能直接升級從庫為主庫,而其他的多種備份工具都沒生效.

這大概是大多數公司的現狀,有一些基礎設施工具,但基本都是和環境耦合的腳本,也正如《7 文》中所說,數據庫等基礎服務部署后很少需要去做變動,并且隨著數據越來越多,越來越不敢動,每次變更,比如升級等,就是一個復雜的工程,差不多要發起一場戰役,但一旦出現預期外的故障,就缺少必要的工具和經驗去應對. 那如何避免這種問題呢?左耳朵耗子的文章《從 GITLAB 誤刪除數據庫想到的》提出了一個建議：「設計出一個高可用的系統,通過自動化的方式去處理問題」.

但是這個基礎設施的自動化高可用系統,有那么容易設計么?一方面大多數公司受限于研發實力,沒時間和精力做這種系統,另外一方面即便是有研發實力,這種系統并不能直接產生價值,如何得到高層的支持?能得到多大資源支持?那數據庫廠商或者其他商業公司能否提供這樣一個數據庫服務,再或者能否通過開源項目打造出一個數據庫服務,用戶可以一鍵部署呢?這樣就能將各公司的運維經驗沉淀成具體的工具和組件,而不是像現在,運維經驗的沉淀和傳播基本都只能通過技術分享或者人員流動,這對業界是一種很大的浪費.

那我們設想一下,如果要做前面描述的這樣一個系統,都需要什么條件.首先,得有一種應用的安裝包的環境無關的封裝,如果要適配不同的操作系統,辦理不同的環境異構問題,就很難了. 其次,基礎環境可編程化,可以在程序中實現網絡,存儲等環境的動態適配.再次,要有一個調度層,可以做動態遷移.最后,需要一個編排文件來定義各種組件,以及一種打包格式,將多個組件封裝到同一個包中做分發.

Ansible/Puppet 等配置管理工具一直想做這個事情,并想封裝成可復用的組件,可惜由于基礎設施的環境不統一,不可編程化,而配置管理工具只能一定程度辦理部署時的復雜性,應對不了動態的故障,基本很難達到這個目標.

IaaS 云實現了基礎設施的標準化,可編程化,可動態調度.所以現在 IaaS 云基本都有 RDS(Relational Database Service),功能和前面的描述的用戶需求非常類似.但 IaaS 的問題是當前 IaaS 的 API 基本都是指令式的,是面向資源的,不是面向應用的,第三方很難通過這種 API 來調度應用,所以這種服務第三方很難實現,基本都是云廠商自己定制(IaaS 上也有鏡像市場,但只能是單個鏡像的應用,不能實現復雜的應用),同時 IaaS 的鏡像都是 VM,很難實現跨云的分發.

Docker 的鏡像,幾乎完美實現了前面提到的安裝包的環境無關的封裝,也就是大家說的集裝箱能力,又通過鏡像倉庫提供了分發機制.上面封裝一層編排調度系統(Swarm,Kubernetes,Mesos),再加上標準化的網絡和存儲,于是基本達到了我們上面所描述的條件.

容器平臺的最終目標其實是屏蔽分布式系統的資源管理細節,提供分布式應用的標準運行環境,同時定義一種分布式應用的 package,對開發者來說降低分布式系統的開發成本,對用戶來說降低分布式應用的維護成本,對廠商來說降低分布式應用的分發成本,也就是 DataCenter OS 或 Distributed OS,可簡稱 DCOS.

也就是說,僅僅把數據庫弄成容器鏡像,這僅僅是第一步,是為了后面的目的服務的.有了這一步,才有可能依托容器編排調度系統封裝更高級的通用服務.

有了這種能力后,運維的經驗就可以沉淀成代碼,積累成具體的工具和服務.軟件的價值在于復用,可復用的頻次越高范圍越廣,產生的價值越大,越值得投入.比如 RDS 這種服務,研發本身的復雜度本來不高,關鍵在對各種異常情況的處理方案的經驗積累. 一個公司遇到的異常狀況肯定有限,只有放在社區中逐漸積累改進才會逐漸完備.

IaaS 云的 RDS 的優勢其實也是這一點,積累了云上的各種用戶的各種使用場景和異常處理經驗,無論是業務增長還是錯誤使用帶來的異常.前兩天 Instapaper 由于 MySQL 數據文件過大、達到 ext3 的 2TB 文件大小限制,而導致其數據庫故障,業務中斷 31 個小時,用的就是 AWS 上的 RDS . 雖然使用 RDS 并不能避免故障,但經過這次故障之后,AWS 肯定會改進 RDS, 將這種故障的應對經驗沉淀到產品中去,其他用戶就可以避免再次踩坑了.

當然還會有人問,我們當前沒有任何精力做更高級的封裝,只是把數據庫簡單的用容器鏡像跑起來,還有意義么?

也正如我在 《容文》中說的,對容器技術可以做漸進式的接納,第一步先當做安裝包使用,第二步考慮隔離,引入網絡辦理混合部署帶來的網絡沖突,第三步再考慮調度編排系統.

《7 文》中也承認了容器在開發測試環境中的意義,既然開發測試環境中可以接納容器,保持環境的一致性不更好么?我在文章《基礎設施服務的微服務化》中分析了為什么應該將基礎服務也作為微服務的組件,一體化管理.

只有將數據庫等基礎設施作為微服務的一個組件,和業務應用的微服務互相可以感知,才能實現最終意義上的全自動化.

當然,只是有了標準化的運行環境,并不一定能帶來豐富的應用,還得依賴商業模式.這種基礎設施服務原來的商業模式基本只能是 on-premise 私有部署模式,銷售和實施成本非常高. 企業應用領域是否可能出現一個類似于 Apple 的 AppStore 的市場來降低銷售和實施成本? 這方面很多廠商都在嘗試,各容器平臺都在嘗試推出自己的應用規范,IaaS 廠商也在考慮提供聲明式的編排 API,讓渡出基礎設施服務,由第三方實現,比如 QingCloud 已經發布的 AppCenter.

如果這個商業模式成熟,不僅獨立的基礎設施服務以及中間件公司會涌現出來,同時各公司的基礎研發部門可能會從原來的支撐部門,變為 2B 業務的營收部門.

引入容器帶來的技術成本和風險

引入任何技術都會帶來技術成本和風險,當然容器也不例外.但成本和風險是可以評估的.

1. 平安 經常有人拿容器和虛擬機的平安做比較,然后說明容器的平安有問題. 但實際上,大多數場景下容器并不是用來替代虛擬機的.如果用戶只是用容器來封裝原來直接運行在宿主機上的服務進程,那平安系數是增加了呢還是降低了?肯定是增加了啊,因為容器多了一層基于 cgroup 和 namespace 的隔離,最差的情況是這層隔離沒有生效,那也和進程直接運行在宿主機上的平安效果一樣.

   容器也并沒有額外對外暴露端口等增加網絡接觸面,如果不是將容器直接暴露出去讓第三方用戶當虛擬機一樣部署應用程序,容器并沒有額外增加平安性問題.

2. IO 性能影響 容器默認情況下一般都不會對 IO 進行限制,并且經過很多測試,基本上容器中的 IO 和宿主機基本沒有差距,影響甚微,基本可以忽略.至于 《7 文》中所說的丟數據的影響,明顯是一個錯誤的表述,Docker 中持久化數據,一般是通過 volume 或者和宿主機目錄映射,并不會直接直接寫到鏡像的 AUFS 上.

3. 網絡性能影響 首先不確定《7 文》中所說的 Docker 1.9 版本中依然存在的網絡問題是什么問題,該文也沒給出 issue 鏈接.即便是容器的網絡方案不成熟, 但 Docker 的網絡標準 libnetwork 以及 Kubernetes 的容器網絡標準 CNI,都是插件式的,用戶可以選擇更成熟的.

   如果服務已經運行在云上,容器一般都是可以復用云的 SDN 來實現網絡的,比如 AWS 上的基于 VPC 路由的容器網絡方案,QingCloud 上的 SDN 網絡直通(SDN Passthrough)方案,和直接使用宿主機網絡效果差距很小或者基本一樣.再退一步說,如果網絡性能真那么重要,并且一臺服務器只運行一個服務,那可以直接用 host 模式么.

4. 成本 容器的接納成本已經非常小了,即便是復雜一些的 Kubernetes,相對于 OpenStack 也簡單許多,所以才有人通過 Kubernetes 去部署 OpenStack .所以說,容器引入的成本和風險相對于收益來說,絕對是可以接受的,即便是它現在存在著許多問題,但絕對是一個潛力股,值得投入.

總結下,對技術的接納很多情況下其實是純粹的觀念問題.最初 IaaS 出來的時候,不也有很多人說,數據庫服務不適合跑在虛擬機上了,大數據服務不適合跑在虛擬機上了,現在不也有很多用戶用的很好.

合適不合適,脫離具體的業務場景和需求,是說不清楚的,對于大多數用戶和產品來說,數據庫的易用性,易維護性,可用性,要大于性能等其他方面的要求的,對另外一部分用戶來說,數據庫肯定要跑到物理機上,甚至 PC 服務器都不能滿足.

所以還是不要僅僅從自己的當前的業務需求來斷定一個技術通用價值.技術人喜歡僅僅從自己的角度去進行價值判斷,我個人也是這樣.最近也在反思,技術人要突破,無論是創業,還是設計對客戶有價值的產品,都需要把視角放寬一些,謹以此文與各位共勉.

• http://coolshell.cn/articles/17680.html 《從 GITLAB 誤刪除數據庫想到的》

• http://jolestar.com/infrastructure-service-as-microservice/ 《基礎設施服務的微服務化》

如果你也想像其他 80,000 + 用戶一樣,嘗試在公有云上部署 Docker 方案,不妨在 QingCloud 控制臺上試用這項 SDN 網絡直通服務,它可以贊助你大幅提升 Docker 性能及網絡配置易用性.SDN 網絡直通的所有組件及功能均不計費.