摘要：分享實(shí)錄云計(jì)算技術(shù)源于互聯(lián)網(wǎng)公司，現(xiàn)在云計(jì)算已經(jīng)是下一代企業(yè)級(jí)的發(fā)展趨勢(shì)。如何做云計(jì)算一直是云計(jì)算技術(shù)的領(lǐng)導(dǎo)者。互聯(lián)網(wǎng)公司的快速發(fā)展，已經(jīng)印證了云計(jì)算技術(shù)和云原生應(yīng)用相比傳統(tǒng)構(gòu)架的巨大優(yōu)勢(shì)。

今天小數(shù)又給大家?guī)?lái)一篇干貨滿滿的分享——來(lái)自KVM社區(qū)線上群分享的實(shí)錄，分享嘉賓是數(shù)人云CEO王璞，題目是《云計(jì)算與 Cloud Native》。這是數(shù)人云在KVM社區(qū)群分享的第一彈，之后還有數(shù)人云CTO肖德時(shí)、COO謝樂(lè)冰的Docker與Mesos的應(yīng)用實(shí)戰(zhàn)經(jīng)驗(yàn)分享，敬請(qǐng)期待！

嘉賓介紹

王璞，數(shù)人云創(chuàng)始人兼CEO
美國(guó) George Mason 大學(xué)計(jì)算機(jī)博士。擅長(zhǎng)分布式計(jì)算、大規(guī)模機(jī)器學(xué)習(xí)、海量數(shù)據(jù)處理。曾擔(dān)任 Google 廣告部門數(shù)據(jù)平臺(tái)構(gòu)架師，負(fù)責(zé)管理每秒訪問(wèn)量全球最高的架構(gòu)平臺(tái)。

分享實(shí)錄

云計(jì)算技術(shù)源于互聯(lián)網(wǎng)公司，現(xiàn)在云計(jì)算已經(jīng)是下一代企業(yè)級(jí)IT的發(fā)展趨勢(shì)。云計(jì)算最大的特點(diǎn)是彈性和靈活，幫助企業(yè)應(yīng)對(duì)復(fù)雜的業(yè)務(wù)需求。但是基于云計(jì)算的IT構(gòu)架和上一代的IT構(gòu)架有很大不同，只有云原生應(yīng)用（Cloud Native Application）才能充分發(fā)揮云計(jì)算彈性和靈活的特性。

目前，微服務(wù)是云原生應(yīng)用比較主流的一種構(gòu)架，微服務(wù)的理念是用服務(wù)來(lái)實(shí)現(xiàn)功能模塊組件化，把大的業(yè)務(wù)邏輯拆為多個(gè)很微小的服務(wù)，每個(gè)微服務(wù)實(shí)現(xiàn)一個(gè)簡(jiǎn)單的功能，微服務(wù)之間松散耦合。遵從微服務(wù)構(gòu)架的應(yīng)用具有彈性和靈活的特性，但是在構(gòu)架上，微服務(wù)比傳統(tǒng)應(yīng)用構(gòu)架復(fù)雜很多。

PaaS平臺(tái)的出現(xiàn)幫助開(kāi)發(fā)人員打造云原生應(yīng)用，讓開(kāi)發(fā)人員專注于業(yè)務(wù)開(kāi)發(fā)層面，并為構(gòu)架層面保駕護(hù)航。然而上一代的PaaS平臺(tái)過(guò)于復(fù)雜和笨重，沒(méi)有得到廣泛的應(yīng)用。基于Docker和Mesos打造的DCOS是下一代輕量級(jí)PaaS平臺(tái)的典型代表，DCOS極大地降低了PaaS平臺(tái)的復(fù)雜度，更加方便企業(yè)開(kāi)發(fā)人員實(shí)現(xiàn)各種業(yè)務(wù)應(yīng)用，幫助企業(yè)輕松打造基于云計(jì)算的軟件基礎(chǔ)設(shè)施。

Google如何做云計(jì)算

Google一直是云計(jì)算技術(shù)的領(lǐng)導(dǎo)者。我有幸在Google工作，接觸到了Google強(qiáng)大的內(nèi)部云計(jì)算平臺(tái)。Google所有的數(shù)據(jù)中心加起來(lái)有大約數(shù)百萬(wàn)臺(tái)服務(wù)器，這么多服務(wù)器被Google的分布式管理平臺(tái)Borg統(tǒng)一管理，形成巨大的資源池，支撐了Google龐大的業(yè)務(wù)體系。Google把所有的服務(wù)器分成了近百個(gè)集群，每個(gè)集群稱為一個(gè)Cell。每個(gè)Cell由幾萬(wàn)臺(tái)處于同一物理位置的服務(wù)器組成，每個(gè)Cell由幾個(gè)Borg主節(jié)點(diǎn)負(fù)責(zé)管理其余幾萬(wàn)臺(tái)服務(wù)器，被管理的每臺(tái)服務(wù)器對(duì)應(yīng)一個(gè)Borg從節(jié)點(diǎn)。

