云計(jì)算常態(tài)化意味著云應(yīng)用的常態(tài)化

　　相信大家都聽(tīng)過(guò)這句話，叫做“云計(jì)算常態(tài)化”。

　　在三年前，云計(jì)算在中國(guó)還只是一個(gè)概念，近年來(lái)，這個(gè)火熱的概念轉(zhuǎn)為實(shí)際，我們也幫助越來(lái)越多如銀行、保險(xiǎn)、證券這樣的大型企業(yè)客戶實(shí)現(xiàn)云計(jì)算項(xiàng)目的真實(shí)落地。如此來(lái)看，云計(jì)算已經(jīng)常態(tài)化了。

　　云計(jì)算常態(tài)化，就意味著云應(yīng)用要常態(tài)化。

　　在我們跟企業(yè)客戶交流時(shí)發(fā)現(xiàn)，客戶希望我們能 把中間件都搞定，讓他們不用操心安裝和運(yùn)維問(wèn)題，從而能把更多的精力投入應(yīng)用。如果我們像過(guò)去一樣只提供云主機(jī)和網(wǎng)絡(luò)，已經(jīng)遠(yuǎn)遠(yuǎn)不能滿足用戶的需求了。而青云的愿景是云計(jì)算要像水電一樣服務(wù)于大眾，所以我們要去解決水電運(yùn)輸問(wèn)題，讓用戶只需要關(guān)心電器。

　　云應(yīng)用常態(tài)化，意味著云化應(yīng)用是一個(gè)極低的門(mén)檻。云化應(yīng)用門(mén)檻如果太高，那么成為常態(tài)化就不是一件容易的事情。

　　降低門(mén)檻，也意味著要有標(biāo)準(zhǔn)化的平臺(tái)，企業(yè)的應(yīng)用云化過(guò)程才能變得簡(jiǎn)單。

　　關(guān)于架構(gòu)的演變，我們?cè)谶^(guò)去兩年切身體會(huì)到很多內(nèi)容，可以分為以下三個(gè)階段：

　　但每個(gè)應(yīng)用還是單獨(dú)開(kāi)發(fā)的，主要原因是應(yīng)用之間千差萬(wàn)別，體系架構(gòu)各不相同。比如說(shuō)應(yīng)用配置文件的定義都不一樣，所以每個(gè)應(yīng)用都需要單獨(dú)開(kāi)發(fā)。

　　在這個(gè)標(biāo)準(zhǔn)云化平臺(tái)上，企業(yè)開(kāi)發(fā)云應(yīng)用的時(shí)候，不用關(guān)心需要什么樣的技術(shù)，同時(shí)可以簡(jiǎn)單、快速地云化應(yīng)用。它的特征是高度抽象，高度標(biāo)準(zhǔn)化。簡(jiǎn)單地說(shuō)，企業(yè)在云化應(yīng)用的時(shí)候，可按照標(biāo)準(zhǔn)批量生產(chǎn)各類云應(yīng)用。以后云技術(shù)就不再是企業(yè)核心了，而應(yīng)用本身才是核心。

　　這會(huì)使得最終競(jìng)爭(zhēng)的是應(yīng)用本身，而不是云計(jì)算平臺(tái)。這里的含義是，如果青云的工程師和青云的合作伙伴，在 AppCenter 2.0 上各自開(kāi)發(fā)一個(gè)云應(yīng)用，青云工程師作為云平臺(tái)的提供者來(lái)說(shuō)沒(méi)有任何獨(dú)特優(yōu)勢(shì)，因?yàn)橛玫氖峭�一個(gè)平臺(tái)。比如，雙方都要做一個(gè) Hadoop，比的是誰(shuí)有更深厚的經(jīng)驗(yàn)，能夠把這個(gè)應(yīng)用做得更好，調(diào)優(yōu)調(diào)得更好，彼此PK的是應(yīng)用本身。

　　標(biāo)準(zhǔn)化平臺(tái)設(shè)計(jì)的思考

　　標(biāo)準(zhǔn)化平臺(tái)設(shè)計(jì)的難點(diǎn)

