一個平臺的誕生必定是經(jīng)年錘煉而來，即從應(yīng)用程序中提取通用的功能到更底層的抽象中。如果完成了既定的設(shè)計(jì)意圖，那么您將得到一個可用的平臺，反之，您將得到一個“燙手山芋”，既而您將再次尋找合適的平臺，這時候您會發(fā)現(xiàn)別人已經(jīng)構(gòu)建好的平臺給您帶來了一線希望的曙光。

正確的平臺，您將在靈活性和簡單性之間達(dá)到您所需要的平衡，從而使您能夠更快速地構(gòu)建而不受太多限制。本文將探討云平臺的范圍，以幫助您找到最適合您的那一款。

對于什么樣的平臺才是完美的，每個人有每個人的看法，因?yàn)槊總€人的使用場景有所不同。但是幾乎所有人都尋求以下兩個特征：

• 提高開發(fā)速度

• 自動化運(yùn)維

這兩個要求推動了大多數(shù)軟件平臺的進(jìn)化。真的，這兩項(xiàng)可以作為自動化檢驗(yàn)標(biāo)準(zhǔn)：速度和可重復(fù)性。

所以，沒有一個平臺對于任何用戶來說是完美的，那么是否意味著我們要自己寫呢？如果自己寫，是否建立在一個現(xiàn)有的平臺之上？您想要一個從上到下的緊密集成的平臺，還是想要使用強(qiáng)大的擴(kuò)展點(diǎn)松散連接的多層平臺？

這些都是一時間難以回答的問題，并沒有一個真正適合每個人的單一答案。尋找合適平臺的成就感是發(fā)現(xiàn)，比較和權(quán)衡之一。所以我們一起來吧！

云平臺的“彩虹”，總有您喜歡的色彩。

每個廠商都會告訴你，他們的軟件是特別的，甚至是獨(dú)一無二的。他們都在努力使自己的產(chǎn)品與眾不同，以提供不可替代的價值。但是，如果您仔細(xì)觀察，并容忍一些粗糙的地方，您可以根據(jù)它們提供的接口類型對這些產(chǎn)品進(jìn)行分組。???

云平臺的示例

“軟件即服務(wù)”一詞最早可追溯到2000年左右，指的是將打包的軟件產(chǎn)品和支持服務(wù)捆綁在托管解決方案中，以避免經(jīng)常未知的執(zhí)行和操作成本。一個SaaS產(chǎn)品本身就是一個基礎(chǔ)平臺。SaaS的一些原始用途取代了傳統(tǒng)企業(yè)資源計(jì)劃（ERP）和客戶關(guān)系管理（CRM）平臺。

像Salesforce和SAP這樣的公司，對于那些沒有大型工程師團(tuán)隊(duì)或IT部門來構(gòu)建和管理這些復(fù)雜的系統(tǒng)客戶，他們會在這些領(lǐng)域非常成功。即使是擁有這些資源的公司也可能認(rèn)為這些事情不在其核心競爭力范圍之內(nèi)，不值得自己去建設(shè)或經(jīng)營。如今幾乎所有類別的軟件都可以通過SaaS獲得，從電子郵件到文字處理系統(tǒng)，再到內(nèi)容管理系統(tǒng)比比皆是。

Spectrum的另一方面是基礎(chǔ)設(shè)施即服務(wù)。

將應(yīng)用程序配置到基礎(chǔ)架構(gòu)平臺上

基礎(chǔ)設(shè)施平臺在SaaS之后不久就出現(xiàn)了。VMware GSX Server（2006）和亞馬遜彈性計(jì)算云（EC2，2006）提供了早期的虛擬化平臺。然而，VMWare最初專注在企業(yè)內(nèi)部部署，亞馬遜web服務(wù)則將其托管的IaaS和SaaS產(chǎn)品結(jié)合，定位于更廣闊的市場。后來，Rackspace和美國航天局開發(fā)了OpenStack（2010）作為VMware vSphere（2009年發(fā)布，取代GSX）和亞馬遜EC2的開源競爭對手。