Google的開(kāi)發(fā)人員會(huì)向Borg提交任務(wù)執(zhí)行申請(qǐng)，Borg負(fù)責(zé)把任務(wù)運(yùn)行在一個(gè)或多個(gè)Cell。Borg運(yùn)行的任務(wù)有優(yōu)先級(jí)，高優(yōu)先級(jí)的任務(wù)會(huì)搶占低優(yōu)先級(jí)任務(wù)的資源。為了防止過(guò)度搶占，Borg在管理每個(gè)Cell資源的時(shí)候，任務(wù)優(yōu)先級(jí)越高，可供分配的總資源越少，反之，任務(wù)優(yōu)先級(jí)越低，可供分配的總資源越多，保證低優(yōu)先級(jí)的任務(wù)也會(huì)得到很好的執(zhí)行，而不會(huì)總被高優(yōu)先級(jí)任務(wù)搶占。

Google內(nèi)部雖然沒(méi)有強(qiáng)調(diào)PaaS、容器、不可變基礎(chǔ)設(shè)施（Immutable Infrastructure）以及微服務(wù)的概念，但是Google內(nèi)部處處體現(xiàn)著這些理念。

首先，Google內(nèi)部的云計(jì)算平臺(tái)除了Borg，還有各種軟件基礎(chǔ)設(shè)施，比如Google File System、MapReduce、BigTable、Chubby、Stubby、PubSub等等，組成了一個(gè)功能無(wú)比強(qiáng)大的PaaS。這些軟件基礎(chǔ)設(shè)施滿足了基于Google內(nèi)部云計(jì)算平臺(tái)開(kāi)發(fā)時(shí)碰到的各種需求，使得Google的開(kāi)發(fā)人員在開(kāi)發(fā)時(shí)非常方便，可以專注于業(yè)務(wù)本身，而不必過(guò)多考慮可擴(kuò)展性、容錯(cuò)性等等復(fù)雜的問(wèn)題，極大地提高了開(kāi)發(fā)效率。這正是PaaS的功能，提高開(kāi)發(fā)效率，降低開(kāi)發(fā)復(fù)雜度，保證應(yīng)用的性能、可靠性等等。

其次，Google內(nèi)部的業(yè)務(wù)應(yīng)用，都是把業(yè)務(wù)程序和各種依賴庫(kù)打包在一起，形成巨大的二進(jìn)制文件，這樣應(yīng)用程序在生產(chǎn)環(huán)境的服務(wù)器上運(yùn)行的時(shí)候，不需要額外的依賴。更進(jìn)一步，Google內(nèi)部不同應(yīng)用程序在同一服務(wù)器上運(yùn)行時(shí)，是用Cgroup技術(shù)進(jìn)行資源隔離，防止某個(gè)程序占用過(guò)多資源。這些其實(shí)都是容器的理念，讓應(yīng)用程序具備了可移植性，并對(duì)應(yīng)用進(jìn)行資源隔離。

再者，Google內(nèi)部生產(chǎn)環(huán)境服務(wù)器，基本上是被Borg自動(dòng)管理，每臺(tái)服務(wù)器上只安裝Linux、Borg程序以及必備的監(jiān)控程序等，開(kāi)發(fā)或運(yùn)維人員幾乎不會(huì)登陸上去做什么操作。這樣，Google每臺(tái)生產(chǎn)環(huán)境服務(wù)器的狀態(tài)都是不可變的，極大地簡(jiǎn)化了對(duì)服務(wù)器的運(yùn)維管理工作，這正是不可變基礎(chǔ)設(shè)施的理念。

另外，Google內(nèi)部也是按照微服務(wù)的方式來(lái)組織構(gòu)架團(tuán)隊(duì)。Google各個(gè)大的部門內(nèi)部，按照不同的業(yè)務(wù)功能劃分出不同的小團(tuán)隊(duì)，每個(gè)小團(tuán)隊(duì)負(fù)責(zé)開(kāi)發(fā)維護(hù)一個(gè)具體的功能模塊組件，也就是一個(gè)“微”服務(wù)。不同微服務(wù)之間通過(guò)遠(yuǎn)程過(guò)程調(diào)用（RPC）相互協(xié)同依賴，實(shí)現(xiàn)了很大規(guī)模的業(yè)務(wù)。比如我之前所在的團(tuán)隊(duì)，是負(fù)責(zé)Google廣告平臺(tái)用戶數(shù)據(jù)收集的業(yè)務(wù)，所維護(hù)的微服務(wù)有數(shù)千個(gè)應(yīng)用實(shí)例在運(yùn)行。

云原生應(yīng)用與傳統(tǒng)架構(gòu)

