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