這些IaaS主要提供了一些具體的抽象：虛擬機(jī)計(jì)算節(jié)點(diǎn)，軟件定義的網(wǎng)絡(luò)和可掛載的存儲。在有SaaS的情況下，托管的IaaS的主要賣點(diǎn)是外部資源容量配置操作的自動化，但與SaaS不同，托管的IaaS會給用戶帶來資源規(guī)模無限大的錯覺。對于大多數(shù)對基礎(chǔ)設(shè)施外包感興趣的公司來說，AWS會提供比客戶以往任何時候資源需求量大得多的資源，在您向AWS尋求更多節(jié)點(diǎn)之前，已經(jīng)擴(kuò)展了數(shù)據(jù)中心。對于無法或者不愿意外包的公司，像OpenStack和vSphere這樣的基礎(chǔ)設(shè)施平臺可以在您選擇的數(shù)據(jù)中心中托管自己的云。

然而，管理不僅僅只是涉及硬件，還包括管理一個基礎(chǔ)設(shè)施平臺，并且這需要更多的工作，這是企業(yè)公司已經(jīng)在自己的平臺上做過的。無論是手動管理沒有虛擬化層的硬件，還是渴望使配置更加自主化。因此，as-a-service模型又回到了起點(diǎn):承載的平臺變成了打包產(chǎn)品，這次添加了多租戶功能，允許客戶為自己的內(nèi)部用戶組操作它。

隨之而來的應(yīng)用平臺。

基礎(chǔ)架構(gòu)平臺上的應(yīng)用平臺

Fotango的Zimki（2006）和Heroku（2007）率先使用平臺即服務(wù)。后來的Google App Engine（2008），CloudFoundry（2011）和其他幾個加入了戰(zhàn)斗。在當(dāng)時，很明顯，這些是真正的應(yīng)用平臺（aPaaS），專門用于加快開發(fā)人員的速度并降低運(yùn)營開銷。使得開發(fā)人員自己配置和管理他們開發(fā)的應(yīng)用，進(jìn)一步壓縮了從開始到發(fā)布到反饋到迭代的周轉(zhuǎn)時間，與日益普及的敏捷軟件開發(fā)思想相契合，并為剛剛起步的DevOps運(yùn)動播下種子。

但進(jìn)步永遠(yuǎn)不會停止。容器平臺出現(xiàn)了。

基礎(chǔ)架構(gòu)平臺上的容器平臺

容器化已經(jīng)比您想象得要深入（FreeBSD Jails自2000年以來一直在使用），但是可以肯定的是直到Docker（2013）將Linux操作系統(tǒng)級虛擬化與文件系統(tǒng)鏡像結(jié)合起來，容器化才真正廣泛流行起來。這使得構(gòu)建和部署容器化應(yīng)用更加容易，這是一種可以理解為通過構(gòu)建磁盤鏡像來加快基礎(chǔ)設(shè)施平臺配置的IaaS用戶模式。但與VM相比，同時運(yùn)行的幾臺驅(qū)動器足以讓您的工作站超負(fù)荷運(yùn)行，容器則允許您在本地部署完整的微服務(wù)堆棧，大大加快了開發(fā)周期。另外，由于降低了開銷，每個微服務(wù)器都可以擁有自己的容器映像，自己的發(fā)布周期和自己的滾動升級，允許更小的團(tuán)隊(duì)并行開發(fā)它們。

從容器運(yùn)行時到容器平臺，這是一個明顯的進(jìn)步。像CloudFoundry這樣的應(yīng)用平臺和像Apache Mesos這樣的集群資源管理系統(tǒng)自成立以來就一直使用容器隔離。下一步是開放一個平臺API，允許開發(fā)人員在一組機(jī)器上部署越來越受歡迎的Docker鏡像。像基礎(chǔ)設(shè)施平臺一樣，容器平臺也是在內(nèi)部開始的，后來提供托管服務(wù)。Mesosphere的Marathon（2013）是通用容器編排的首個開源平臺之一，但它早期是由內(nèi)部努力推動的，比如Google的Borg（?2004）和Twitter的Aurora（2010年寫成，在2013年開放為Apache Aurora）。

容器編排是容器平臺的核心。與應(yīng)用平臺一樣，容器平臺需要提供基于約束的聲明性調(diào)度。與應(yīng)用平臺不同的是，容器不限于十二要素應(yīng)用程序。比如，有狀態(tài)服務(wù)需要的持久卷，隔離保證機(jī)制，特定域的遷移過程及并行的備份作業(yè)等等。由于這種靈活性，容器平臺可以輕松地變得比應(yīng)用程序平臺更復(fù)雜，以支持更多種類的工作負(fù)載。

計(jì)算機(jī)集群上的容器平臺