云計(jì)算最大的特點(diǎn)是彈性和靈活，企業(yè)采用云計(jì)算技術(shù)可以輕松應(yīng)對(duì)復(fù)雜的業(yè)務(wù)需求。一般來(lái)說(shuō)，云計(jì)算分為三層，IaaS、PaaS和SaaS：IaaS提供資源彈性，PaaS提供應(yīng)用彈性，SaaS提供服務(wù)彈性。目前IaaS和SaaS相對(duì)成熟，PaaS相對(duì)早期。PaaS最大的作用是幫助企業(yè)打造云原生應(yīng)用（Cloud Native Application），使得企業(yè)的業(yè)務(wù)應(yīng)用充分享受云計(jì)算帶來(lái)的靈活和彈性。

傳統(tǒng)IT構(gòu)架最大的問(wèn)題在于不能滿足復(fù)雜的業(yè)務(wù)需求。企業(yè)信息化經(jīng)過(guò)多年發(fā)展，很多企業(yè)的業(yè)務(wù)已經(jīng)實(shí)現(xiàn)了IT化。每家企業(yè)都面臨著激烈的商業(yè)競(jìng)爭(zhēng)，業(yè)務(wù)的需求往往紛繁復(fù)雜，勢(shì)必要求IT系統(tǒng)能靈活應(yīng)對(duì)業(yè)務(wù)的需求，但實(shí)際情況并非如此，往往是企業(yè)業(yè)務(wù)部門的需求很長(zhǎng)時(shí)間IT部門才能實(shí)現(xiàn)。云計(jì)算的出現(xiàn)，很大程度緩解了企業(yè)內(nèi)部IT跟不上業(yè)務(wù)發(fā)展需求的矛盾。

云原生應(yīng)用的優(yōu)點(diǎn)體現(xiàn)在具有良好的可擴(kuò)展性、伸縮性和容錯(cuò)性：當(dāng)業(yè)務(wù)需求發(fā)生變化時(shí)，云原生應(yīng)用可以做到快速迭代；當(dāng)業(yè)務(wù)規(guī)模發(fā)生變化時(shí)，云原生應(yīng)用可以做到彈性伸縮；當(dāng)IT系統(tǒng)出現(xiàn)軟硬件故障時(shí)，云原生應(yīng)用有良好的容錯(cuò)機(jī)制，可以做到讓業(yè)務(wù)應(yīng)用不宕機(jī)。云原生應(yīng)用的這些特性，能極大地幫助企業(yè)提升業(yè)務(wù)能力，在激烈的競(jìng)爭(zhēng)中占據(jù)優(yōu)勢(shì)。互聯(lián)網(wǎng)公司的快速發(fā)展，已經(jīng)印證了云計(jì)算技術(shù)和云原生應(yīng)用相比傳統(tǒng)IT構(gòu)架的巨大優(yōu)勢(shì)。

但是云原生應(yīng)用的種種良好特性并不是很輕易就能實(shí)現(xiàn)的，企業(yè)開(kāi)發(fā)人員在開(kāi)發(fā)業(yè)務(wù)應(yīng)用的時(shí)候，還要考慮未來(lái)應(yīng)用的可擴(kuò)展性和容錯(cuò)性，這極大地增加了開(kāi)發(fā)的復(fù)雜度。于是PaaS的出現(xiàn)，正是要幫助開(kāi)發(fā)人員降低云原生應(yīng)用的開(kāi)發(fā)復(fù)雜度，讓開(kāi)發(fā)人員還是專注于業(yè)務(wù)應(yīng)用的開(kāi)發(fā)，為開(kāi)發(fā)人員屏蔽底層細(xì)節(jié)。

PaaS往往會(huì)制定出一些開(kāi)發(fā)范式，只要企業(yè)的開(kāi)發(fā)人員遵從這些范式，那么開(kāi)發(fā)出的業(yè)務(wù)應(yīng)用就能獲得云原生應(yīng)用的特性。但是以CloudFoundry為代表的上一代PaaS，由于規(guī)范過(guò)于復(fù)雜，沒(méi)有在企業(yè)級(jí)得到很好的應(yīng)用。下一代輕量級(jí)PaaS（Micro PaaS），特別強(qiáng)調(diào)輕量的特性，沒(méi)有對(duì)開(kāi)發(fā)人員制定過(guò)多的開(kāi)發(fā)范式，更多是在軟件設(shè)計(jì)層面給出指導(dǎo)，極大地降低了使用門檻。比如，輕量級(jí)PaaS倡導(dǎo)應(yīng)用遵從微服務(wù)構(gòu)架設(shè)計(jì)，就能具有良好的可擴(kuò)展性；再如，輕量級(jí)PaaS倡導(dǎo)應(yīng)用盡量遵從無(wú)狀態(tài)設(shè)計(jì)，就能獲得良好的容錯(cuò)性。微服務(wù)構(gòu)架和無(wú)狀態(tài)設(shè)計(jì)，更多是軟件設(shè)計(jì)理念，而不是諸如EJB、RESTful這樣具體的編程規(guī)范，降低了開(kāi)發(fā)人員的學(xué)習(xí)成本，對(duì)開(kāi)發(fā)人員更加友好。

