1、透過(guò)三個(gè)典型代表暢談PaaS的前世今生PaaS的前世今生我們所熟悉的云計(jì)算分為3個(gè)層面：IaaS（基礎(chǔ)架構(gòu)即服務(wù)）、PaaS（平臺(tái)即服務(wù)）、 SaaS（軟件即服務(wù)）。與SaaS相比，PaaS和IaaS的概念相對(duì)較新，也是最近幾 年云計(jì)算領(lǐng)域的集中發(fā)力點(diǎn)，像 Amazon微軟、谷歌、阿里云等還有很多初創(chuàng) 公司都推出了 IaaS和PaaS產(chǎn)品。下面一張圖比較經(jīng)典的比較傳統(tǒng)IT、IaaS和PaaS：目前市面上有很多PaaS平臺(tái)，我自己認(rèn)為可以分為3個(gè)階段：第一代PaaS,比如Google App Engine SAE這是最早期的PaaS,當(dāng)時(shí) 并沒(méi)有PaaS這個(gè)概念，但是他們做的事情，現(xiàn)在看來(lái)是包含

2、在PaaS范圍 內(nèi)的。第二代 PaaS,比如 Cloud Foundry、OpenShift。這是各大 IaaS 流行之 后，順勢(shì)推出的PaaS 并且迅速發(fā)展。第三代PaaS,比如Kubernetes。這是在 Docker火爆之后，利用 Docker 的特性構(gòu)建出許多PaaS,這些PaaS更加靈活，更加適應(yīng)企業(yè)，逐漸成為 PaaS的主力，我想也是很多人正在做的方向。接下來(lái)給大家說(shuō)明下剛才提到的幾個(gè)典型的項(xiàng)目，Cloud Foundry、Docker和Kubernetes ,從中就可以看到幾代PaaS進(jìn)化的技術(shù)驅(qū)動(dòng)力。Cloud FoundryCloud Foundry是VMware于2011年

3、推出的業(yè)界第一個(gè)開(kāi)源 PaaS云平臺(tái)，后來(lái) 分拆出Pivotal公司進(jìn)行接管，2014創(chuàng)立Cloud Foundry基金會(huì)，希望吸引更 多的公司參與，而不是 Pivotal 一家獨(dú)大。現(xiàn)在說(shuō)的Cloud Foundry是V2架構(gòu)，它的結(jié)構(gòu)圖如下: Router：路由模塊，所有的數(shù)據(jù)面和管理面請(qǐng)求都通過(guò) Router進(jìn)行分發(fā)。 UAA/Login Server :鑒權(quán)模塊。 NATS消息總線(xiàn)，Cloud Foundry內(nèi)部組件的通信主要通過(guò) NATS1行通Cloud Controller(CC):管理中心，負(fù)責(zé)應(yīng)用的生命周期管理等等。, Health Manager ：應(yīng)用的健康監(jiān)控狀態(tài)。DEA

4、應(yīng)用的運(yùn)行時(shí)節(jié)點(diǎn)，應(yīng)用都是運(yùn)行在DEA。Warden容器管理,K塊，類(lèi)似 Docker,提供給應(yīng)用容器運(yùn)行環(huán)境。 Service Brokers :用于適配對(duì)接各類(lèi)的第三方服務(wù)，可以是各種關(guān)系數(shù) 據(jù)庫(kù)、中間件、緩存、云存儲(chǔ)、內(nèi)存數(shù)據(jù)庫(kù)等各種服務(wù)。 Metrics Collector/App Log Aggregator ：平臺(tái)應(yīng)用的日志和監(jiān)控?cái)?shù)據(jù)收Cloud Foundry推出以后逐漸得到了各大廠(chǎng)商的支持，華為云、舊M BlueMix、HP Cloud和Dell云服務(wù)都采用了 Cloud Foundry 作為基礎(chǔ)，一時(shí)間成為 PaaS 的代表。那么Cloud Foundry的優(yōu)勢(shì)有哪些呢？開(kāi)源

5、、開(kāi)發(fā)的架構(gòu)。開(kāi)源是趨勢(shì)，Cloud Foundry順應(yīng)了趨勢(shì)，自然可以吸引 大批的開(kāi)發(fā)者和公司參與其中。同時(shí) Cloud Foundry是一個(gè)開(kāi)發(fā)的架構(gòu)，定義 了一套標(biāo)準(zhǔn)，可以擴(kuò)展多種框架、語(yǔ)言、運(yùn)行時(shí)環(huán)境及應(yīng)用服務(wù)，支持運(yùn)行在云 平臺(tái)IaaS上。運(yùn)維智能化。運(yùn)維能力是PaaS最最最最最重要的能力，這決定了 PaaS的成功 與否，如果PaaS無(wú)法提供強(qiáng)大的運(yùn)維支持，為什么我要把應(yīng)用托管在PaaS,我需要看日志和監(jiān)控，我需要經(jīng)常升級(jí)應(yīng)用等等，IaaS可是提供了相當(dāng)靈活的處 理機(jī)制。Cloud Foundry在這方面做出了很多努力，提供應(yīng)用的容錯(cuò)容災(zāi)、彈 性伸縮、負(fù)載均衡、安全控制、監(jiān)控日志的收

