透過三個典型代表暢談PaaS的前世今生
PaaS的前世今生
我們所熟悉的云計算分為3個層面：IaaS(基礎(chǔ)架構(gòu)即服務(wù))、PaaS(平臺即服務(wù))、SaaS(軟件即服務(wù))。與SaaS相比，PaaS和IaaS的概念相對較新，也是最近幾年云計算領(lǐng)域的集中發(fā)力點，像Amazon、微軟、谷歌、阿里云等還有很多初創(chuàng)公司都推出了IaaS和PaaS產(chǎn)品。
下面一張圖比較經(jīng)典的比較傳統(tǒng)IT、IaaS和PaaS：
目前市面上有很多PaaS平臺，我自己認為可以分為3個階段：
- ***代PaaS，比如Google App Engine、SAE，這是最早期的PaaS，當時并沒有PaaS這個概念，但是他們做的事情，現(xiàn)在看來是包含在PaaS范圍內(nèi)的。
- 第二代PaaS，比如 Cloud Foundry、OpenShift。這是各大IaaS流行之后，順勢推出的PaaS， 并且迅速發(fā)展。
- 第三代PaaS，比如Kubernetes。這是在Docker火爆之后，利用Docker的特性構(gòu)建出許多PaaS，這些PaaS更加靈活，更加適應(yīng)企業(yè)，逐漸成為PaaS的主力，我想也是很多人正在做的方向。
接下來給大家說明下剛才提到的幾個典型的項目， Cloud Foundry、Docker和Kubernetes，從中就可以看到幾代PaaS進化的技術(shù)驅(qū)動力。
Cloud Foundry
Cloud Foundry是VMware于2011年推出的業(yè)界***個開源PaaS云平臺，后來分拆出Pivotal公司進行接管，2014創(chuàng)立Cloud Foundry基金會，希望吸引更多的公司參與，而不是Pivotal一家獨大。
現(xiàn)在說的Cloud Foundry是V2架構(gòu)，它的結(jié)構(gòu)圖如下：
- Router：路由模塊，所有的數(shù)據(jù)面和管理面請求都通過Router進行分發(fā)。
- UAA/Login Server：鑒權(quán)模塊。
- NATS：消息總線， Cloud Foundry內(nèi)部組件的通信主要通過NATS進行通信。
- Cloud Controller(CC)：管理中心，負責應(yīng)用的生命周期管理等等。
- Health Manager：應(yīng)用的健康監(jiān)控狀態(tài)。
- DEA：應(yīng)用的運行時節(jié)點，應(yīng)用都是運行在DEA上。
- Warden：容器管理模塊，類似Docker，提供給應(yīng)用容器運行環(huán)境。
- Service Brokers：用于適配對接各類的第三方服務(wù)，可以是各種關(guān)系數(shù)據(jù)庫、中間件、緩存、云存儲、內(nèi)存數(shù)據(jù)庫等各種服務(wù)。
- Metrics Collector/App Log Aggregator：平臺應(yīng)用的日志和監(jiān)控數(shù)據(jù)收集。
Cloud Foundry推出以后逐漸得到了各大廠商的支持， 華為云、IBM BlueMix、 HP Cloud和Dell云服務(wù)都采用了 Cloud Foundry作為基礎(chǔ)，一時間成為PaaS的代表。那么 Cloud Foundry的優(yōu)勢有哪些呢?
開源、開發(fā)的架構(gòu)。 開源是趨勢， Cloud Foundry順應(yīng)了趨勢，自然可以吸引大批的開發(fā)者和公司參與其中。同時 Cloud Foundry是一個開發(fā)的架構(gòu)，定義了一套標準，可以擴展多種框架、語言、運行時環(huán)境及應(yīng)用服務(wù)，支持運行在云平臺IaaS上。
運維智能化。 運維能力是PaaS最最最最最重要的能力，這決定了PaaS的成功與否，如果PaaS無法提供強大的運維支持，為什么我要把應(yīng)用托管在PaaS，我需要看日志和監(jiān)控，我需要經(jīng)常升級應(yīng)用等等，IaaS可是提供了相當靈活的處理機制。 Cloud Foundry在這方面做出了很多努力，提供應(yīng)用的容錯容災(zāi)、彈性伸縮、負載均衡、安全控制、監(jiān)控日志的收集匯總等等。
容器。 這里不得不提容器技術(shù)，容器輕量、隔離的特性是非常適合PaaS的需求的， Cloud Foundry中開發(fā)了Warden組件來實現(xiàn)容器管理，實際上Warden和Docker類似，只不過 Cloud Foundry當時并沒有專注于容器這一塊，Warden在易用性和設(shè)計上都不如Docker，自然被Docker搶了風頭。
Cloud Foundry***的問題是它只能支持簡單的Web類應(yīng)用：應(yīng)用只能暴露一個HTTP端口，應(yīng)用之間通信也只能通過HTTP等等，這是因為 Cloud Foundry一開始的設(shè)計模型是比較簡單的，很多復(fù)雜場景應(yīng)該是沒考慮的，目前V3架構(gòu)Diego正在開發(fā)中，應(yīng)該有這方面的考慮。
總之Cloud Foundry最為第二代PaaS的代表，它在運作、架構(gòu)和技術(shù)上相比***代PaaS都有一定的提高，在云計算大潮中***了PaaS的發(fā)展，但是PaaS 一直處在一個不溫不火的尷尬程度，使用PaaS絕大多數(shù)是開發(fā)者個人的玩票性質(zhì)，真正使用的企業(yè)用戶其實很少。接下來Docker登場。
#p#
Docker
Docker是PaaS提供商dotCloud開源的高級容器引擎，Docker自2013年以來非?；馃幔?014年就已經(jīng)火得沒有朋友了。
這篇文章講Docker的由來的，蠻有趣的，有點無心插柳柳成蔭的意思。
關(guān)于Docker的好處，現(xiàn)在有許多文章都會說明，這里我講講個人的理解：
像很多文章提到的Docker快速敏捷(啟動、停止都是以秒或毫秒為單位的)，隔離輕量級(不添加額外的操作系統(tǒng))，這些實際上是Linux內(nèi)核提供的能力，Docker是沿用了這些特性，像Cloud Foundry的Warden也有這些能力，Docker***的創(chuàng)新點在于Docker鏡像的設(shè)計，下面是張Docker鏡像的層次圖，分層的文件系統(tǒng)，一層層地搭建出一個完整的容器運行環(huán)境：
這樣一來，我們可以像樂高玩具一樣搭建各式各樣的鏡像，同時Docker提供了一整套鏡像存儲方案(Docker Registry)，可以非常方便地獲取想要的鏡像，然后快速地啟動運行，而不必像以前那樣安裝各種麻煩的依賴軟件。
Docker 更像個微創(chuàng)新者，但是解決了***痛點，像Warden只解決了應(yīng)用運行的問題，而Docker解決了應(yīng)用的發(fā)布、構(gòu)建和運行，創(chuàng)建了很多想象空間，所以基于Docker衍生出了很多新的解決方案，特別是PaaS，即第三代的PaaS，Kubernetes是其中***代表性的一員，***講一下 Kubernetes。
Kubernetes
Kubernetes是Google開源的容器集群管理系統(tǒng)。它構(gòu)建Docker技術(shù)之上，為容器化的應(yīng)用提供資源調(diào)度、部署運行、服務(wù)發(fā)現(xiàn)、擴容縮容等整一套功能，本質(zhì)上可看作是基于容器技術(shù)的micro-PaaS平臺。
因為Docker解決了應(yīng)用編譯構(gòu)建的問題，所以Kubernetes架構(gòu)上就可以專注在容器編排，服務(wù)發(fā)現(xiàn)等等運維相關(guān)特性上，像Cloud Foundry就是花了很大精力在應(yīng)用編譯構(gòu)建上，集成了BuildPack，各種文件傳輸，效果其實不是特別好。
PaaS的價值不是在幫你編譯打包上，而是在于節(jié)省運維成本。
Kubernetes的設(shè)計模型我認為有幾個好的地方：
- Label的設(shè)計： Pod、Service、Replication Controller之間的是通過Label進行關(guān)聯(lián)，這是一種輕綁定的方式，可以方便地組合業(yè)務(wù)，做灰度升級等等。
- 網(wǎng)絡(luò)模型: Kubernetes采用扁平化的網(wǎng)絡(luò)模型，每個Pod都有一個全局唯一的IP(IP-per-pod)，Pod之間可以跨主機通信，相比于Docker 原生的NAT方式來說，這樣使得容器在網(wǎng)絡(luò)層面更像虛擬機或者物理機，復(fù)雜度整體降低，更加容易實現(xiàn)服務(wù)發(fā)現(xiàn)、遷移、負載均衡等功能。
Q&A
問：開源勢必引入安全問題。Cloud Foundry的安全保護機制?
答：Cloud Foundry對于應(yīng)用有個安全組的特性，可以控制應(yīng)用容器的訪問。但是實際上能力不強，容器安全這塊一直是被擔心的地方。
問：Cloud Foundry的DEA，即應(yīng)用的運行時節(jié)點，是虛擬的操作系統(tǒng)么?Warden對底層的操作系統(tǒng)有和要求?Warden如何實現(xiàn)的隔離性?
答：DEA是個服務(wù)，其實還是Linux系統(tǒng)Warden對內(nèi)核有要求，實現(xiàn)原理和Docker類似。
問：va/spring/web 應(yīng)用很容易在Docker/Kubernetes環(huán)境運行，如果要遷移到CF，工作量大嗎?
答：CF V2工作量應(yīng)該挺大，V3的話因為支持Docker，所以還好。
問：關(guān)于k8s中Flannel和Weave兩者哪個更適合生產(chǎn)環(huán)境?
答：這個我最近正在分析，感覺Flannel和Weave都還不成熟，推薦OVS。
問：Docker既然是namespace隔離的，就算不安全應(yīng)該也影響不是很大吧?
答：其實如果你清楚原理，很容易進入到容器環(huán)境中的，沒辦法，安全是個大問題。
問：k8s可以實現(xiàn)應(yīng)用的自主遷移嗎?
答：目前沒有Pod遷移的API。
問：CloudFoundary中監(jiān)控部分有插件機制么?
答：支持導(dǎo)入到各種第三方監(jiān)控系統(tǒng)。
問：Pod直接通信需要開通隧道么?換句話說他們之間是如何實現(xiàn)通信的?
答：容器跨主機的通信，是對Docker的增強，像Flannel、ovs等。
問：PaaS的三個典型代表： Cloud Foundry、Docker和Kubernetes，最近的DaoCloud、靈雀云、時速云等以Docker為核心提出了新的CaaS概念。CaaS 和PaaS都使用了Docker，Kubernetes等技術(shù)，您是怎么理解PaaS和CaaS的?
答：CaaS容器即服務(wù)，我的理解就是PaaS，只不過主打這Docker容器，所以叫CaaS。
問：Docker在CentOS上使用devicemapper，據(jù)說容易使系統(tǒng)crash，對于其他的文件系統(tǒng)有沒有推薦，brtfs和aufs哪個更好?
答：aufs是內(nèi)核不接受的，聽說是因為代碼太亂。
問：對于管理Docker這件事情，除了Kubernetes， OpenStack(IaaS陣營)， YARN(Hadoop陣營)也開始發(fā)力，怎么看待這幾者間的競爭?
答：沒有任何技術(shù)是銀彈，不同需求不同設(shè)計。當然大家都想占據(jù)制高點了，這就是運作了。
問：k8s現(xiàn)在具備auto scaling能力嗎，比如應(yīng)用響應(yīng)時間變長，k8s可以自動擴容?
答：沒有。
問：如果將Flannel替換成ovs是不是也可以替換掉kube-proxy，如果是那會不會影響集群中SVC的使用?
答：flannel/ovs和kube-proxy的作用是不一樣的，可以看下http://dockone.io/article/545。