微服務(wù)和SOA異同點(diǎn)

微服務(wù)是眼下非常流行的應(yīng)用設(shè)計(jì)框架。如前所述，微服務(wù)不是具體的編程規(guī)范，而是軟件設(shè)計(jì)理念。微服務(wù)是伴隨互聯(lián)網(wǎng)公司業(yè)務(wù)規(guī)模快速擴(kuò)張進(jìn)而演化得來(lái)的設(shè)計(jì)模式，Google、Amazon、Netflix這些互聯(lián)網(wǎng)巨頭都是微服務(wù)的先行者和倡導(dǎo)者。遵從微服務(wù)設(shè)計(jì)，使得互聯(lián)網(wǎng)巨頭的業(yè)務(wù)應(yīng)用具有良好的可擴(kuò)展性：一方面保持業(yè)務(wù)應(yīng)用快速迭代，同時(shí)應(yīng)用迭代速度沒(méi)有隨著業(yè)務(wù)規(guī)模擴(kuò)展急劇減緩；另一方面保證業(yè)務(wù)應(yīng)用具有彈性伸縮能力，能處理海量業(yè)務(wù)帶來(lái)的巨大負(fù)載。

微服務(wù)有幾個(gè)主要的設(shè)計(jì)理念：

1、通過(guò)服務(wù)實(shí)現(xiàn)組件化。傳統(tǒng)的IT構(gòu)架是把所有的業(yè)務(wù)邏輯用一個(gè)大而全的應(yīng)用來(lái)實(shí)現(xiàn)，各個(gè)功能組件模塊是在一個(gè)應(yīng)用內(nèi)部。這樣做的后果是模塊之間很容易緊密耦合，隨著應(yīng)用越來(lái)越大，失去了可擴(kuò)展性，一旦要修改業(yè)務(wù)邏輯，就會(huì)牽一發(fā)而動(dòng)全身，導(dǎo)致應(yīng)用迭代非常緩慢。微服務(wù)使用服務(wù)的形式來(lái)實(shí)現(xiàn)各個(gè)功能組件模塊，各個(gè)模塊間的依賴通過(guò)服務(wù)的方式來(lái)組織，即一個(gè)模塊通過(guò)遠(yuǎn)程過(guò)程調(diào)用來(lái)依賴另一個(gè)模塊，每個(gè)模塊是一個(gè)微服務(wù)。這樣做使得模塊之間很容易松散耦合，每個(gè)微服務(wù)規(guī)定好服務(wù)的形式，諸如請(qǐng)求的格式以及響應(yīng)的格式，然后多個(gè)微服務(wù)組合起來(lái)共同實(shí)現(xiàn)整個(gè)業(yè)務(wù)邏輯。如圖一所示。

圖一：整體型應(yīng)用程序與微服務(wù)架構(gòu)應(yīng)用程序

2、微服務(wù)的松散耦合構(gòu)架，使得企業(yè)可以按照業(yè)務(wù)功能來(lái)組織團(tuán)隊(duì)，每個(gè)小團(tuán)隊(duì)負(fù)責(zé)一個(gè)微服務(wù)，以降低團(tuán)隊(duì)間的溝通成本。很多企業(yè)的研發(fā)團(tuán)隊(duì)通常按開(kāi)發(fā)職責(zé)劃分，諸如前端開(kāi)發(fā)團(tuán)隊(duì)、中間件開(kāi)發(fā)團(tuán)隊(duì)、數(shù)據(jù)庫(kù)團(tuán)隊(duì)等等。這樣按職責(zé)劃分加大了團(tuán)隊(duì)間溝通成本，因?yàn)槊總€(gè)具體的業(yè)務(wù)需求都有可能涉及前后端，因此多個(gè)職能團(tuán)隊(duì)要配合才能實(shí)現(xiàn)具體的業(yè)務(wù)需求，這樣無(wú)疑溝通成本很高。按照微服務(wù)的方式，團(tuán)隊(duì)是按業(yè)務(wù)功能來(lái)組織劃分，而不是按照開(kāi)發(fā)職責(zé)劃分，這樣可以讓具體的業(yè)務(wù)需求落在某個(gè)團(tuán)隊(duì)內(nèi)部，避免涉及多個(gè)團(tuán)隊(duì)，從而極大地降低了團(tuán)隊(duì)間的溝通成本。這也符合康威法則：任何組織在設(shè)計(jì)一套系統(tǒng)（廣義層面的系統(tǒng)）時(shí)，其設(shè)計(jì)成果都會(huì)直接體現(xiàn)該組織所使用的溝通結(jié)構(gòu)。如圖二所示。

圖二：康威定律的實(shí)際體現(xiàn)