6、集匯總等等。容器。這里不得不提容器技術(shù)，容器輕量、隔離的特性是非常適合PaaS的需求 的，Cloud Foundry中開(kāi)發(fā)了 Warden組件來(lái)實(shí)現(xiàn)容器管理，實(shí)際上 Warden和 Docker類(lèi)似，只不過(guò) Cloud Foundry當(dāng)時(shí)并沒(méi)有專(zhuān)注于容器這一塊， Warden在 易用性和設(shè)計(jì)上都不如 Docker,自然被Docker搶了風(fēng)頭。Cloud Foundry最大的問(wèn)題是它只能支持簡(jiǎn)單的 We瀆應(yīng)用：應(yīng)用只能暴露一個(gè) HTT嘲口，應(yīng)用之間通信也只能通過(guò) HTT對(duì)等，這是因?yàn)镃loud Foundry一開(kāi) 始的設(shè)計(jì)模型是比較簡(jiǎn)單的，很多復(fù)雜場(chǎng)景應(yīng)該是沒(méi)考慮的，目前V3架構(gòu)Diego 正在

7、開(kāi)發(fā)中，應(yīng)該有這方面的考慮?？傊瓹loud Foundry最為第二代PaaS的代表，它在運(yùn)作、架構(gòu)和技術(shù)上相比第 一代PaaS都有一定的提高，在云計(jì)算大潮中引領(lǐng)了 PaaS的發(fā)展，但是PaaS 直處在一個(gè)不溫不火的尷尬程度，使用PaaS絕大多數(shù)是開(kāi)發(fā)者個(gè)人的玩票性質(zhì), 真正使用的企業(yè)用戶(hù)其實(shí)很少。接下來(lái) Docker登場(chǎng)。DockerDocker是PaaS提供商dotCloud開(kāi)源的高級(jí)容器引擎，Docker自2013年以來(lái)非 常火熱，2014年就已經(jīng)火得沒(méi)有朋友了。這篇文章講Docker的由來(lái)的，蠻有趣的，有點(diǎn)無(wú)心插柳柳成蔭的意思。關(guān)于Docker的好處，現(xiàn)在有許多文章都會(huì)說(shuō)明，這里我講講個(gè)

8、人的理解：像很多文章提到的Docker快速敏捷（啟動(dòng)、停止都是以秒或毫秒為單位的），隔 離輕量級(jí)（不添加額外的操作系統(tǒng)），這些實(shí)際上是Linux內(nèi)核提供的能力， Docker是沿用了這些特性，像 Cloud Foundry的Warden也有這些能力，Docker 最大的創(chuàng)新點(diǎn)在于Docker鏡像的設(shè)計(jì)，下面是張Docker鏡像的層次圖，分層的 文件系統(tǒng)，一層層地搭建出一個(gè)完整的容器運(yùn)行環(huán)境：references parent這樣一來(lái)，我們可以像樂(lè)高玩具一樣搭建各式各樣的鏡像，同時(shí) Docker提供了 一整套鏡像存儲(chǔ)方案(Docker Registry),可以非常方便地獲取想要的鏡像，然 后快速

9、地啟動(dòng)運(yùn)行，而不必像以前那樣安裝各種麻煩的依賴(lài)軟件。Docker更像個(gè)微創(chuàng)新者，但是解決了最大痛點(diǎn)，像Warden只解決了應(yīng)用運(yùn)行的 問(wèn)題，而Docker解決了應(yīng)用的發(fā)布、構(gòu)建和運(yùn)行，創(chuàng)建了很多想象空間，所以 基于Docker衍生出了很多新的解決方案，特別是 PaaS即第三代的PaaS Kubernetes是其中最具代表性的一員，最后講一下Kubernetes。KubernetesKubernetes是Google開(kāi)源的容器集群管理系統(tǒng)。它構(gòu)建Docker技術(shù)之上，為容器化的應(yīng)用提供資源調(diào)度、部署運(yùn)行、服務(wù)發(fā)現(xiàn)、擴(kuò)容縮容等整一套功能，本 質(zhì)上可看作是基于容器技術(shù)的 micro-PaaS平臺(tái)。因

10、為Docker解決了應(yīng)用編譯構(gòu)建的問(wèn)題，所以Kubernetes架構(gòu)上就可以專(zhuān)注在 容器編排，服務(wù)發(fā)現(xiàn)等等運(yùn)維相關(guān)特性上，像 Cloud Foundry就是花了很大精力 在應(yīng)用編譯構(gòu)建上，集成了 BuildPack ,各種文件傳輸，效果其實(shí)不是特別好。PaaS的價(jià)值不是在幫你編譯打包上，而是在于節(jié)省運(yùn)維成本。Kubernetes的設(shè)計(jì)模型我認(rèn)為有幾個(gè)好的地方：. Label 的設(shè)計(jì)：Pod、Service、Replication Controller 之間的是通過(guò) Label進(jìn)行關(guān)聯(lián)，這是一種輕綁定的方式，可以方便地組合業(yè)務(wù)，做灰度 升級(jí)等等。.網(wǎng)絡(luò)模型：Kubernetes采用扁平化的網(wǎng)絡(luò)模