　　有的集群是沒(méi)有角色的，有的是有一主一從的，也有一主多從的，或者多主多從的，甚至分片的多主多從。

　　此外，每個(gè)應(yīng)用的集群管理方式也是多樣化的。每個(gè)應(yīng)用的生命周期如何管理，比如啟動(dòng)集群、停止集群，如何運(yùn)行這些命令，都不一樣，這非常復(fù)雜，也給標(biāo)準(zhǔn)化平臺(tái)帶來(lái)一些難度。

　　有些應(yīng)用的配置與某類角色有關(guān)，同時(shí)如何實(shí)現(xiàn)應(yīng)用配置自動(dòng)變更，如何存儲(chǔ)這些信息，這都是難點(diǎn)。

　　AppCenter 2.0 不僅僅是解決集群自動(dòng)化部署、自動(dòng)化運(yùn)維這個(gè)層面，還會(huì)成為一個(gè)生態(tài)，每個(gè)組件之間能夠互相感知。比如說(shuō)企業(yè)應(yīng)用有一個(gè) Kafka，當(dāng) ZooKeeper 節(jié)點(diǎn)發(fā)生改變時(shí)，Kafka 能否自動(dòng)感知到該變化。

　　一般的做法是把這些信息手動(dòng)改一下，并重啟 Kafka 服務(wù)。標(biāo)準(zhǔn)化平臺(tái)能否自動(dòng)化這個(gè)過(guò)程，即在 ZooKeeper 加節(jié)點(diǎn)時(shí)不需要手動(dòng)操作，Kafka 可自動(dòng)更新配置、自動(dòng)重啟，服務(wù)照樣運(yùn)行。使服務(wù)之間互相感知，也是一個(gè)難點(diǎn)。

　　應(yīng)用既然云化，就要滿足云彈性伸縮的特征。當(dāng)把沒(méi)有彈性伸縮能力的傳統(tǒng)軟件搬到云上時(shí)，AppCenter 2.0 需要解決這個(gè)問(wèn)題。這樣一來(lái)，第三方合作伙伴用 AppCenter 2.0 平臺(tái)云化應(yīng)用的時(shí)候，不用寫(xiě)代碼，只需按照 AppCenter 2.0 的規(guī)范操作即可擁有云的特性，同時(shí)實(shí)現(xiàn)對(duì)整個(gè)集群生命周期的管理。

　　業(yè)內(nèi)標(biāo)準(zhǔn)化平臺(tái)設(shè)計(jì)現(xiàn)有的解決方案，基本上是基于 Mesos 的 DC/OS、DockerSwarm、Rancher、K8S 而設(shè)計(jì)的，它們離生產(chǎn)環(huán)境還比較遠(yuǎn)。之前參加過(guò)一個(gè) Mesos 的會(huì)議突然醒悟到，他們的重點(diǎn)是放在 IaaS 層的，強(qiáng)調(diào)的是資源層面的調(diào)度，對(duì)應(yīng)用層面的調(diào)度還不深入。

　　作為應(yīng)用調(diào)度層，還是要和底層分開(kāi)為好。

　　應(yīng)用管理平臺(tái)只負(fù)責(zé)調(diào)度和管理集群生命周期，至于 IaaS 層用的是 KVM 或者 Docker 都沒(méi)關(guān)系，底層的資源調(diào)度由 IaaS 層解決就好。應(yīng)用層的重點(diǎn)應(yīng)該是深刻了解各類應(yīng)用、類型，并做出相應(yīng)的方案。

　　目標(biāo)一、人人都可以開(kāi)發(fā)云產(chǎn)品。

　　前提條件是你要懂一些基礎(chǔ)的東西，比如寫(xiě)腳本。云計(jì)算目前還是有點(diǎn)高門(mén)檻，青云的目標(biāo)就是盡可能降低這個(gè)門(mén)檻，讓人人都能開(kāi)發(fā)云應(yīng)用產(chǎn)品。

　　目標(biāo)二、縮短開(kāi)發(fā)周期。