3、企業(yè)按照業(yè)務(wù)功能來(lái)組織團(tuán)隊(duì)，每個(gè)團(tuán)隊(duì)負(fù)責(zé)一個(gè)微服務(wù)，可以做到“誰(shuí)構(gòu)建，誰(shuí)運(yùn)行”，這將極大降低運(yùn)維復(fù)雜度。如果按照傳統(tǒng)的IT方式，開(kāi)發(fā)團(tuán)隊(duì)開(kāi)發(fā)出來(lái)的應(yīng)用交給運(yùn)維團(tuán)隊(duì)去上線維護(hù)，不僅周期長(zhǎng)，而且運(yùn)維復(fù)雜度高，因?yàn)檫\(yùn)維團(tuán)隊(duì)畢竟不了解業(yè)務(wù)實(shí)現(xiàn)細(xì)節(jié)，應(yīng)用出了問(wèn)題還需要涉及開(kāi)發(fā)和運(yùn)維兩個(gè)團(tuán)隊(duì)來(lái)配合。如果按照微服務(wù)的方式，每個(gè)團(tuán)隊(duì)開(kāi)發(fā)一個(gè)微服務(wù)，并負(fù)責(zé)該微服務(wù)的上線運(yùn)行，不涉及運(yùn)維團(tuán)隊(duì)，這樣做不僅周期短，而且降低運(yùn)維復(fù)雜度，某個(gè)微服務(wù)出現(xiàn)問(wèn)題僅涉及所負(fù)責(zé)的開(kāi)發(fā)團(tuán)隊(duì)。“誰(shuí)構(gòu)建，誰(shuí)運(yùn)行”還可以讓每個(gè)團(tuán)隊(duì)都經(jīng)歷整個(gè)產(chǎn)品的生命周期。采用微服務(wù)構(gòu)架后，運(yùn)維團(tuán)隊(duì)將更多負(fù)責(zé)整體業(yè)務(wù)相關(guān)的工作，比如整體業(yè)務(wù)的資源規(guī)劃、穩(wěn)定性、性能等等。

4、有了微服務(wù)，可以方便地做到離散化數(shù)據(jù)管理。每個(gè)微服務(wù)可以自行管理各自的數(shù)據(jù)，包括不同業(yè)務(wù)的數(shù)據(jù)、不同微服務(wù)的配置等等，更加切實(shí)匹配業(yè)務(wù)需求。如圖三所示。

圖三：微服務(wù)架構(gòu)的離散數(shù)據(jù)管理

5、微服務(wù)構(gòu)架使得持續(xù)集成和持續(xù)交付變得更加便捷。對(duì)比傳統(tǒng)IT構(gòu)架，有了微服務(wù)，集成和交付的單元從大而全的整體應(yīng)用變成了各個(gè)微服務(wù)。這樣，每個(gè)微服務(wù)都可以靈活地集成和交付，降低了集成和交付的復(fù)雜度，提高了業(yè)務(wù)應(yīng)用迭代的速度，進(jìn)而提升了企業(yè)的業(yè)務(wù)能力。如圖四所示。

圖四：微服務(wù)構(gòu)架使得持續(xù)集成和持續(xù)交付變得更加便捷

微服務(wù)經(jīng)常被拿來(lái)與十年前就提出的面向服務(wù)架構(gòu)（SOA）進(jìn)行比較，因?yàn)槲⒎?wù)和SOA有相似的主張。SOA實(shí)際所指的是利用企業(yè)服務(wù)總線實(shí)現(xiàn)的集成化整體應(yīng)用程序，企業(yè)服務(wù)總線通常包含復(fù)雜度極高的消息跌幅、編排、轉(zhuǎn)換以及業(yè)務(wù)規(guī)則應(yīng)用等機(jī)制。準(zhǔn)確講，SOA是中間件時(shí)代的一種開(kāi)發(fā)范式，微服務(wù)是云計(jì)算時(shí)代輕量級(jí)PaaS的開(kāi)發(fā)范式。

支撐微服務(wù)的問(wèn)題和挑戰(zhàn)

前面提到微服務(wù)最大好處是使得應(yīng)用具有可擴(kuò)展性，方便靈活應(yīng)對(duì)業(yè)務(wù)的復(fù)雜需求。凡事必有兩面性，微服務(wù)提升了應(yīng)用的可擴(kuò)展性，但是微服務(wù)也有其復(fù)雜性的一面。

首先，微服務(wù)以服務(wù)的形式實(shí)現(xiàn)組件化模塊化，不同功能模塊組件之間通過(guò)服務(wù)的形式，即遠(yuǎn)程過(guò)程調(diào)用的方式，來(lái)相互通訊。這樣一來(lái)，模塊或組件間的耦合度降低了，但是通訊效率也降低了。畢竟遠(yuǎn)程過(guò)程調(diào)用比共享內(nèi)存的方式要慢很多。此外，為了提高應(yīng)用的容錯(cuò)性，一般微服務(wù)之間的遠(yuǎn)程過(guò)程調(diào)用都盡量設(shè)計(jì)為異步通訊的方式。異步通訊顯然比同步通訊在開(kāi)發(fā)復(fù)雜度方面增加不少。

