有容云：容器驅動的PaaS平台實現方案（上）

編者注:

本文基於上海容器大會現場演講內容，立足於實戰跟大家分享了新一代PaaS平台構建中遇到的問題、當下主流PaaS平台解析、企業交付經驗及心得體會等。文章較長，分為上、下兩個部分，本文為上篇。

 

嘉賓介紹：

馬洪喜，有容雲聯合創始人兼首席架構師。此前擔任Rancher Labs中國區技術負責人、Citrix公司資深架構師、Oracle公司虛擬化產品開發經理等職務，在容器雲、IaaS雲、案頭雲建設方面擁有較為豐富的經驗。

本次大會的大部分朋友都是以使用者身份分享了自己家的故事和經驗，我作為廠商代表之一，首先是想從一個大的面上跟大家交流下各方面的知識點，另外也給大家分享下我們遇到的別人家的故事，相信對大家有一定借鑒的意義。

 

下面我們進入主題。早上樑博士（編者：指Rancher Labs CEO梁勝博士）也說了，PaaS是一個老的概念了，發展到現在有老一代PaaS也有新一代PaaS，其中新一代我管它叫容器驅動的輕量級PaaS。當下業界我們能看到的一種趨勢，大家都在逐漸擯棄老的PaaS技術而擁抱容器驅動的新一代輕量級PaaS。就拿一個我們華南地區的金融客戶來說，他們想做一個比DevOps範疇還大的開發營運系統，他們請來了傳統PaaS廠商，但是需求始終沒能得到滿足。後來我跟他們負責人聊的時候就介紹了容器驅動的新一代的輕量級PaaS，或者說是CaaS，然後發現跟他們的需求就配套了。這是一個非常典型的代表。還有一家位於北京的全國性商業銀行，跟他們聊的時候他們也在猶豫是採用老一代的PaaS技術還是直接用容器，後來交流了容器驅動的輕量級PaaS技術之後他們就沒再邀請傳統PaaS廠商來測試了，所有入圍測試的都是基於Docker容器技術的廠商。這是一些客戶的情況。那麼為什麼會出現這種情況呢。

通過這張膠片大家可以看到，老一代PaaS技術下的產品有一個特點就是非常重，封閉性比較強。當然，這之中有開源版本也有商業版本，但是如果選擇商業版本的的話你不得不等待它的版本和組件發布步調，比如等待一個新版本的Redis組件，程式員都不太喜歡封閉性的東西。而新一代的容器技術無論是基於Kubernetes還是Mesos還是其它技術，它的一個特點就是更輕量，更開放，而程式員會感覺自己在裡面可以有貢獻，有一種參與感，這是他們的一個區別。所以我們看到，現在的客戶有很多都有這種新一代PaaS的需求，很多企業在選擇的時候都會考慮以容器為基礎的PaaS。有趣的是有些企業可能前兩年已經採購了傳統PaaS產品，但是今年他們還是會去看看新一代採用容器技術的PaaS到底能給他帶來哪些便利。大家都相信未來是採用容器技術實現PaaS的方向，那大家在選擇這種容器的PaaS方案或廠商時會重點關注哪些問題呢。我可以給大家稍微分享一下。

某世界500強保險集團

 

1. 開源方案，簡單易用 - 這其實也是業界一種共識。你可以是純粹的開源，也可以是商業開源。所謂商業開源，就是說你可以不是Apache或GPL協議發布，但是你承諾向客戶開放所有原始碼等，這也是一種開源的形式。

 

2. 需求匹配度高，API豐富，可定製化 – 他們的另外一個要求就是你一定要有非常豐富的API介面。我不一定會用你的portal，但可能我需要做一些功能非常豐富的整合，所有你介面上有的功能API一定都要能實現，甚至說有些隱藏的功能是介面上沒有，但是API裡一定要有。

 

3. 服務團隊能力強 - 服務團隊的交付能力不僅僅是廠商或是服務供應商，也包括客戶自有團隊或者說自有團隊跟廠商之間形成的合作和默契。

 

 某全國性股份制商業銀行

 