　　以前開(kāi)發(fā)一個(gè)云應(yīng)用基本上是幾個(gè)月，最快是兩個(gè)月，現(xiàn)在可以把它縮短到幾天，快的話幾個(gè)小時(shí)就可以搞定。

　　目標(biāo)三、學(xué)習(xí)成本要低。

　　制定的規(guī)范要通俗易懂，不能讓人覺(jué)得奇怪，因?yàn)槠婀值臇|西往往生命周期不會(huì)很長(zhǎng)的，所以要讓它的學(xué)習(xí)成本很低。

　　目標(biāo)四、合作伙伴擁有完整的云平臺(tái)。

　　AppCenter 不僅包括應(yīng)用調(diào)度引擎，還給青云合作伙伴提供一整套云管理平臺(tái)。青云合作伙伴基于 AppCenter 進(jìn)行運(yùn)營(yíng)、運(yùn)維、開(kāi)發(fā)、銷售等，也就是說(shuō)除了自己的應(yīng)用，企業(yè)不需要關(guān)心其它的東西。

　　集群管理引擎是 AppCenter 2.0 最核心的一部分。

　　先從底層講起，底層調(diào)用青云后臺(tái)的 API —— CreateCluster，輸入一個(gè) JSON 串。下面通過(guò)舉例的方式來(lái)介紹 JSON 串。

　　示例一，ZooKeeper 集群創(chuàng)建。

　　輸入該集群的名字和描述，加入到哪個(gè)二層網(wǎng)絡(luò)，以及節(jié)點(diǎn)信息。比如說(shuō)要?jiǎng)?chuàng)建的節(jié)點(diǎn)數(shù)，每個(gè)節(jié)點(diǎn)的 CPU 數(shù)、內(nèi)存大小，指定鏡像 ID 和類型（KVM/Docker/LXC），并說(shuō)明在哪個(gè)區(qū)創(chuàng)建，要掛多少數(shù)據(jù)盤(pán)，盤(pán)的文件系統(tǒng)是什么，掛載點(diǎn)在哪里，大小是多少。甚至可以指定它的類型，比如容量盤(pán)、性能盤(pán)、高性能盤(pán)等。

　　即管理該 ZooKeeper 服務(wù)的命令。比如如何啟動(dòng)、關(guān)停 ZooKeeper 服務(wù)。

　　部分傳統(tǒng)軟件沒(méi)有云計(jì)算彈性伸縮的特性，那它如何做到伸縮呢？一般是新起一個(gè)集群。比如原有 10 個(gè)節(jié)點(diǎn)的集群，現(xiàn)在需要加到 20 個(gè)節(jié)點(diǎn)的做法是，先創(chuàng)建一個(gè) 20 個(gè)節(jié)點(diǎn)的集群，把這 10 個(gè)節(jié)點(diǎn)的集群的數(shù)據(jù)導(dǎo)過(guò)來(lái)，然后把舊集群刪除。AWSRedshift 就是這樣的做法。傳統(tǒng)軟件不像 Hadoop 那樣在現(xiàn)有集群上直接加一個(gè)節(jié)點(diǎn)就可以伸縮。所以在這里需要先聲明 advancedaction，才可支持應(yīng)用的彈性伸縮。

　　通過(guò)以上定義把這個(gè)應(yīng)用部署到青云 AppCenter 2.0上，那么 ZooKeeper 的云上特性就有了，包括啟動(dòng)、關(guān)閉、暫停、恢復(fù)、加減節(jié)點(diǎn)，縱向伸縮，所有這些都是這個(gè)文件內(nèi)容申明的。企業(yè)用戶只需填好這些信息，不到一個(gè)小時(shí)即可完成 ZooKeeper 的創(chuàng)建。

　　示例二，HBase 的創(chuàng)建。

　　示例一中，ZooKeeper 沒(méi)有角色，是一個(gè)很簡(jiǎn)單的例子，通常情況下應(yīng)用比這個(gè)復(fù)雜得多，比如 HBase，它是多角色的，有外部關(guān)聯(lián)，有應(yīng)用參數(shù)等。創(chuàng)建 HBase 要點(diǎn)如下：