為了增加靈活性，并且在不遷移的情況下支持傳統(tǒng)工作負(fù)載，許多人在基礎(chǔ)設(shè)施平臺之上運(yùn)行容器平臺，但這并不是絕對必要的。容器與單個機(jī)器已經(jīng)十分接近，幾乎所有的工作負(fù)載都是兼容的。所以并不是每個人都需要這種靈活性。許多開發(fā)人員將他們所有的時間都花在單層的堆棧中。他們尋找避免重復(fù)執(zhí)行任務(wù)的辦法，例如為他們構(gòu)建的每個新應(yīng)用程序手工制作容器鏡像。對于這些人來說，功能平臺（也稱為無服務(wù)器）就出現(xiàn)了。

亞馬遜推出了AWS Lambda（2014），引領(lǐng)了無服務(wù)的“熱潮”，在其虛擬基礎(chǔ)設(shè)施平臺之上提供輕量級的容器化事件處理。像其他Amazon Web Services一樣，Lambda僅僅只是一種托管服務(wù)。因此，由Iron.io（2014），Apache OpenWhisk（2016），F(xiàn)ission（2016），Galactic Fog的Gestalt（2016），OpenLambda（2016）填補(bǔ)了私有化部署替代品的市場。

除了他們各自基于特定語言的框架之外，功能平臺的運(yùn)行方式與應(yīng)用平臺相同。因此，開發(fā)人員只需要開發(fā)事件處理程序，并使用平臺API將觸發(fā)器映射到該處理程序即可，而不是使用多個端點(diǎn)編寫應(yīng)用程序。功能平臺通常與API網(wǎng)關(guān)配合或集成，以處理代理，負(fù)載均衡和集中式服務(wù)發(fā)現(xiàn)。與應(yīng)用平臺不同，功能平臺透明地集成了基于負(fù)載的自動縮放，因?yàn)樗鼈兛刂扑腥肟邳c(diǎn)和復(fù)用。

像容器平臺一樣，功能平臺不一定需要基礎(chǔ)架構(gòu)平臺，但與容器平臺提供的靈活性不同，功能平臺不是設(shè)計(jì)用于支持各種各樣的工作負(fù)載。所以僅僅只運(yùn)行一個功能平臺可能是不明智的或不可能的。您可能還需要一個較低級別的容器或基礎(chǔ)架構(gòu)平臺。一些功能平臺甚至被設(shè)計(jì)成與容器平臺集成，利用中間層自動化來降低較高層的復(fù)雜性。

云平臺，它們的接口和抽象規(guī)模

這些平臺中的每一層都提供了自己獨(dú)特的抽象和API，某些層比其他層更抽象。一些更高層級的平臺要么全部采用，要么就全不用。它們具有頂部到底部的集成，但只能支持您要運(yùn)行的一小部分工作負(fù)載。您可能會嘗試選擇最高層的抽象化來最大限度地提高開發(fā)人員的速度，但是您也必須考慮到這些平臺上構(gòu)建的軟件將與平臺最緊密耦合，當(dāng)您需要重新選擇平臺的時候， 這將增加您的風(fēng)險。另一方面，較低級別的平臺可以提供最大的靈活性，可以實(shí)現(xiàn)最廣泛的工作負(fù)載，包括Web應(yīng)用程序，微服務(wù)器，整體架構(gòu)應(yīng)用，數(shù)據(jù)管道和數(shù)據(jù)存儲服務(wù)。它們使得遷移更輕松和基礎(chǔ)設(shè)施操作更容易，但是在上面實(shí)際開發(fā)或運(yùn)維應(yīng)用程序，服務(wù)或作業(yè)卻更難。

應(yīng)用平臺和基礎(chǔ)設(shè)施平臺之間的沖突是容器平臺受歡迎的重要原因之一。容器平臺在這兩方面作出了妥協(xié)。它們允許您根據(jù)每個容器來決定您的工作負(fù)載是否需要自己的環(huán)境，或者可以作為二進(jìn)制運(yùn)行，支持更多種類的工作負(fù)載。但它們還像應(yīng)用程序平臺一樣提供聲明式配置，生命周期管理，復(fù)制和調(diào)度。如果您還需要更高層次的抽象，您可以輕松地在容器平臺之上部署更輕量級的應(yīng)用程序或功能平臺，共享具有較低級別工作負(fù)載的資源和機(jī)器。如果您還需要較低級別的抽象，您可以輕松地在基礎(chǔ)設(shè)施平臺之上部署容器平臺，而不是直接使用裸機(jī)。

DC / OS架構(gòu)層

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：

長按訂閱更多精彩▼
如有收獲，點(diǎn)個在看，誠摯感謝