1. 容器管理能力強 - 構建在容器上的PaaS平台，需要容器的管理能力非常強，容器調度、編排策略需求比較豐富。

 

2. PaaS能力快速上線 - 最好客戶團隊自己就可以快速開發出構建在基於容器之上的PaaS能力模組，不需要依賴於廠商的發布周期。

 

3. Application Configuration Manangement功能豐富 - 我的應用程式配置，比如說我的CI、CD部署參數並非都一樣，在開發、測試、生產等環境不也各有不同。所以我的應用程式有大量的定製化需求，客戶希望平台可以提供靈活的應用配置參數，哪怕是Java棧的記憶體參數也好，總之應用程式的參數一定要可定製化。

 

某通訊方案提供者

 

還有某通訊方案提供者，看看他們的關注點：

 

容器網路、儲存，灰階發布等 - 他們要求比較細節，首先一點容器網路要求比較高，其次在容器的情境上構建PaaS時我儲存的問題怎樣解決。還有一個是灰階發布，也是比較領先的課題，包括另外一個某銀行客戶，他們也提出了這個要求，他們希望應用到的是什麼情境呢。比如我想把最新的版本只發送給深圳的IP，而其他地區IP訪問還是舊版本，或者是想把新版本只給IT中的某個部門訪問，但是其他部門訪問的還是舊版本。所以也討論到是否可以採用比如來源IP，或者用訪問標籤來做標識和區分。其實對廠商來講我們可以在不同客戶那裡聽到很多新的的需求，而這些需求可以不斷融入到我們產品中來。

 

某省科技廳醫學大資料項目

 

另外這是某省科技廳醫學大資料項目的關注點。我們可以想象，把所有醫院血液的大資料都聚集在一起，做一個健康大資料系統，做一些腫瘤早期的預測，某些疾病的篩查等，這是非常有意義的。他們不僅僅是要構建一個PaaS的大資料平台，他們也希望基於容器技術搭建，他們有什麼需求呢。

 

1. 混合雲能力構建-他們想借力類似國內阿里、騰訊這樣的公用雲端來運作他們的大資料分析系統；

 

2. 容器資料存放區，大資料與容器結合-他們希望這個PaaS平台在大資料方面有比較大建樹，具備大資料分析能力比較強的特點；

 

3. 本地交付團隊-便於隨時交流和提供支援人員。

 

以上是我列舉的不同行業客戶對構建PaaS平台的需求。那我們的理解是什麼呢。

我們通過大量的客戶交流、客戶交付做了一個總結：項目能成功的因素至少有這兩點，首先是基於一個優良的架構或者是產品去做你的事情，大部分使用者不可能說是完全白手起家，基於Docker就去做，另一方面是比較強的服務交付團隊，無論是自己的還是邀請夥伴協作的團隊，至少這兩點都是不可或缺.

 

大家知道，對於Docker來說，它本身只是幾十兆的幾個安裝包，本身只提供了一個命令列的方式，當然現在也提供了Docker Swarm可以實現叢集管理 ,但是在生產中還是需要一個容器的管理平台。這樣我們通過一個Docker核心的Engine加上一個容器管理平台就構成了完整的Container Service。Container as a Services只是容器應用情境的一部分而已，他並不等於一個完整的PaaS平台,PaaS的範疇比它要大很多。在我們的定義中，一個完整的PaaS應該包括一個很好的容器管理平台作為堅實的基礎，上層有部署流水線、大資料、中介軟體等PaaS能力外掛程式，這我們稱之為構建PaaS的基礎，但其實這距離企業完整的PaaS需求還不夠，還需要一個交付團隊去補充。

 

我們到一家客戶去聊的時候他們就表示，你上頭搞的portal我並不關心，上面所有的東西我都需要跟我的系統做一些對接，所以你們要保證你們產品內件有比較好的機制，豐富的API介面，團隊要有能力，能跟我們一起構建符合我們需求的PaaS平台。大家知道，開箱即用的PaaS平台可能並不能滿足每個企業的個人化需求，所以構建PaaS有很多個性的需求。