　　文件定義變成 node list，每類 node 要定義角色。這個(gè)角色名字可由開(kāi)發(fā)者自行定義，但需要清楚每個(gè)角色以及它們的唯一性，否則容易產(chǎn)生混亂。

　　服務(wù)依賴。因 HBase 依賴于 ZooKeeper，這種情況下如果有人已經(jīng)創(chuàng)建了 ZooKeeper 服務(wù)，就不需要再開(kāi)發(fā) ZooKeeper 服務(wù)了，只需開(kāi)發(fā)一個(gè) HBase 服務(wù)，指定它依賴于哪個(gè) ZooKeeper。輸入 ZooKeeper 以 cl- 開(kāi)頭的 ID，即可自動(dòng)連接 ZooKeeper 與 HBase。

　　節(jié)點(diǎn)創(chuàng)建的要領(lǐng)跟 ZooKeeper 一樣。

　　生成公鑰。運(yùn)維 Hadoop、Spark、HBase 時(shí)，需要把主節(jié)點(diǎn)的公鑰復(fù)制到從節(jié)點(diǎn)上，指定 passphraseless ，即可生成主節(jié)點(diǎn)的公鑰。

　　Service 里設(shè)置 order，即節(jié)點(diǎn)啟動(dòng)順序。在云服務(wù)中，各類節(jié)點(diǎn)的啟動(dòng)順序是不一樣的。比如主從架構(gòu)的應(yīng)用是先啟動(dòng)主節(jié)點(diǎn)再啟動(dòng)從節(jié)點(diǎn)。如果先啟動(dòng)從節(jié)點(diǎn)的話，它可能因?yàn)檎也坏街鞴?jié)點(diǎn)而掛掉。所以需要指定不同節(jié)點(diǎn)類型的服務(wù)啟動(dòng)順序。更復(fù)雜的還有 Redis Cluster，它的執(zhí)行命令只在一個(gè)節(jié)點(diǎn)上執(zhí)行，而它的主節(jié)點(diǎn)至少有 3 個(gè)，從節(jié)點(diǎn)可以是零個(gè)到多個(gè)，所以需要制定規(guī)范滿足這種特殊需求。

　　參數(shù)呈現(xiàn)。HBase 是一個(gè)帶參數(shù)的應(yīng)用，這些參數(shù)需要呈現(xiàn)給最終用戶并且可以修改，比如 HDFS 副本有幾個(gè)。參數(shù)也要分角色，不同角色可能暴露不同參數(shù)給用戶。

　　endpoint。服務(wù)之間感知需要知道這些信息，有些軟件的端口號(hào)不是標(biāo)準(zhǔn)的，這個(gè)時(shí)候需要暴露這些信息給可能會(huì)用到這個(gè)的 App 的開(kāi)發(fā)者。

　　還有一種情況，有些端號(hào)是可變的。所以需要有一個(gè)類似于引用的功能，指向那個(gè)參數(shù)。當(dāng)參數(shù)發(fā)生改變時(shí)，服務(wù)的 endpoint 端口也會(huì)改。要開(kāi)發(fā)這一個(gè)標(biāo)準(zhǔn)化的平臺(tái)，不僅僅是為了滿足自動(dòng)化的部署，還要讓各個(gè)應(yīng)用之間發(fā)生關(guān)聯(lián)，形成一個(gè)生態(tài)。

　　首先是調(diào)度系統(tǒng)，統(tǒng)一管理著整個(gè)系統(tǒng)，包括元數(shù)據(jù)管理系統(tǒng)  metad，它的后端是定制化的 etcd。

　　confd 是配置管理系統(tǒng)，也是定制化的，它會(huì)從元數(shù)據(jù)管理系統(tǒng)獲取集群信息，從而自動(dòng)更新節(jié)點(diǎn)配置。

　　調(diào)度系統(tǒng)把集群的信息都注冊(cè)到元數(shù)據(jù)管理系統(tǒng)里，使不同集群可以關(guān)聯(lián)。比如有集群用到 ZooKeeper，它們就可以通過(guò)元數(shù)據(jù)管理系統(tǒng) metad 發(fā)生關(guān)聯(lián)，集群可以從這里得到關(guān)聯(lián)應(yīng)用的信息，從而連接 ZooKeeper。