其次，對(duì)于按微服務(wù)構(gòu)架設(shè)計(jì)的應(yīng)用進(jìn)行修改迭代的時(shí)候，如果要修改的部分僅限于某個(gè)或某些微服務(wù)組件內(nèi)部，那就比較容易，不涉及微服務(wù)組件間的依賴，比如更改一個(gè)微服務(wù)內(nèi)部的業(yè)務(wù)邏輯、把一個(gè)微服務(wù)組件分拆為多個(gè)微服務(wù)。但是一旦要修改的部分要牽扯到已有微服務(wù)組件之間的依賴，那改動(dòng)起來(lái)還是有一定工作量的，比如遠(yuǎn)程過(guò)程調(diào)用的接口修改，或者更進(jìn)一步，重新定義兩個(gè)或多個(gè)微服務(wù)之間的業(yè)務(wù)邊界。如果微服務(wù)構(gòu)架設(shè)計(jì)的不好，應(yīng)用迭代的時(shí)候頻繁更改微服務(wù)間的依賴關(guān)系，也就失去了良好的可擴(kuò)展性。

再者，由于按照微服務(wù)構(gòu)架設(shè)計(jì)的應(yīng)用天然是分布式應(yīng)用，勢(shì)必在故障排除方面增加了復(fù)雜度。分布式應(yīng)用的維護(hù)對(duì)遠(yuǎn)程監(jiān)控的依賴很強(qiáng)，因?yàn)榉植际綉?yīng)用會(huì)運(yùn)行在很多臺(tái)服務(wù)器上，而且會(huì)在不同服務(wù)器上動(dòng)態(tài)調(diào)度遷移，一旦發(fā)生故障，不可能要求運(yùn)維人員逐一檢查每臺(tái)服務(wù)器，必須有統(tǒng)一的監(jiān)控平臺(tái)，實(shí)時(shí)監(jiān)控應(yīng)用的運(yùn)行情況，并統(tǒng)一收集日志用于故障排查。此外，微服務(wù)之間如果是異步通訊機(jī)制，也增加了錯(cuò)誤檢查的復(fù)雜度。

下一代輕量級(jí)PaaS：基于Docker+Mesos的DCOS

基于Docker和Mesos打造的Data Center Operating System（DCOS），是下一代輕量級(jí)PaaS的代表。以Docker為代表的容器技術(shù)，為DCOS和企業(yè)業(yè)務(wù)應(yīng)用之間，定義了清晰的邊界：DCOS提供統(tǒng)一的、標(biāo)準(zhǔn)的容器運(yùn)行環(huán)境，滿足容器運(yùn)行時(shí)的各種需求，諸如調(diào)度、編排、容錯(cuò)恢復(fù)、彈性伸縮、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、監(jiān)控報(bào)警等等；容器內(nèi)部封裝企業(yè)的業(yè)務(wù)應(yīng)用，為應(yīng)用提供良好的可移植性。

DCOS的輕量特性主要體現(xiàn)在如下方面：

首先，企業(yè)的開(kāi)發(fā)人員不需要了解容器之外的太多細(xì)節(jié)，使得開(kāi)發(fā)人員可以專注于開(kāi)發(fā)業(yè)務(wù)，降低了開(kāi)發(fā)人員的開(kāi)發(fā)復(fù)雜度。

其次，DCOS為云原生應(yīng)用提供良好的彈性，包括可擴(kuò)展性、伸縮性和容錯(cuò)性。開(kāi)發(fā)人員遵從微服務(wù)構(gòu)架和無(wú)狀態(tài)設(shè)計(jì)開(kāi)發(fā)云原生應(yīng)用，一方面可以通過(guò)DCOS快速集成和交付上線，加快迭代周期，另一方面DCOS為云原生應(yīng)用提供很好的彈性伸縮能力，可以按需使用計(jì)算資源，再一方面DCOS使云原生應(yīng)用具有很好的容錯(cuò)能力。

再者，DCOS極大地降低了運(yùn)維復(fù)雜度。DCOS實(shí)現(xiàn)了不可變基礎(chǔ)設(shè)施，DCOS在每臺(tái)服務(wù)器上只安裝Linux、Docker、Mesos等DCOS的組件，不包括任何業(yè)務(wù)應(yīng)用相關(guān)的依賴，再加上DCOS的容錯(cuò)機(jī)制，使得生產(chǎn)系統(tǒng)的運(yùn)維復(fù)雜度大大降低。