今天我們也看到，很多朋友基於Swarm，Kubernetes、Mesos做了PaaS技術分享，也有一些基於Rancher或者是我們有容雲AppSoar的PaaS技術分享。我列出這張圖來並非做一個優劣的對比，而是做一個比喻。最著名的三劍客Swarm、Mesos、Kubernetes，它們好比發動機的引擎技術，而Rancher、AppSoar、OpenShift等他們是基於引擎技術之上構建的範圍更廣的產品或者說平台。可能有些使用者會說，ok，我不想花更多的心思去組裝發動機、輪子、方向盤，我只是想買一輛直接就能開的車；也有一些使用者會說我想要有一些靈活的定製化，我希望配置出來的是一個我最喜歡的效能狀態，比如底盤調試等各種都是按照我的意願來組裝的。所以我們這張圖就是告訴大家，在選擇的時候存在這樣兩種趨勢。

 

我花點時間跟大家談下我對三種架構的一個粗淺認識。之前也跟梁博士有過交流，這三種技術短時間內暫時還不會出現誰幹掉誰的局面，但是就我個人的觀點來看，大家選擇Kubernetes，或者Docker  Swarm的時候，至少這兩種是一個完全的不同的路線，並不是從技術層面來說，而是非技術角度。圈裡人都聽過，不管是Kubernetes社區還是Docker社區，兩者之間是一種PK的關係，包括對網路棧的支援。很有意思的一個故事， Kubernetes之前發了一篇文章說為什麼我們不支援Docker的CNM結構而支援CNI，未來會有更多Docker已有的功能 Kubernetes沒有，但是Kubernetes會拿另外一種東西來做補充。這就是兩個社區背後相關利益既得者，他們的想法不一樣。

 

比如說Kubernetes，他們想做的事是未來大家只要用Kubernetes就好，至於底層你採用的Engine、到底是Rocket 還是Docker，你不用關心，你只需要知道Kubernetes就好。對Docker來說，主要的優勢是他們有大量使用者基礎。所羅門曾在一次技術採訪被問到面對Google這樣強大的競爭者是否有壓力時，所羅門的回答是我們並不懼怕任何困難和挑戰，因為90%以上的容器使用者只用Docker。大家也可以看到，Docker馬上就會有自己的生態系統，它會逐步壯大起來。雖然今天的Swarm還相對弱小，但是大家會看到他會逐漸強大起來，所以說對於Rancher也好，對於我們有容雲自己也好，我們的選擇都是不選邊不站隊，都支援。

下面我們來談下整個CaaS架構的樣本。本樣本雖然是基於我們自有的產品，但是我會用一種通用的方式來告訴大家是什麼意思。簡單來說，我想用這幅圖來告訴大家一個完整的容器管理系統他應該包含哪些方面的功能。首先一點就是對底層多主機的管理。可能有人會說，大部分平台都支援多主機管理，但我相信有一天，我們需要的是一個混合雲的狀態，我們希望企業在應對我們業務的時候，可以像流水一樣把我們的業務任意在企業私人雲端、或者租用的公用雲端之間漂移。

 

比如平時我的業務都部署在私人雲端上，遇到特殊活動比如雙十一雙十二，充紅包、促銷等時候我們擴充出來的業務可以自動遷移到公用雲端上，而且遷移的流量入口也可以從公用雲端那裡進來。未來如果企業要想達成這些能力，Docker是一個非常好的技術組件去完成這件事，但是我們一定要選擇一個合適的平台，在未來或者說今天可以很好的管理混合雲業務情境的模型。

 

在這基礎之上我們有不同方式會對租戶或者說業務情境的切割，例如測試、生產等環境的資源等進行切割，實作類別似於“多租戶”的管理。之前聽了一些朋友關於儲存、網路的介紹，都講得非常好，大家也意識到，容器時代我們面臨的來自儲存、網路的挑戰跟虛擬機器時代是一樣的。並不能說，虛擬機器時代我們踩過的坑比如說在VMware上的標準交換器、分布式交換器已經做得很好，自然在容器時代就這些問題都得到瞭解決。其實