　　那么這個(gè)元數(shù)據(jù)結(jié)構(gòu)是什么樣的呢？它是一個(gè)樹(shù)狀結(jié)構(gòu)，根節(jié)點(diǎn)是 self。每個(gè)節(jié)點(diǎn)可發(fā)出指令到元數(shù)據(jù)中心取它所在集群相關(guān)的所有信息，這個(gè)信息包括以下：

　　集群所有節(jié)點(diǎn)的信息，每個(gè)節(jié)點(diǎn)的詳細(xì)信息包括：IP地址、MAC、server ID、CPU、內(nèi)存以及主機(jī)所在物理機(jī)位置。

　　主機(jī)本身信息，詳細(xì)信息同上。

　　Cluster 信息，包括集群所在網(wǎng)絡(luò)。

　　env 參數(shù)，這些參數(shù)可以用來(lái)更新應(yīng)用配置。

　　伸縮信息。在加減節(jié)點(diǎn)的時(shí)候，每個(gè)集群會(huì)做一些動(dòng)作。比如數(shù)據(jù)的遷移，刪節(jié)點(diǎn)的時(shí)候不能盲目地把節(jié)點(diǎn)全刪掉，一定是在數(shù)據(jù)遷走之后再刪掉才最安全。增減節(jié)點(diǎn)的時(shí)候，你可以獲取相應(yīng)節(jié)點(diǎn)的 IP 地址、MAC 等全部信息。我們還提供了 scale in/scale out 的命令接口。

　　Links 信息。當(dāng) Kafka 要用某個(gè) ZooKeeper，通過(guò) ZooKeeper 的 ID 就可以獲取剛才說(shuō)到的 ZooKeeper 這個(gè)集群的所有信息，而后可將Kafka里的應(yīng)用配置跟 ZooKeeper 相關(guān)的信息全部更新，這就發(fā)生了集群關(guān)聯(lián)。

　　最后是 endpoint，當(dāng)應(yīng)用之間發(fā)生關(guān)聯(lián)的時(shí)候，有這個(gè)信息就可以自動(dòng)更新服務(wù)的關(guān)聯(lián)。

　　那么應(yīng)用如何實(shí)現(xiàn)自動(dòng)更新？和 Rancher、DCOS 的思路一致，需要寫(xiě)兩類文件，其中一個(gè)是以 toml 結(jié)尾的配置文件，另一個(gè)是以 tmpl 結(jié)尾的配置文件，它們是 Gotemplate 的模板語(yǔ)言，這個(gè)學(xué)習(xí)曲線是最高的，但它并不難。因?yàn)樵獢?shù)據(jù)結(jié)構(gòu)是一個(gè) tree 結(jié)構(gòu)，需要用到的無(wú)非就是那幾類：得到某個(gè) Key 的 value，或者得到某個(gè)Key 的 name，或者要遍歷 node 下面所有的 Key，沒(méi)有其它更多的。我們的文檔基本上提供了所有可能用到的語(yǔ)法案例。

　　ZooKeeper 有兩個(gè)配置文件，一個(gè)叫 zoo.cfg，一個(gè)叫 myid。

　　先看 zoo.cfg.toml 配置文件，該配置文件下有個(gè) src，即 ZooKeeper 應(yīng)用的配置模板。src 會(huì)更新 ZooKeeper 配置的內(nèi)容，即 dest 指定的文件。更新過(guò)程通過(guò) watch 的 keys 變更觸發(fā)，更新完之后，reload_cmd 定義的命令根據(jù)你的業(yè)務(wù)需求來(lái)選擇觸發(fā)與否，比如當(dāng) ZooKeeper 配置文件發(fā)生改變時(shí)，ZooKeeperservice 需要重啟。

