云世界里的技術(shù)日新月異，新名詞一個接著一個讓人應(yīng)接不暇，從虛擬化開始，VMware、HyperV、KVM，到云管理平臺VSphere、SystemCenter、OpenStack，再到容器領(lǐng)域的Docker、Kubernetes、Mesos、Swarm，資源管理調(diào)度的Yarn、Mesos和今天的微服務(wù)Micro Service。這些東東到底是干嘛的？能解決什么問題？它們之間有木有關(guān)聯(lián)性？作為多年來運營商IT的一名架構(gòu)師，筆者試著從自己的角度解讀下云技術(shù)的演進與實踐。目的不是論證各項技術(shù)，而是想把一些碎片化的知識串接起來，讓大家知道來龍去脈，在有必要的時候做出選擇或去深度研究。
1. 虛擬化與X86
最早有硬件服務(wù)器（Server）和軟件應(yīng)用（Application），兩者之間夾了個操作系統(tǒng)（OS），讓應(yīng)用程序可以通過它來使用CPU、內(nèi)存和存儲等。從定位來看叫它系統(tǒng)軟件更加貼切，以區(qū)別于應(yīng)用軟件。
慢慢硬件和OS就綁在一起了，IBM的Aix，HP的HP-UX，Sun的Solaris；微軟是個例外，可在不同的PC服務(wù)器上跑Windows。這種局面鬧得應(yīng)用也不得不選擇自己的營地，一旦落定后要想再遷移可得費老鼻子勁了，用戶要花錢花力冒風(fēng)險，廠家賺的盆滿缽溢的。
后來基于統(tǒng)一X86架構(gòu)的PC服務(wù)器越做越好，價格便宜而且有多家產(chǎn)品可選擇，再加上出了個開源的OS，Linux，在上面開發(fā)應(yīng)用讓您隨時可以更換底層的機器，這一局面大大降低了硬件成本。呼啦一下新應(yīng)用都在X86上開發(fā)了，有些企業(yè)甚至下了行政命令不許再買小機了。幾家硬件巨頭也只好隨風(fēng)跟進，但時間一長，利潤空間越擠越小，Sun出局了（賣給Oracle了），IBM把X86產(chǎn)品線轉(zhuǎn)給聯(lián)想了，只有HP還在那兒苦苦地撐著，X86產(chǎn)品線在中國也和紫光合并了。
不過X86在體量和性能上都不如Unix小機，那它怎么能承受的住原來小機上的那些負載呢？工程師們總是有法子的，單機負載不是太大嗎？我干脆弄個業(yè)務(wù)組網(wǎng)，把應(yīng)用在每臺X86上都裝一份，然后在前端放個LB（負載均衡器），把原來一臺機器上的負載分配到不同的機器上，把負載給均衡了。
您要是專家立馬會問那數(shù)據(jù)怎么辦？應(yīng)用程序要是太大了太重了怎么辦？為了好保證數(shù)據(jù)一致性，數(shù)據(jù)還得放在同一個庫里，所以在一堆X86后面往往都有臺仍舊是小機的數(shù)據(jù)庫服務(wù)器（它也由此成了瓶頸，后面咱們再說怎么解決它，怎么徹底做到去IOE）。應(yīng)用太大了啟動起來費半天勁怎么辦？還是化整為零的辦法，用了個一般人看了后懵懵的名字叫“應(yīng)用服務(wù)化”或“容器化”，后面我們也會談到。
人們追求效率追求成本的努力永不間斷。在實際生產(chǎn)中X86的使用率并不高，只有10%左右。剛剛在X86上落定的IT人又再琢磨能不能再優(yōu)化些，讓一臺X86當(dāng)多臺機器使用？虛擬化應(yīng)運而生。
虛擬化是個啥玩意兒？說白了就是夾在硬件和OS之間一個叫做Hypervisor的東西。它可以把一臺物理機里的CPU、內(nèi)存、硬盤存儲都抓過來，化整為零重新分配給一個個叫做虛機的“小盒子”。這個概念其實在小機上就存在。每個小盒子具備了一定的硬件資源后，再給它裝個OS它就能像臺真正的機器一樣給應(yīng)用使用。那個Hypervisor就像個監(jiān)工，哪個小盒子里的資源要是不夠用了，它就動態(tài)地多給一些。這是件多好的事兒呀！再加上一幫專門忽悠人的老美給它取了個云里霧里的名字叫“云計算”，弄了個像供水電一樣的銷售使用模式，這家伙X86+虛擬化一下子就火起來了，風(fēng)靡了全世界。
2. 云化資源管理
這小盒子一多，多到能有成千上萬個，這時候云管理平臺就出來了，它要管理的主要對象是虛機集群。這時候知道點云計算的您肯定會舉手說OpenStack。
哈哈，您先別急，聽我慢慢道來。剛剛從Unix小機解放出來的用戶試著走進虛擬世界，但很快發(fā)現(xiàn)又有被廠家綁定的危險。虛擬軟件的老大VMware自打推出它的Hypervisor之后，很快又推出了它的管理平臺VSphere；另一大佬微軟比VMware胃口還大，從操作系統(tǒng)Windows、到虛擬軟件HyperV，當(dāng)然忘不了它的管理平臺SystemCenter。昂貴的軟件使用費逼的用戶又一次轉(zhuǎn)向開源社區(qū)。一下子虛擬化管理領(lǐng)域熱鬧非凡，混戰(zhàn)到最后剩下的有Eucalyptus（國內(nèi)叫桉樹）、CloudStack和OpenStack幾家了。
關(guān)于他們的優(yōu)劣和成敗原因的分析，已有很多。三者中，Eucalyptus出身最學(xué)術(shù)，CloudStack出身商業(yè)味最濃，OpenStack介于兩者之間。CloudStack 和Eucalyptus一樣，最開始并不開源，開源后還留了點尾巴，而且自己控制著商業(yè)版本。等發(fā)現(xiàn)這種模式玩不轉(zhuǎn)了，賣給了Citrix，全部開源后，發(fā)現(xiàn)大家已經(jīng)都在玩OpenStack了。其實OpenStack發(fā)布后直到CloudStack被Citrix再轉(zhuǎn)賣出去為止，它的易用性和穩(wěn)定性一直和CloudStack有差距。但是架不住OpenStack免費、完全開源、沒有商業(yè)公司控制。咳，人都貪便宜，不想被束縛。
按道理OpenStack只是個虛機管理工具，可是一旦一家獨大之后人們對它的期望也就越來越高，就集萬千寵愛于一身。存儲要管（Cinder、Swift），網(wǎng)絡(luò)SDN也要管（Neutron）；虛機要管（Nova、Glance），物理機也要管（Ironic），鬧不好連遺留下來的小機也得一并納入；光是硬件資源還不過癮，中間件、大數(shù)據(jù)（Sahara) 等也都要攏過來。資源種類多了，資源之間的編排(Heat) 也越做越復(fù)雜。以前只是管理和集成，現(xiàn)在要深入到更底層的資源了，還要考慮收費計價（Ceilometer）。競爭對手一個個倒下，看似勢頭無敵的時候，也就是最危險的時候。這危險一是來自內(nèi)部，要做那么些功能開源社區(qū)跟不上趟了，開發(fā)落后于需求，用戶不得不自己找一幫高手來開發(fā)；二是來自外部，來自它所需要管理的對象：虛機。
3. 容器時代的到來
大家還記得虛機是什么吧！虛機就是物理機上的一個個“盒子”，盒子里裝著OS，OS之上是各自的應(yīng)用。問題就出在這OS上。因為操作系統(tǒng)本身就是一個軟件程序，一個很重的系統(tǒng)軟件因為它包含了形形色色的各類功能。好多功能應(yīng)用根本就用不上，譬如Web服務(wù)器負責(zé)處理網(wǎng)絡(luò)請求，數(shù)據(jù)庫服務(wù)器負責(zé)數(shù)據(jù)庫的運行和數(shù)據(jù)庫訪問，等等。這些服務(wù)器可能永遠都用不上OS中顯示器、多用戶、多進程等功能。這些場景下的虛機和OS的任務(wù)很明確，就是提供最好的存儲、計算、網(wǎng)絡(luò)性能。但是OS并沒有隨著虛擬化而重建，大而全的OS功能越多重啟它耗費的時間就越長，也因此拖累了虛機。
這時候兩大改造運動開始了，一個是把OS搬到“盒子”外面讓大家共享，一個是把OS做輕，去掉那些無用的功能。剩下的“盒子”就是當(dāng)紅子雞 “Docker” 或容器（其實這兩種技術(shù)改造路線是相輔相成的）。做輕量級OS比較有名的兩個代表（一看公司的名字就知道干嘛的了）一個叫CoreOS，另一個叫Unikernel。最初CoreOS是一家容器化Linux服務(wù)器操作系統(tǒng)創(chuàng)業(yè)公司，同時，該公司使用自家的Linux系統(tǒng)CoreOS為Docker提供服務(wù)，并為Docker作出了巨大的貢獻。令人出乎意料的是CoreOS卻與Docker分道揚鑣，另起爐灶，并開發(fā)了類Docker的開源容器Rocket。后來在Linux基金會的調(diào)解下，這兩家公司互讓一步，聯(lián)手打造開放容器技術(shù)項目（OCP）。OCP是一個非營利性組織，它實際上采用了Docker的技術(shù)作為開源容器的軟件技術(shù)標(biāo)準(zhǔn)。既然開源了，CoreOS也就放了Docker一馬。做輕OS的另一個廠家Unikernel后來干脆被Docker收購了。自此，Docker成了容器的代名詞。
4. 容器集群管理
Docker被應(yīng)用接受了，逐漸推廣了，問題也出來了。問題一是和虛機管理平臺一樣，容器一多管理上成了問題啦，需要個容器集群管理系統(tǒng)。問題二是容器是輕量級的，用它來承載大塊頭的應(yīng)用是不適合的。容器集群管理系統(tǒng)里出了Mesos、Kubernetes和Swarm，這里面谷歌開源出來的Kubernetes被業(yè)界公認為是目前最好的工具，但Mesos對集群資源調(diào)度及跨集群任務(wù)執(zhí)行有自己的特長而Swarm是Docker公司自己出的Docker管理工具。
Kubernetes是谷歌開源的容器集群管理系統(tǒng)（可以認為是谷歌輸給Docker容器之戰(zhàn)后采用的另一種戰(zhàn)略體現(xiàn)），為封裝應(yīng)用的容器提供資源調(diào)度、部署運行、服務(wù)發(fā)現(xiàn)、擴容縮容等一整套功能。Kubernetes不光光是簡單地對Docker的整個生命周期進行管理，它更像個DevOps的PaaS平臺，面向應(yīng)用開發(fā)者提供開發(fā)、測試和運行Docker的環(huán)境；它對外提供的是RESTful的API端口，每個端口對應(yīng)的是封裝了應(yīng)用的Docker或Docker組合（POD），是將POD打了標(biāo)簽后的服務(wù)（Service），或是POD的復(fù)制。因為分布式應(yīng)用出于性能或高可用性的考慮，需要復(fù)制多份資源，并且根據(jù)負載情況動態(tài)伸縮。
相比于Kubernetes，Mesos根本提不上對Docker有什么管理功能。Kubernetes所有的如服務(wù)注冊、發(fā)現(xiàn)，對外提供RESTful接口等PaaS功能都需要由Mesos之外的一個叫Marathon的組件來完成。Mesos本身更注重對底層資源的調(diào)度，把每臺機器上的CPU、內(nèi)存、存儲聚在一起提供給上層的應(yīng)用框架使用。每個框架會根據(jù)分配到的資源再細分到各個任務(wù)或容器上。如果要拿蘋果比蘋果的話，應(yīng)該拿Kubernetes和Mesos+Marathon來比較。
5. 集群資源管理與調(diào)度
說到這兒有必要把集群資源管理調(diào)度搞搞清楚。容器也好，虛機也好，怎樣根據(jù)底層可使用的物理資源的多少來把它們分配給容器或虛機使用？這就是調(diào)度或動態(tài)調(diào)度。OpenStack 做不好這事，它不能在虛機和資源之間進行調(diào)度（VMware的VSphere可以，它有個DRS功能）。Mesos可以，它可以在計算框架和資源之間進行調(diào)度；如果計算框架自身具備面向框架內(nèi)任務(wù)的細顆粒度資源調(diào)度，而這些任務(wù)又是用容器來承載的，那么我們也可以認為Mesos可以在容器與資源之間進行調(diào)度（兩級調(diào)度）。
這種調(diào)度的目的就是要提高設(shè)備資源的使用率。譬如當(dāng)你的大數(shù)據(jù)平臺已不再是唯一的Hadoop集群，其它的數(shù)據(jù)處理框架如Spark、Storm、Kafka等也需要組成集群要你來運行時，你肯定會考慮到資源利用率，運維成本，數(shù)據(jù)共享等因素。企業(yè)一般都希望將所有這些框架部署到一個公共的集群中，讓它們共享集群的資源，并對資源進行統(tǒng)一使用，這樣，便誕生了資源統(tǒng)一管理與調(diào)度平臺，其中典型代表就是Mesos和Hadoop生態(tài)體系內(nèi)的Yarn。
首先，資源統(tǒng)一管理和調(diào)度平臺應(yīng)該提供一個全局跨域的資源管理器。所有接入的框架要先向該資源管理器申請資源，申請成功之后，再由框架自身的調(diào)度器決定將分配到的資源交由哪個任務(wù)使用；也就是說，整個大的系統(tǒng)是個雙層調(diào)度器，第一層是統(tǒng)一管理和調(diào)度平臺，另一層是框架自身的調(diào)度器。
弄清了這一點也就弄清了Mesos和Yarn的各自定位。Mesos是第一層的資源統(tǒng)一管理與調(diào)度，它所覆蓋的框架集群有大數(shù)據(jù)類的（Yarn所能支撐的）和非大數(shù)據(jù)類的（Yarn不能支撐的）。第二層是計算框架自帶的調(diào)度器如Yarn（或Kubernetes等），對分配到的資源進行再次分配；也就是說，Mesos將大部分調(diào)度任務(wù)授權(quán)給了計算框架。總結(jié)來說，Mesos首先完成粗粒度的資源分配，即：將資源分配給框架，然后由框架進行細粒度的資源分配；而Yarn進行細粒度的分配，即:將資源分配給某個任務(wù)。
Yarn和Mesos是否單獨執(zhí)行資源調(diào)度還沒有到下定論的時候，雙方也都還在繼續(xù)演進當(dāng)中，以支持越來越多的框架。好在Mesos不僅僅是做大數(shù)據(jù)分布式計算的框架，所以Mesos往往被稱為數(shù)據(jù)中心操作系統(tǒng)，DCOS，是軟件定義數(shù)據(jù)中心的利器。為了讓兩者能夠更好地整合在一起，發(fā)揮各自的作用，業(yè)界試著用一個叫Myriad的組件來做Y2M或M2Y。不過Myriad的穩(wěn)定性還有待驗證，目前還不能用它來做生產(chǎn)組網(wǎng)。在過渡時期，我們可能不得不考慮由Mesos和Yarn分別組網(wǎng)的情況。
至此，我們可以大致勾勒出來新一代云平臺的邊際圖：
- 底層是各類硬件資源，以X86物理機為主，混搭著虛機、小型機、SAN存儲、SDS存儲、SDN網(wǎng)絡(luò)等。
- 這些資源統(tǒng)一由OpenStack（或其它云管理軟件）云平臺來負責(zé)管理，管理內(nèi)容包括自動化部署（OS、虛擬軟件等）、可視化監(jiān)控、IaaS多租戶管理、資源組件目錄、用戶門戶等。
- 在這些資源之上我們可以部署Mesos，用它來匯聚底層資源（CPU、內(nèi)存、存儲）并根據(jù)需求動態(tài)提供給上層的框架（Kubernetes、Hadoop、Spark、Storm、Kafka、MySQL、Redis等）。
- 這些框架如帶有自身的資源調(diào)度器，可將分配到的資源二次細分到各自的任務(wù)或容器中。
6. 應(yīng)用的服務(wù)化與微服務(wù)化
在前面談到容器是輕量級的，用它來承載大塊頭的應(yīng)用是不適合的。所以要想通過容器來運行應(yīng)用必須要對應(yīng)用進行劃小處理。這要比應(yīng)用遷移至X86上，數(shù)據(jù)庫能不能在虛機上跑之類的云化改造來的更動筋骨一些。傳統(tǒng)的企業(yè)級應(yīng)用是單體應(yīng)用（monolithic application），比如運營商的系統(tǒng)，業(yè)務(wù)非常復(fù)雜，這種巨型系統(tǒng)，首先要關(guān)注的是如何根據(jù)業(yè)務(wù)劃分子系統(tǒng)。這種劃分是一種垂直切分，十幾年前開始風(fēng)行的SOA（Service Oriented Architecture）就是基于這種垂直劃分后的子系統(tǒng)的。在SOA體系里，每個子系統(tǒng)都是獨立的服務(wù)（Service），通過服務(wù)接口與外部協(xié)作。既然有垂直切分就得有水平切分。傳統(tǒng)的企業(yè)級應(yīng)用一般是分層結(jié)構(gòu)，如表現(xiàn)層、應(yīng)用層和數(shù)據(jù)層。如果將垂直切分后的子系統(tǒng)按三層架構(gòu)來設(shè)計，我們會得到更細一步的“服務(wù)”。這種橫豎切割的過程也叫做服務(wù)化過程。SOA還同時提供了調(diào)用服務(wù)的接口協(xié)議，XML和WS（Web Service），提供服務(wù)之間的通信與整合樞紐：企業(yè)服務(wù)總線（ESB），服務(wù)編排所需要的業(yè)務(wù)規(guī)則流程引擎（BPM）等。
按照 SOA 這種思想和架構(gòu)原則來改造應(yīng)用無疑相當(dāng)于推翻重新開發(fā)一遍，在成本上很難接受而且工作過于復(fù)雜。 因此大部分企業(yè)實踐SOA的思路不是劃小應(yīng)用，而是做不同應(yīng)用系統(tǒng)間的松耦合集成，讓系統(tǒng)與系統(tǒng)之間通過服務(wù)接口（Service API）和企業(yè)服務(wù)總線（ESB）進行交互。
應(yīng)用沒有被劃小，傳統(tǒng)的復(fù)雜應(yīng)用只是通過API將其功能和數(shù)據(jù)進行了開放，但還裝不進輕量級的容器Docker中。實際上應(yīng)用服務(wù)化的目的不是為了使用容器，而是想解決三大問題：一是應(yīng)用的維護問題，二是應(yīng)用的開發(fā)問題，三是應(yīng)用的部署問題。
一個簡單的應(yīng)用會隨著時間推移逐漸變大。幾年后，一個小而簡單的應(yīng)用因為改來改去會變成一個龐然大物。一旦你的應(yīng)用變成一個龐大而又復(fù)雜的怪物，維護開發(fā)團隊肯定會很痛苦。敏捷開發(fā)和快速部署舉步維艱，其中最主要的問題就是這個應(yīng)用太復(fù)雜，以至于任何一個程序員都不可能搞懂它。因此，修正bug和添加新功能會變得非常困難，并且很耗時。
我們所要尋求的是加快開發(fā)速度和減少變更代價。怎樣才能加快開發(fā)速度呢？如果我們的開發(fā)不是重造輪子，而是每一次做新產(chǎn)品都可以利用已有的東西，那就會好很多。怎樣才能減少變更代價呢？如果我們能夠理清功能模塊之間的關(guān)系，合理分層，每次變更只需要修改其中某個部分，甚至不需要修改代碼，僅僅是改變參數(shù)配置就可以了。 我們先不看軟件行業(yè)，來看一下建筑行業(yè)，他們是怎么蓋樓房的呢？施工之前先設(shè)計，把整個樓房分解為不同預(yù)制件，比如鋼筋混凝土的樓板、門窗、石膏隔斷墻等，分別在各地生產(chǎn)，最后在現(xiàn)場組裝，所以整個搭建過程非常快。之后的維修也是那塊壞了，換那塊，不用一動就上下一大串、左右一大片。
除去開發(fā)和維護方面的問題之外，我們還要解決的是應(yīng)用部署問題。誰沒聽說過由于程序員登錄生產(chǎn)現(xiàn)場誤操作導(dǎo)致整個應(yīng)用癱瘓，長期無法訪問的現(xiàn)象？這些現(xiàn)象反映了很多企業(yè)的應(yīng)用部署還是停留在“大鍋飯”階段。所謂的大鍋飯就是包含眾多功能的應(yīng)用軟件被部署到生產(chǎn)環(huán)境時，基本都是以文件的型式打成一個大軟件包，然后被部署到一個應(yīng)用服務(wù)器上，如WebLogic、Tomcat等（也可以把這些應(yīng)用服務(wù)器看成個大容器）。應(yīng)用服務(wù)器可以提供很多基礎(chǔ)服務(wù)比如HTTP服務(wù)器，服務(wù)目錄或共享庫包等。問題出在同一個應(yīng)用服務(wù)器會接受好幾個不同應(yīng)用的部署，使得在擴展性、維護性和資源使用上會有很多磕磕絆絆、互相牽連的事情發(fā)生。比如當(dāng)你改動或新添一個功能后，你需要重新部署你的軟件到應(yīng)用服務(wù)器上，要重新啟動你的應(yīng)用服務(wù)器。裝滿沉重應(yīng)用的它需要很長時間來啟動；如果可憐的你因為趕活兒沒仔細測試你修改后的軟件，應(yīng)用服務(wù)器啟動不了或啟動一段時間后又趴下了，那你造成的影響不光光是你自己的應(yīng)用而且連累了應(yīng)用服務(wù)器上所有其它的應(yīng)用。我敢保證攤上這事兒的你，死的心都有了！
這時候不用我說，你大概也明白了為什么我們要把一個復(fù)雜的應(yīng)用服務(wù)化了，也就是說劃小了。
劃小后的應(yīng)用成了一項項服務(wù)（Service），用Docker容器把每個單項服務(wù)和它運行所需要的基礎(chǔ)軟件環(huán)境封裝在一起，單獨地部署，直接運行在標(biāo)準(zhǔn)的X86硬件資源之上。如果你劃小后的應(yīng)用出了問題，影響范圍也只限于它而已。你想增添個新功能，你就加一項容器服務(wù)，無需牽一發(fā)而動全身。某項服務(wù)使用頻次高了，不夠用了，你就把它的容器多復(fù)制幾份，前面加個負載均衡機制就解決了系統(tǒng)的容量問題、高并發(fā)問題。
這時的我已經(jīng)不用再過多跟您解釋什么是“微服務(wù)”了。微服務(wù)定義：采用一組服務(wù)的方式來構(gòu)建一個應(yīng)用，服務(wù)獨立部署在不同的進程中，不同服務(wù)通過一些輕量級交互機制來通信，例如 RPC、HTTP（也就是REST） 等，服務(wù)可獨立擴展伸縮，每個服務(wù)定義了明確的邊界，不同的服務(wù)甚至可以采用不同的編程語言來實現(xiàn)，由獨立的團隊來維護。
微服務(wù)與SOA有很多相同之處。兩者都屬于典型的、包含松耦合分布式服務(wù)的系統(tǒng)結(jié)構(gòu)。但是兩種架構(gòu)背后的意圖是不同的：SOA嘗試將應(yīng)用集成，一般采用中央管理模式（ESB模式）來確保各應(yīng)用能夠交互運作。微服務(wù)嘗試部署新功能，快速有效地擴展開發(fā)團隊。它著重于分散管理、代碼再利用與自動化執(zhí)行。
7. 分布式數(shù)據(jù)庫
應(yīng)用服務(wù)化了，采用了分布式架構(gòu)被部署在X86服務(wù)器上了?？蓴?shù)據(jù)呢？前面說過三層架構(gòu)的應(yīng)用展現(xiàn)層和業(yè)務(wù)邏輯層都可以做云化改造，唯獨后端的數(shù)據(jù)層還因為數(shù)據(jù)一致性的問題停留在小型機上，成為了瓶頸（訪問量大、擴展性差）。企業(yè)的核心數(shù)據(jù)庫系統(tǒng)一般都采用“小型機＋高端商用數(shù)據(jù)庫＋高端存儲陣列”的集中式架構(gòu)，也就是我們常說的IOE（IBM的小機、Oracle的數(shù)據(jù)庫、EMC的存儲）。這些設(shè)備價格昂貴不說，主要問題還是在于它只允許縱向（Scale-in)而不是橫向擴展（Scale-out)。縱向擴展的意思就是在機器內(nèi)加配置，加CPU，加內(nèi)存，加硬盤，加到最后就加不了了；而橫向擴展則能讓您加機器，加節(jié)點；一臺不夠，兩臺，兩臺不夠十臺、百臺、千臺，形成了集群，形成了我們所說的分布式架構(gòu)。這后種形式的擴展優(yōu)越性不言而喻。那您肯定會說應(yīng)用都劃小了，怎么不把數(shù)據(jù)庫也分了得了？
和應(yīng)用切分一樣，我們也可以對數(shù)據(jù)庫通過一系列垂直和水平切分將數(shù)據(jù)分布到不同的DB服務(wù)器上，然后通過路由中間件訪問特定的數(shù)據(jù)庫。然而我們面臨的困難首先是網(wǎng)絡(luò)延時問題。因為原來依靠單機內(nèi)部的通信現(xiàn)在要搬到外面來，成了機器與機器之間的通信，系統(tǒng)的開銷一下子因為網(wǎng)絡(luò)通信而增大。這種通信的代價會使系統(tǒng)單次提交的時間延遲。延遲提高會導(dǎo)致數(shù)據(jù)庫鎖定時間變長，使得性能比單機數(shù)據(jù)庫具有明顯差距。
分布式數(shù)據(jù)庫面臨的另一個問題是數(shù)據(jù)一致性問題。一致性就是數(shù)據(jù)保持一致，在分布式系統(tǒng)中，可以理解為多個節(jié)點中數(shù)據(jù)的值是一致的。而一致性又可以分為強一致性與弱一致性。強一致性就是在任意時刻，所有節(jié)點中的數(shù)據(jù)是一樣的。弱一致性又有很多種類型，目前分布式系統(tǒng)中廣泛實現(xiàn)的是最終一致性。所謂最終一致性，就是不保證在任意時刻任意節(jié)點上的同一份數(shù)據(jù)都是相同的，但是隨著時間的遷移，不同節(jié)點上的同一份數(shù)據(jù)總是在向趨同的方向變化。也可以簡單的理解為在一段時間后，節(jié)點間的數(shù)據(jù)會最終達到一致狀態(tài)。
這些問題恰恰是分布式數(shù)據(jù)庫的短板，就像它的可擴展性和可用性優(yōu)點一樣明顯。魚和熊掌不可兼得。根據(jù)著名的CAP理論，在分布式數(shù)據(jù)庫應(yīng)用中，任何分布式系統(tǒng)只可同時滿足CAP其中兩點，無法三者兼顧。
- Consistency(一致性), 數(shù)據(jù)一致更新，所有數(shù)據(jù)變動都是同步的；
- Availability(可用性), 好的響應(yīng)性能，集群中某些節(jié)點宕掉了系統(tǒng)照用；
- Partition tolerance(分區(qū)容錯性) ，可靠性。系統(tǒng)如果不能在時限內(nèi)達成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當(dāng)前操作在C和A之間做出選擇。
CA 系統(tǒng)是要求高可用并且實時一致性。單點數(shù)據(jù)庫是符合這種架構(gòu)的。
AP 滿足可用性，分區(qū)容忍性的系統(tǒng)，通常可能對一致性要求低一些。
CP 系統(tǒng)是要求滿足一致性，分區(qū)容忍性，通常性能不是特別高。
我們不要將精力浪費在如何設(shè)計能滿足三者的完美分布式系統(tǒng)，而是應(yīng)該進行取舍。所以分布式的數(shù)據(jù)庫也應(yīng)該設(shè)計成多樣的。比如將分析類型應(yīng)用所需要的數(shù)據(jù)遷移至以Hadoop為主的分布式NoSQL數(shù)據(jù)庫，將對實時一致性要求不是很高的一些應(yīng)用遷移至分布式MySQL數(shù)據(jù)庫等。這里有必要提一下分布式關(guān)系型數(shù)據(jù)庫中的路由中間件。
數(shù)據(jù)庫中間件對數(shù)據(jù)庫云化改造或?qū)φ麄€IT架構(gòu)的分布式改造起著非常重要的作用，它能提供的典型功能有分庫分表、讀寫分離、負載均衡、Failover 等。
跟阿里數(shù)據(jù)庫產(chǎn)品打過交道的人都知道它里面有個叫“頭都大了”（TDDL，Taobao Distributed Data Layer）的路由代理，用它可以大大簡化前端應(yīng)用與后端數(shù)據(jù)庫的連接，特別是當(dāng)應(yīng)用和數(shù)據(jù)庫都成了分布式的時候，這是種N對N的連接。其實TDDL還并沒有全部開源，近兩年來有個在開源社區(qū)十分火爆的牛X產(chǎn)品叫“我的貓”（MyCat）。MyCat技術(shù)原理是它攔截了應(yīng)用發(fā)送過來的SQL語句做特定分析：如分片分析、路由分析、讀寫分離分析、緩存分析等，然后將此SQL發(fā)往后端的數(shù)據(jù)庫節(jié)點，并將返回的結(jié)果做適當(dāng)?shù)奶幚?，最終再返回給應(yīng)用。MyCat發(fā)展到目前已經(jīng)不再是一個單純的MySQL代理了，它的后端可以支持MySQL、SQL Server、Oracle、DB2、PostgreSQL等主流數(shù)據(jù)庫，也支持MongoDB這種新型NoSQL方式的存儲，未來還會支持更多類型的數(shù)據(jù)庫。
從用戶角度來看，代理中間件提供的就是一個傳統(tǒng)的數(shù)據(jù)庫表，支持標(biāo)準(zhǔn)的SQL語句，對前端業(yè)務(wù)系統(tǒng)來說，可以大幅降低開發(fā)難度，提升開發(fā)速度。對整個IT架構(gòu)來說，因為這個中間件可以擁有一個多種數(shù)據(jù)庫的數(shù)據(jù)服務(wù)，拼在一起可以滿足CAP要求。
8. 結(jié)束語
X86、虛擬化、容器、分布式數(shù)據(jù)庫、微服務(wù)，所有這一切都是為了把我們的IT系統(tǒng)搭建起一個面向服務(wù)的架構(gòu)，一個廣義上的SOA。其實前面把SOA簡單說成是做應(yīng)用系統(tǒng)間的集成有失公允。因為當(dāng)我們開發(fā)一個新應(yīng)用時，也可以按照橫豎切分的原則來設(shè)計服務(wù)的開發(fā)，形成一個個應(yīng)用組件，然后通過ESB開放給開發(fā)團隊使用。我所在的公司前幾年搞過一個叫做uCloud的PaaS項目，其設(shè)計理念就是上述思路的體現(xiàn)。在ESB之下，開發(fā)集成了十幾項技術(shù)服務(wù)和數(shù)據(jù)庫服務(wù)供應(yīng)用方使用，一個典型的SOA架構(gòu)。問題出在在這樣一個部門各自為政、應(yīng)用開發(fā)以第三方廠家為主的公司，如果沒有一個強有力的管理措施要求各方必須使用中央管理的Service API時，結(jié)果自然可以想象。這令我不得不想起一個叫康威的老外定的一條規(guī)律：軟件設(shè)計的架構(gòu)，實際上反應(yīng)了公司的組織與溝通架構(gòu)（Conway’ s law: Organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations.）。
公司的組織與溝通是老板領(lǐng)導(dǎo)意識的最佳表現(xiàn)。所以服務(wù)化的成功與否不光光是中心化的SOA或去中心化的微服務(wù)選擇，更重要的是整個企業(yè)的一種戰(zhàn)略決策。最近微信群里流傳早在2002年，亞馬遜創(chuàng)始人兼CEO貝佐斯就在亞馬遜強制推行了以下六個原則：
所有團隊的程序模塊都要以通過Service Interface 方式將其數(shù)據(jù)與功能開放出來。
團隊間的程序模塊的信息通信，都要通過這些接口。
除此之外沒有其它的通信方式。其它形式一概不允許：不能使用直接鏈結(jié)程序、不能直接讀取其他團隊的數(shù)據(jù)庫、不能使用共享內(nèi)存模式、不能使用別人模塊的后門、等等；唯一允許的通信方式只能是能過調(diào)用 Service Interface。
任何技術(shù)都可以使用。比如：HTTP、Corba、Pubsub、自定義的網(wǎng)絡(luò)協(xié)議、等等，都可以，貝佐斯不管這些。
所有的Service Interface，毫無例外，都必須從骨子里到表面上設(shè)計成能對外界開放的。也就是說，團隊必須做好規(guī)劃與設(shè)計，以便未來把接口開放給全世界的程序員，沒有任何例外。
不這樣的做的人會被炒魷魚。
十幾年后的亞馬遜已經(jīng)從一個購書網(wǎng)站發(fā)展成了全球最大的云公司，恐怕這也是和它的“服務(wù)化”戰(zhàn)略決策分不開的。貝佐斯的六原則展示出高度的遠見和超強的信念，“不謀萬世者，不足謀一時；不謀全局者，不足謀一域。”
從另一方面來看，SOA也好，微服務(wù)也好，虛擬化也好，容器也好，如果形不成一個公司的整體戰(zhàn)略，達到整個生態(tài)系統(tǒng)的共識，那么最好不要大張旗鼓地去搞什么全民皆兵的戰(zhàn)役。其結(jié)果往往以失敗而告終。當(dāng)然謹慎地在自己的部門領(lǐng)域內(nèi)做些新技術(shù)的嘗試性工作也未嘗不可，這種創(chuàng)新精神還是值得鼓勵的。
革命尚未成功，同志仍需努力。
京公網(wǎng)安備 11010502049343號