11、型，每個(gè) Pod都有一個(gè)全局 唯一的IP(IP-per-pod) , Pod之間可以跨主機(jī)通信，相比于 Docker原生 的NA*式來(lái)說(shuō)，這樣使得容器在網(wǎng)絡(luò)層面更像虛擬機(jī)或者物理機(jī)，復(fù)雜度整體降低，更加容易實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)、遷移、負(fù)載均衡等功能。Q&A問(wèn)：開(kāi)源勢(shì)必引入安全問(wèn)題。Cloud Foundry的安全保護(hù)機(jī)制？答：Cloud Foundry對(duì)于應(yīng)用有個(gè)安全組的特性，可以控制應(yīng)用容器的訪(fǎng)問(wèn)。但 是實(shí)際上能力不強(qiáng)，容器安全這塊一直是被擔(dān)心的地方。問(wèn)：Cloud Foundry的DEA即應(yīng)用的運(yùn)行時(shí)節(jié)點(diǎn)，是虛擬的操作系統(tǒng)么 ？Warden 對(duì)底層的操作系統(tǒng)有和要求？Warden如何實(shí)現(xiàn)的隔離性？

12、答：DEA1個(gè)服務(wù)，其實(shí)還是Linux系統(tǒng)WardeM內(nèi)核有要求，實(shí)現(xiàn)原理和Docker 類(lèi)似。問(wèn)：va/spring/web 應(yīng)用很容易在Docker/Kubernetes環(huán)境運(yùn)行，如果要遷移 到CF,工作量大嗎？答：CF V2工作量應(yīng)該挺大，V3的話(huà)因?yàn)橹С諨ocker,所以還好。問(wèn)：關(guān)于k8s中Flannel和Weave兩者哪個(gè)更適合生產(chǎn)環(huán)境？答：這個(gè)我最近正在分析，感覺(jué) Flannel和WeavetB還不成熟，推薦OVS問(wèn)：Docker既然是namespace隔離的，就算不安全應(yīng)該也影響不是很大吧 ？答：其實(shí)如果你清楚原理，很容易進(jìn)入到容器環(huán)境中的，沒(méi)辦法，安全是個(gè)大問(wèn) 題。問(wèn)：k8s

13、可以實(shí)現(xiàn)應(yīng)用的自主遷移嗎？答：目前沒(méi)有Pod遷移的API。問(wèn)：CloudFoundary中監(jiān)控部分有插件機(jī)制么？答：支持導(dǎo)入到各種第三方監(jiān)控系統(tǒng)。問(wèn)：Pod直接通信需要開(kāi)通隧道么？換句話(huà)說(shuō)他們之間是如何實(shí)現(xiàn)通信的？答：容器跨主機(jī)的通信，是對(duì) Docker的增強(qiáng)，像Flannel、ovs等。問(wèn)：PaaS的三個(gè)典型代表：Cloud Foundry、Docker和Kubernetes ,最近的DaoCloud、靈雀云、時(shí)速云等以 Docker為核心提出了新的 CaaS概念。CaaS和PaaS者B使用了 Docker, Kubernetes等技術(shù)，您是怎么理解 PaaS和CaaS的？答：Caa哈器即服

14、務(wù)，我的理解就是 PaaS只不過(guò)主打這Docker容器，所以叫 CaaS問(wèn)：Docker在CentOS上使用devicemapper,據(jù)說(shuō)容易使系統(tǒng)crash ,對(duì)于其他 的文件系統(tǒng)有沒(méi)有推薦，brtfs和aufs哪個(gè)更好？答：aufs是內(nèi)核不接受的，聽(tīng)說(shuō)是因?yàn)榇a太亂。問(wèn)：對(duì)于管理 Docker這件事情，除了 Kubernetes , OpenStack（IaaS 陣營(yíng)），YARN（Hadoop車(chē)營(yíng)）也開(kāi)始發(fā)力，怎么看待這幾者間的競(jìng)爭(zhēng) ？答：沒(méi)有任何技術(shù)是銀彈，不同需求不同設(shè)計(jì)。當(dāng)然大家都想占據(jù)制高點(diǎn)了，這 就是運(yùn)作了。問(wèn)：k8s現(xiàn)在具備auto scaling 能力嗎，比如應(yīng)用響應(yīng)時(shí)間變長(zhǎng)，k8s可以自動(dòng)擴(kuò)容？答：沒(méi)有。問(wèn)：如果將Flannel替換成ovs是不是也可以替換掉kube-proxy ,如果是那會(huì) 不會(huì)影響集群中SVC勺使用？答：flannel/ovs 和kube-proxy的作用是不一樣的，可以看下 HYPERLINK http:/dock