　　再來(lái)看 zoo.cfg.template，range 這個(gè)模板語(yǔ)法可以獲取 hosts 集群信息。先是 lsdir，獲取主機(jī)集群目錄下所有的 instanceid，然后獲取每個(gè)主機(jī)的 serverid 和 IP 信息，把變量替換之后就變成了類似于 server.1=192.168.100.2：28888：38888 這樣的配置。myid的更新就更簡(jiǎn)單了，直接拿到本機(jī)的 serverID 更新就行了。

　　這樣一來(lái)，包含兩個(gè)配置文件的 image 就做好了，再結(jié)合前面的創(chuàng)建集群輸入 json 信息，就可以實(shí)現(xiàn)應(yīng)用的云化了。

　　前面講的是一個(gè)具體的實(shí)例 ZooKeeperinstance 以及 json 里面指定了幾顆 CPU、幾個(gè)節(jié)點(diǎn)。對(duì)于應(yīng)用中心的一名應(yīng)用開(kāi)發(fā)者，要提供 ZooKeeper 服務(wù)的話，肯定不能指定幾個(gè) CPU，而是要讓最終用戶去選擇，需要幾個(gè)節(jié)點(diǎn)和幾顆 CPU 等信息。

　　要開(kāi)發(fā)這樣的應(yīng)用，就要加兩個(gè)文件，config.json 和 cluster.json.mustache。這兩個(gè)文件加起來(lái)，經(jīng)過(guò)渲染就變成了一個(gè)應(yīng)用的實(shí)例信息即前面講的創(chuàng)建集群輸入?yún)��?shù)信息 cluster.json。

　　青云調(diào)度系統(tǒng)根據(jù) config.json 這個(gè)文件展現(xiàn)給用戶進(jìn)行選擇，比如有一個(gè) key 叫 CPU，它的 default 值是一顆 CPU，前端根據(jù)這個(gè)信息配置文件，展現(xiàn)給最終用戶以選擇幾個(gè) CPU。

　　cluster.json.mustache 和 cluster.json 很像，mustache 里的變量比如 name 是最終用戶根據(jù)前面的 config.json 在 UI 上填的內(nèi)容，如 cluster.name、CPU 數(shù)量、nodecount、volumesize。也就是說(shuō){{}} 里面是個(gè)變量，來(lái)自于 configjson 里最終用戶填的具體值，把它渲染完以后就變成了一個(gè)集群的實(shí)例信息，即前面講的 cluster.json。此時(shí)系統(tǒng)就會(huì)自動(dòng)調(diào)用 CreateCluster，創(chuàng)建這個(gè)應(yīng)用實(shí)例。

　　所以，開(kāi)發(fā)者要開(kāi)發(fā)應(yīng)用給最終用戶使用，他需要寫(xiě)這兩個(gè)文件，一個(gè)是 config.json，一個(gè)是 cluster.json.mustache。把這兩個(gè)文件寫(xiě)好之后，打包上傳到 AppCenter 平臺(tái)上就 OK 了。

　　除了以上兩個(gè)文件，還要制作相應(yīng)的鏡像。

　　基本上就這三件事情，寫(xiě) config.json，寫(xiě) cluster.json.mustache 以及制作鏡像。

　　AppCenter 2.0 集群管理引擎的運(yùn)用：應(yīng)用編排

　　相信大家看到這里肯定有一個(gè)感覺(jué)，AppCenter 2.0 集群管理引擎可以有很多使用方法。

　　使用方法一，開(kāi)發(fā)者可以利用這個(gè)引擎寫(xiě)很復(fù)雜的應(yīng)用，甚至不用 link，ZooKeeper 和 Kafka 也不用分開(kāi)。比如說(shuō)一個(gè)日志系統(tǒng)，可以把 ZooKeeper、Kafka、Storm、Hadoop 寫(xiě)進(jìn)同一個(gè) App，賦予不同的角色就行了，按照前面的一套方法就可以做這個(gè)事情。