總之，云計(jì)算是下一代企業(yè)級(jí)IT的發(fā)展趨勢(shì)，云計(jì)算相關(guān)技術(shù)正在逐漸演化成熟，特別是PaaS領(lǐng)域的技術(shù)，正在快速發(fā)展。以DCOS為代表的下一代輕量級(jí)PaaS正逐漸為企業(yè)客戶所接受。因?yàn)镈COS具有輕量的優(yōu)點(diǎn)，只要企業(yè)開(kāi)發(fā)人員遵從微服務(wù)和無(wú)狀態(tài)設(shè)計(jì)開(kāi)發(fā)出云原生業(yè)務(wù)應(yīng)用，DCOS就能保證云原生應(yīng)用具有良好的可擴(kuò)展性、伸縮性和容錯(cuò)性。這極大地提升了企業(yè)IT的靈活性，緩解了IT跟不上業(yè)務(wù)發(fā)展需求的矛盾，幫助企業(yè)快速應(yīng)對(duì)業(yè)務(wù)需求，提升企業(yè)業(yè)務(wù)能力。

精彩問(wèn)答

QQ群 | KVM虛擬化1群

Q1. 云計(jì)算彈性與靈活，更多在應(yīng)用業(yè)務(wù)的彈性與靈活、快速上線，然而需要龐大的基礎(chǔ)設(shè)施支撐、同時(shí)需要虛擬化、容器技術(shù)支撐，若沒(méi)有這些技術(shù)云計(jì)算很難做到彈性、靈活，請(qǐng)問(wèn)在銀行業(yè)務(wù)，銀行更多是的使用 小機(jī) Powervm 云計(jì)算該如何去做呢？

A1. 目前 DCOS 還不支持小型機(jī)。云計(jì)算的趨勢(shì)是x86化。

Q2. 云計(jì)算解決了應(yīng)用業(yè)務(wù)快速上線，彈性與靈活，基礎(chǔ)環(huán)境的靈活彈性。個(gè)人認(rèn)為云計(jì)算需要龐大的基礎(chǔ)設(shè)施（Datacenter）環(huán)境及高效的設(shè)施，基礎(chǔ)環(huán)境設(shè)施很重要。

A2. 的確是很重要。而且數(shù)據(jù)中心基礎(chǔ)設(shè)施復(fù)雜度很高，不應(yīng)該每個(gè)公司都搞一遍。數(shù)據(jù)中心必須要有很大規(guī)模，才能降低邊際成本。

QQ群 | KVM虛擬化2群

Q1. 請(qǐng)問(wèn)，銀行如何轉(zhuǎn)型新型IT模式呢，云計(jì)算將如何在銀行領(lǐng)域進(jìn)行落地呢？個(gè)人覺(jué)得 IT 市場(chǎng)還是在銀行領(lǐng)域，1. 銀行有錢 2. IT服務(wù)銀行用的最多，最廣泛。

A1. 云計(jì)算將幫助金融類客戶減輕IT系統(tǒng)的復(fù)雜度，讓客戶的業(yè)務(wù)應(yīng)用更輕量、有彈性，靈活應(yīng)對(duì)復(fù)雜多變的業(yè)務(wù)需求。下一代企業(yè)級(jí)IT肯定是要往輕量化方向發(fā)展，注重應(yīng)用的彈性。
金融機(jī)構(gòu)對(duì)IT服務(wù)有需求，而且有付費(fèi)意愿

Q2. 企業(yè)如何去構(gòu)架一個(gè)真正的云計(jì)算數(shù)據(jù)中心呢？構(gòu)架成什么樣才能達(dá)到云計(jì)算特性呢？

A2. 云計(jì)算最根本的特性是彈性。云計(jì)算的彈性包括三層：
IaaS 提供資源彈性，PaaS 提供應(yīng)用彈性，SaaS 提供服務(wù)彈性。
包含這三層彈性才是完整的云計(jì)算彈性。

Q3. 真正的要將云計(jì)算進(jìn)行落地，從技術(shù)角度該如何做呢？要遵循什么樣的機(jī)制去構(gòu)建云計(jì)算數(shù)據(jù)中心，或者說(shuō)怎樣能達(dá)到云計(jì)算、靈活、彈性。需要用那些技術(shù)做構(gòu)建呢？

A3. 其實(shí)主要是 IaaS 相關(guān)技術(shù)和 PaaS 相關(guān)技術(shù)。
IaaS 領(lǐng)域主要的技術(shù)就是虛擬化技術(shù)，包括虛擬主機(jī)、SDN、軟件定義存儲(chǔ)等。
PaaS 領(lǐng)域的技術(shù)相對(duì)不夠成熟，目前 PaaS 領(lǐng)域最流行的技術(shù)就是 Docker，還有對(duì) Docker 管理調(diào)度的技術(shù)，比如 Mesos、K8s、Swarm 等，以及 Docke r網(wǎng)絡(luò)和存儲(chǔ)管理的技術(shù)，比如Calico 和 Flocker。

微信群 | 云實(shí)名技術(shù)

Q1. DCOS 是不是在 Docker 之上還做了管理？

A1. 是的，DCOS目前用Mesos管理Docker

