透過(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)是包含在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 Foundry
Cloud Foundry是VMware于2011年推出的業(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ò)NATS進(jìn)行通信。
- Cloud Controller(CC)：管理中心，負(fù)責(zé)應(yīng)用的生命周期管理等等。
- Health Manager：應(yīng)用的健康監(jiān)控狀態(tài)。
- DEA：應(yīng)用的運(yùn)行時(shí)節(jié)點(diǎn)，應(yīng)用都是運(yùn)行在DEA上。
- Warden：容器管理模塊，類(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)商的支持， 華為云、IBM BlueMix、 HP Cloud和Dell云服務(wù)都采用了 Cloud Foundry作為基礎(chǔ)，一時(shí)間成為PaaS的代表。那么 Cloud Foundry的優(yōu)勢(shì)有哪些呢?
開(kāi)源、開(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)控日志的收集匯總等等。
容器。 這里不得不提容器技術(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)單的Web類(lèi)應(yīng)用：應(yīng)用只能暴露一個(gè)HTTP端口，應(yīng)用之間通信也只能通過(guò)HTTP等等，這是因?yàn)?Cloud Foundry一開(kāi)始的設(shè)計(jì)模型是比較簡(jiǎn)單的，很多復(fù)雜場(chǎng)景應(yīng)該是沒(méi)考慮的，目前V3架構(gòu)Diego正在開(kāi)發(fā)中，應(yīng)該有這方面的考慮。
總之Cloud Foundry最為第二代PaaS的代表，它在運(yùn)作、架構(gòu)和技術(shù)上相比***代PaaS都有一定的提高，在云計(jì)算大潮中***了PaaS的發(fā)展，但是PaaS 一直處在一個(gè)不溫不火的尷尬程度，使用PaaS絕大多數(shù)是開(kāi)發(fā)者個(gè)人的玩票性質(zhì)，真正使用的企業(yè)用戶(hù)其實(shí)很少。接下來(lái)Docker登場(chǎng)。
#p#
Docker
Docker是PaaS提供商dotCloud開(kāi)源的高級(jí)容器引擎，Docker自2013年以來(lái)非?；馃幔?014年就已經(jīng)火得沒(méi)有朋友了。
這篇文章講Docker的由來(lái)的，蠻有趣的，有點(diǎn)無(wú)心插柳柳成蔭的意思。
關(guān)于Docker的好處，現(xiàn)在有許多文章都會(huì)說(shuō)明，這里我講講個(gè)人的理解：
像很多文章提到的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)境：
這樣一來(lái)，我們可以像樂(lè)高玩具一樣搭建各式各樣的鏡像，同時(shí)Docker提供了一整套鏡像存儲(chǔ)方案(Docker Registry)，可以非常方便地獲取想要的鏡像，然后快速地啟動(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。
Kubernetes
Kubernetes是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)。
因?yàn)镈ocker解決了應(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ò)模型，每個(gè)Pod都有一個(gè)全局唯一的IP(IP-per-pod)，Pod之間可以跨主機(jī)通信，相比于Docker 原生的NAT方式來(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)的隔離性?
答：DEA是個(gè)服務(wù)，其實(shí)還是Linux系統(tǒng)Warden對(duì)內(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和Weave都還不成熟，推薦OVS。
問(wèn)：Docker既然是namespace隔離的，就算不安全應(yīng)該也影響不是很大吧?
答：其實(shí)如果你清楚原理，很容易進(jìn)入到容器環(huán)境中的，沒(méi)辦法，安全是個(gè)大問(wèn)題。
問(wèn)：k8s可以實(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都使用了Docker，Kubernetes等技術(shù)，您是怎么理解PaaS和CaaS的?
答：CaaS容器即服務(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陣營(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的作用是不一樣的，可以看下http://dockone.io/article/545。