　　還有一種使用方法就是應(yīng)用嵌套。當(dāng)開(kāi)發(fā)者要做一個(gè)系統(tǒng)，發(fā)現(xiàn)已經(jīng)有人做了某些需要用到的應(yīng)用，開(kāi)發(fā)者就不需要重復(fù)做這個(gè)事情，只需要直接 link，就可以把小的應(yīng)用組成一個(gè)大的應(yīng)用。比如日志系統(tǒng)，有人做了 ZooKeeper、Kafka、Storm、Hadoop，你可以把這些應(yīng)用組成大的日志系統(tǒng)應(yīng)用提供給最終用戶使用，在這些小應(yīng)用之上你可以額外收費(fèi)，這些小應(yīng)用的提供者同時(shí)也能收取他應(yīng)得的報(bào)酬，這些是通過(guò)青云收費(fèi)系統(tǒng)自動(dòng)完成的。

　　這是應(yīng)用編排的示意圖，第三方合作伙伴和青云的App都會(huì)展現(xiàn)在這里。最終用戶和開(kāi)發(fā)者都可以對(duì)這些 App 進(jìn)行拖拽，可以把它分層，底層是基礎(chǔ)層，中間是 middleware 層，再上層是應(yīng)用層，每一層都是 App，把它們?nèi)�部關(guān)聯(lián)起來(lái)然后封裝成一個(gè)大的 App。

　　舉例來(lái)說(shuō)，日志系統(tǒng)中的 Kafka、ZooKeeper、Hadoop、Storm 全拖拽進(jìn)來(lái)之后，再拖拽主機(jī)進(jìn)來(lái)。主機(jī)對(duì)青云來(lái)說(shuō)是一個(gè)系統(tǒng) App，在這個(gè)主機(jī)里可以部署程序，程序可以從Kafka取數(shù)據(jù)、消費(fèi)數(shù)據(jù)，結(jié)合 Storm 處理這些數(shù)據(jù)，Storm 處理結(jié)果輸出到 Redis、MySql、Hadoop 等，把這個(gè)模板做好之后就可以發(fā)布，使用過(guò)程中還可以通過(guò)對(duì)象存儲(chǔ)不停地迭代程序，因?yàn)樵谥鳈C(jī)程序里，可以通過(guò) environment 的方式把 Link 傳進(jìn)對(duì)象存儲(chǔ)，每次把代碼上傳到對(duì)象存儲(chǔ)里面，點(diǎn)一下部署，主機(jī)會(huì)自動(dòng)把代碼拉進(jìn)來(lái)，自動(dòng)更新。

　　以上是我們?cè)谧?QingCloud AppCenter 2.0 的思考。我們已經(jīng)看到，無(wú)論是公有云、私有云或混合云，還是 IaaS、PaaS 或 SaaS，越來(lái)越多的企業(yè)和個(gè)人已經(jīng)在使用云上提供的各類豐富服務(wù)，云計(jì)算的常態(tài)化在全世界已成為不可逆轉(zhuǎn)的趨勢(shì)。

　　青云 QingCloud AppCenter 2.0 志在建立一個(gè)學(xué)習(xí)使用成本低的高度標(biāo)準(zhǔn)化平臺(tái)，使得原有不論多復(fù)雜的產(chǎn)品和應(yīng)用的架構(gòu)都可以在“以天計(jì)算”的時(shí)間成本內(nèi)完成產(chǎn)品和應(yīng)用的云化，變成一個(gè)擁有所有云計(jì)算內(nèi)置能力的新產(chǎn)品和應(yīng)用。

　　除此之外，平臺(tái)上所有的產(chǎn)品和應(yīng)用都可以以服務(wù)的形式和其它產(chǎn)品和應(yīng)用一起靈活簡(jiǎn)潔的集成編排，形成更具價(jià)值的大服務(wù)�？梢韵胂瘢�這種以生態(tài)系統(tǒng)為形式的融合創(chuàng)造，將會(huì)為最終用戶提供無(wú)限廣闊的價(jià)值。

　　AppCenter 2.0 會(huì)貫通資源和應(yīng)用，將是一個(gè)非常強(qiáng)大的平臺(tái)。今年 7 月份的 QingCloud Insight 大會(huì)我們會(huì)推出更多激動(dòng)人心的產(chǎn)品。歡迎大家到時(shí)來(lái)參加。