Q2. 微服務(wù)應(yīng)該是對(duì)一個(gè)傳統(tǒng)的應(yīng)用進(jìn)行拆分吧？

A2. 肯定要拆分。微服務(wù)的拆分不僅是業(yè)務(wù)應(yīng)用實(shí)現(xiàn)層面拆分，對(duì)開(kāi)發(fā)團(tuán)隊(duì)的組織也要拆分成小團(tuán)隊(duì)。微服務(wù)的拆分不是按照開(kāi)發(fā)職責(zé)拆（不是按前端開(kāi)發(fā)、后段開(kāi)發(fā)來(lái)拆），而是按照業(yè)務(wù)職責(zé)拆

Q3. 能具體描述下 Mesos 的功能嗎？Mesos 和 Marathon 是否都可以管理 Docker，其差別在哪里？

A3. Mesos 主要是用于資源管理，Mesos 不直接管理 Docker。Marathon 是基于 Mesos 做任務(wù)調(diào)度，Marathon 支持管理調(diào)度 Docker 任務(wù)。

Q4. 我們現(xiàn)在用 Kubernetes，但是實(shí)踐中，碰到了太多問(wèn)題，想換 Swarm，有什么好的建議嗎，如果用 Mesos 呢？

A4. K8s 和 Swarm 都比較新，還沒(méi)有經(jīng)過(guò)很大規(guī)模生產(chǎn)系統(tǒng)驗(yàn)證。Mesos 相對(duì)成熟一些，Twitter 用 Mesos 管理上萬(wàn)臺(tái)物理服務(wù)器。這些開(kāi)源技術(shù)在易用性方面都有缺陷，畢竟只是技術(shù)不是產(chǎn)品。

微信群 | 《運(yùn)維前線》

Q1. Docker 如何解決網(wǎng)絡(luò)流量隔離的問(wèn)題？

A1. Docker 目前在網(wǎng)絡(luò)方面還很弱，目前沒(méi)有非常成熟的方案，Calico 是我們目前在嘗試的方案

Q2. 把所有的服務(wù)拆成微服務(wù)之后是不是會(huì)給整個(gè)系統(tǒng)帶來(lái)復(fù)雜性？這個(gè)微應(yīng)該微到什么程度？

A2. 的確微服務(wù)會(huì)提高系統(tǒng)復(fù)雜度，所以微服務(wù)非常需要PaaS來(lái)簡(jiǎn)化系統(tǒng)復(fù)雜度。
微服務(wù)該多微小，這個(gè)沒(méi)有一般性標(biāo)準(zhǔn)，要按照業(yè)務(wù)來(lái)定。一般來(lái)講，一個(gè)微服務(wù)最好實(shí)現(xiàn)一個(gè)單一功能。

Q3. 誰(shuí)構(gòu)建，誰(shuí)運(yùn)行，那微服務(wù)團(tuán)隊(duì)內(nèi)部懂各種技術(shù)的人員都需要存在了，懂開(kāi)發(fā)語(yǔ)言的，懂平臺(tái)軟件的，懂運(yùn)維的，人員的成本是否也上去了呢？

A3. PaaS平臺(tái)的作用就是降低開(kāi)發(fā)人員的開(kāi)發(fā)難度，減輕運(yùn)維工作復(fù)雜度。有了PaaS平臺(tái)之后，懂平臺(tái)軟件的人可以減少，運(yùn)維的工作變輕，開(kāi)發(fā)人員可以專注業(yè)務(wù)開(kāi)發(fā)而無(wú)需考慮很多底層細(xì)節(jié)。

Q4. 沒(méi)有開(kāi)發(fā)能力的運(yùn)維能上不？

A4. 可以，運(yùn)維本來(lái)就不要很強(qiáng)的開(kāi)發(fā)能力。PaaS平臺(tái)就是要降低運(yùn)維復(fù)雜度。Immutable Infrastructure會(huì)極大減輕運(yùn)維的工作復(fù)雜度。

Q5. 單單靠一個(gè)paas平臺(tái)實(shí)現(xiàn)太多，勢(shì)必會(huì)造成另外的一個(gè)極端。

A5. 是的。所以PaaS平臺(tái)本身也要輕量化。上一代PaaS沒(méi)有流行起來(lái)就是因?yàn)椴粔蜉p量，不夠靈活。云計(jì)算時(shí)代，企業(yè)客戶都偏向輕量化的平臺(tái)和應(yīng)用。

Q6. 數(shù)人云在docker領(lǐng)域主要做了哪些改進(jìn)，提供哪些特色功能或者服務(wù)？

A6. 數(shù)人云對(duì)Docker本身沒(méi)有什么改動(dòng)，就是標(biāo)準(zhǔn)的Docker開(kāi)源版本。數(shù)人云的主要工作在對(duì)于Docker的管理調(diào)度方面，包括服務(wù)發(fā)現(xiàn)、負(fù)載均衡、灰度發(fā)布、彈性伸縮等等。