青云 QingCloud 大數(shù)據(jù)平臺負(fù)責(zé)人周小四
以下為分享正文：
云計算常態(tài)化意味著云應(yīng)用的常態(tài)化
相信大家都聽過這句話，叫做“云計算常態(tài)化”。
在三年前，云計算在中國還只是一個概念，近年來，這個火熱的概念轉(zhuǎn)為實際，我們也幫助越來越多如銀行、保險、證券這樣的大型企業(yè)客戶實現(xiàn)云計算項目的真實落地。如此來看，云計算已經(jīng)常態(tài)化了。
云計算常態(tài)化，就意味著云應(yīng)用要常態(tài)化。
在我們跟企業(yè)客戶交流時發(fā)現(xiàn)，客戶希望我們能 把中間件都搞定，讓他們不用操心安裝和運維問題，從而能把更多的精力投入應(yīng)用。如果我們像過去一樣只提供云主機和網(wǎng)絡(luò)，已經(jīng)遠(yuǎn)遠(yuǎn)不能滿足用戶的需求了。而青云的愿景是云計算要像水電一樣服務(wù)于大眾，所以我們要去解決水電運輸問題，讓用戶只需要關(guān)心電器。
云應(yīng)用常態(tài)化，意味著云化應(yīng)用是一個極低的門檻。云化應(yīng)用門檻如果太高，那么成為常態(tài)化就不是一件容易的事情。
降低門檻，也意味著要有標(biāo)準(zhǔn)化的平臺，企業(yè)的應(yīng)用云化過程才能變得簡單。
關(guān)于架構(gòu)的演變，我們在過去兩年切身體會到很多內(nèi)容，可以分為以下三個階段：
- 初級階段，每個應(yīng)用在開發(fā)的時候完全是孤立的，每個研發(fā)組獨立開發(fā)項目。目前，很多業(yè)內(nèi)幾乎都是處在這個階段的。
- 第二階段，底層的應(yīng)用實現(xiàn)框架化，并將相同的模塊抽象出來共用。
但每個應(yīng)用還是單獨開發(fā)的，主要原因是應(yīng)用之間千差萬別，體系架構(gòu)各不相同。比如說應(yīng)用配置文件的定義都不一樣，所以每個應(yīng)用都需要單獨開發(fā)。
- 第三階段，也是青云近一年來一直在探索的，一個端到端的標(biāo)準(zhǔn)云化平臺—— AppCenter 2.0。
在這個標(biāo)準(zhǔn)云化平臺上，企業(yè)開發(fā)云應(yīng)用的時候，不用關(guān)心需要什么樣的技術(shù)，同時可以簡單、快速地云化應(yīng)用。它的特征是高度抽象，高度標(biāo)準(zhǔn)化。簡單地說，企業(yè)在云化應(yīng)用的時候，可按照標(biāo)準(zhǔn)批量生產(chǎn)各類云應(yīng)用。以后云技術(shù)就不再是企業(yè)核心了，而應(yīng)用本身才是核心。
這會使得最終競爭的是應(yīng)用本身，而不是云計算平臺。這里的含義是，如果青云的工程師和青云的合作伙伴，在 AppCenter 2.0 上各自開發(fā)一個云應(yīng)用，青云工程師作為云平臺的提供者來說沒有任何獨特優(yōu)勢，因為用的是同一個平臺。比如，雙方都要做一個 Hadoop，比的是誰有更深厚的經(jīng)驗，能夠把這個應(yīng)用做得更好，調(diào)優(yōu)調(diào)得更好，彼此PK的是應(yīng)用本身。
標(biāo)準(zhǔn)化平臺設(shè)計的思考
標(biāo)準(zhǔn)化平臺設(shè)計的難點
標(biāo)準(zhǔn)化平臺設(shè)計難點在于：
一、應(yīng)用種類繁多。
有的集群是沒有角色的，有的是有一主一從的，也有一主多從的，或者多主多從的，甚至分片的多主多從。
此外，每個應(yīng)用的集群管理方式也是多樣化的。每個應(yīng)用的生命周期如何管理，比如啟動集群、停止集群，如何運行這些命令，都不一樣，這非常復(fù)雜，也給標(biāo)準(zhǔn)化平臺帶來一些難度。
二、應(yīng)用配置變更。
有些應(yīng)用的配置與某類角色有關(guān)，同時如何實現(xiàn)應(yīng)用配置自動變更，如何存儲這些信息，這都是難點。
三、服務(wù)依賴感知。
AppCenter 2.0 不僅僅是解決集群自動化部署、自動化運維這個層面，還會成為一個生態(tài)，每個組件之間能夠互相感知。比如說企業(yè)應(yīng)用有一個 Kafka，當(dāng) ZooKeeper 節(jié)點發(fā)生改變時，Kafka 能否自動感知到該變化。
一般的做法是把這些信息手動改一下，并重啟 Kafka 服務(wù)。標(biāo)準(zhǔn)化平臺能否自動化這個過程，即在 ZooKeeper 加節(jié)點時不需要手動操作，Kafka 可自動更新配置、自動重啟，服務(wù)照樣運行。使服務(wù)之間互相感知，也是一個難點。
四、集群彈性伸縮。
應(yīng)用既然云化，就要滿足云彈性伸縮的特征。當(dāng)把沒有彈性伸縮能力的傳統(tǒng)軟件搬到云上時，AppCenter 2.0 需要解決這個問題。這樣一來，第三方合作伙伴用 AppCenter 2.0 平臺云化應(yīng)用的時候，不用寫代碼，只需按照 AppCenter 2.0 的規(guī)范操作即可擁有云的特性，同時實現(xiàn)對整個集群生命周期的管理。
標(biāo)準(zhǔn)化平臺設(shè)計現(xiàn)有方案
業(yè)內(nèi)標(biāo)準(zhǔn)化平臺設(shè)計現(xiàn)有的解決方案，基本上是基于 Mesos 的 DC/OS、DockerSwarm、Rancher、K8S 而設(shè)計的，它們離生產(chǎn)環(huán)境還比較遠(yuǎn)。之前參加過一個 Mesos 的會議突然醒悟到，他們的重點是放在 IaaS 層的，強調(diào)的是資源層面的調(diào)度，對應(yīng)用層面的調(diào)度還不深入。
作為應(yīng)用調(diào)度層，還是要和底層分開為好。
應(yīng)用管理平臺只負(fù)責(zé)調(diào)度和管理集群生命周期，至于 IaaS 層用的是 KVM 或者 Docker 都沒關(guān)系，底層的資源調(diào)度由 IaaS 層解決就好。應(yīng)用層的重點應(yīng)該是深刻了解各類應(yīng)用、類型，并做出相應(yīng)的方案。
青云 QingCloud AppCenter 2.0 探索
QingCloud AppCenter 2.0 目標(biāo)
目標(biāo)一、人人都可以開發(fā)云產(chǎn)品。
前提條件是你要懂一些基礎(chǔ)的東西，比如寫腳本。云計算目前還是有點高門檻，青云的目標(biāo)就是盡可能降低這個門檻，讓人人都能開發(fā)云應(yīng)用產(chǎn)品。
目標(biāo)二、縮短開發(fā)周期。
以前開發(fā)一個云應(yīng)用基本上是幾個月，最快是兩個月，現(xiàn)在可以把它縮短到幾天，快的話幾個小時就可以搞定。
目標(biāo)三、學(xué)習(xí)成本要低。
制定的規(guī)范要通俗易懂，不能讓人覺得奇怪，因為奇怪的東西往往生命周期不會很長的，所以要讓它的學(xué)習(xí)成本很低。
目標(biāo)四、合作伙伴擁有完整的云平臺。
AppCenter 不僅包括應(yīng)用調(diào)度引擎，還給青云合作伙伴提供一整套云管理平臺。青云合作伙伴基于 AppCenter 進(jìn)行運營、運維、開發(fā)、銷售等，也就是說除了自己的應(yīng)用，企業(yè)不需要關(guān)心其它的東西。
AppCenter 2.0 核心：集群管理引擎
集群管理引擎是 AppCenter 2.0 最核心的一部分。
先從底層講起，底層調(diào)用青云后臺的 API —— CreateCluster，輸入一個 JSON 串。下面通過舉例的方式來介紹 JSON 串。
示例一，ZooKeeper 集群創(chuàng)建。
第一步，定義集群。
輸入該集群的名字和描述，加入到哪個二層網(wǎng)絡(luò)，以及節(jié)點信息。比如說要創(chuàng)建的節(jié)點數(shù)，每個節(jié)點的 CPU 數(shù)、內(nèi)存大小，指定鏡像 ID 和類型（KVM/Docker/LXC），并說明在哪個區(qū)創(chuàng)建，要掛多少數(shù)據(jù)盤，盤的文件系統(tǒng)是什么，掛載點在哪里，大小是多少。甚至可以指定它的類型，比如容量盤、性能盤、高性能盤等。
第二步，輸入 Service 信息。
即管理該 ZooKeeper 服務(wù)的命令。比如如何啟動、關(guān)停 ZooKeeper 服務(wù)。
第三步，輸入 advanced_actions，比如 scale_horizontal。
部分傳統(tǒng)軟件沒有云計算彈性伸縮的特性，那它如何做到伸縮呢？一般是新起一個集群。比如原有 10 個節(jié)點的集群，現(xiàn)在需要加到 20 個節(jié)點的做法是，先創(chuàng)建一個 20 個節(jié)點的集群，把這 10 個節(jié)點的集群的數(shù)據(jù)導(dǎo)過來，然后把舊集群刪除。AWSRedshift 就是這樣的做法。傳統(tǒng)軟件不像 Hadoop 那樣在現(xiàn)有集群上直接加一個節(jié)點就可以伸縮。所以在這里需要先聲明 advancedaction，才可支持應(yīng)用的彈性伸縮。
通過以上定義把這個應(yīng)用部署到青云 AppCenter 2.0上，那么 ZooKeeper 的云上特性就有了，包括啟動、關(guān)閉、暫停、恢復(fù)、加減節(jié)點，縱向伸縮，所有這些都是這個文件內(nèi)容申明的。企業(yè)用戶只需填好這些信息，不到一個小時即可完成 ZooKeeper 的創(chuàng)建。
示例二，HBase 的創(chuàng)建。
示例一中，ZooKeeper 沒有角色，是一個很簡單的例子，通常情況下應(yīng)用比這個復(fù)雜得多，比如 HBase，它是多角色的，有外部關(guān)聯(lián)，有應(yīng)用參數(shù)等。創(chuàng)建 HBase 要點如下：
文件定義變成 node list，每類 node 要定義角色。這個角色名字可由開發(fā)者自行定義，但需要清楚每個角色以及它們的唯一性，否則容易產(chǎn)生混亂。
服務(wù)依賴。因 HBase 依賴于 ZooKeeper，這種情況下如果有人已經(jīng)創(chuàng)建了 ZooKeeper 服務(wù)，就不需要再開發(fā) ZooKeeper 服務(wù)了，只需開發(fā)一個 HBase 服務(wù)，指定它依賴于哪個 ZooKeeper。輸入 ZooKeeper 以 cl- 開頭的 ID，即可自動連接 ZooKeeper 與 HBase。
節(jié)點創(chuàng)建的要領(lǐng)跟 ZooKeeper 一樣。
生成公鑰。運維 Hadoop、Spark、HBase 時，需要把主節(jié)點的公鑰復(fù)制到從節(jié)點上，指定 passphraseless ，即可生成主節(jié)點的公鑰。
Service 里設(shè)置 order，即節(jié)點啟動順序。在云服務(wù)中，各類節(jié)點的啟動順序是不一樣的。比如主從架構(gòu)的應(yīng)用是先啟動主節(jié)點再啟動從節(jié)點。如果先啟動從節(jié)點的話，它可能因為找不到主節(jié)點而掛掉。所以需要指定不同節(jié)點類型的服務(wù)啟動順序。更復(fù)雜的還有 Redis Cluster，它的執(zhí)行命令只在一個節(jié)點上執(zhí)行，而它的主節(jié)點至少有 3 個，從節(jié)點可以是零個到多個，所以需要制定規(guī)范滿足這種特殊需求。
參數(shù)呈現(xiàn)。HBase 是一個帶參數(shù)的應(yīng)用，這些參數(shù)需要呈現(xiàn)給最終用戶并且可以修改，比如 HDFS 副本有幾個。參數(shù)也要分角色，不同角色可能暴露不同參數(shù)給用戶。
endpoint。服務(wù)之間感知需要知道這些信息，有些軟件的端口號不是標(biāo)準(zhǔn)的，這個時候需要暴露這些信息給可能會用到這個的 App 的開發(fā)者。
還有一種情況，有些端號是可變的。所以需要有一個類似于引用的功能，指向那個參數(shù)。當(dāng)參數(shù)發(fā)生改變時，服務(wù)的 endpoint 端口也會改。要開發(fā)這一個標(biāo)準(zhǔn)化的平臺，不僅僅是為了滿足自動化的部署，還要讓各個應(yīng)用之間發(fā)生關(guān)聯(lián)，形成一個生態(tài)。
AppCenter 2.0 集群管理引擎架構(gòu)圖
這是AppCenter2.0集群管理引擎的架構(gòu)圖
首先是調(diào)度系統(tǒng)，統(tǒng)一管理著整個系統(tǒng)，包括元數(shù)據(jù)管理系統(tǒng) metad，它的后端是定制化的 etcd。
confd 是配置管理系統(tǒng)，也是定制化的，它會從元數(shù)據(jù)管理系統(tǒng)獲取集群信息，從而自動更新節(jié)點配置。
調(diào)度系統(tǒng)把集群的信息都注冊到元數(shù)據(jù)管理系統(tǒng)里，使不同集群可以關(guān)聯(lián)。比如有集群用到 ZooKeeper，它們就可以通過元數(shù)據(jù)管理系統(tǒng) metad 發(fā)生關(guān)聯(lián)，集群可以從這里得到關(guān)聯(lián)應(yīng)用的信息，從而連接 ZooKeeper。
那么這個元數(shù)據(jù)結(jié)構(gòu)是什么樣的呢？它是一個樹狀結(jié)構(gòu)，根節(jié)點是 self。每個節(jié)點可發(fā)出指令到元數(shù)據(jù)中心取它所在集群相關(guān)的所有信息，這個信息包括以下：
集群所有節(jié)點的信息，每個節(jié)點的詳細(xì)信息包括：IP地址、MAC、server ID、CPU、內(nèi)存以及主機所在物理機位置。
主機本身信息，詳細(xì)信息同上。
Cluster 信息，包括集群所在網(wǎng)絡(luò)。
env 參數(shù)，這些參數(shù)可以用來更新應(yīng)用配置。
伸縮信息。在加減節(jié)點的時候，每個集群會做一些動作。比如數(shù)據(jù)的遷移，刪節(jié)點的時候不能盲目地把節(jié)點全刪掉，一定是在數(shù)據(jù)遷走之后再刪掉才最安全。增減節(jié)點的時候，你可以獲取相應(yīng)節(jié)點的 IP 地址、MAC 等全部信息。我們還提供了 scale in/scale out 的命令接口。
Links 信息。當(dāng) Kafka 要用某個 ZooKeeper，通過 ZooKeeper 的 ID 就可以獲取剛才說到的 ZooKeeper 這個集群的所有信息，而后可將Kafka里的應(yīng)用配置跟 ZooKeeper 相關(guān)的信息全部更新，這就發(fā)生了集群關(guān)聯(lián)。
最后是 endpoint，當(dāng)應(yīng)用之間發(fā)生關(guān)聯(lián)的時候，有這個信息就可以自動更新服務(wù)的關(guān)聯(lián)。
應(yīng)用如何實現(xiàn)自動更新？
那么應(yīng)用如何實現(xiàn)自動更新？和 Rancher、DCOS 的思路一致，需要寫兩類文件，其中一個是以 toml 結(jié)尾的配置文件，另一個是以 tmpl 結(jié)尾的配置文件，它們是 Gotemplate 的模板語言，這個學(xué)習(xí)曲線是最高的，但它并不難。因為元數(shù)據(jù)結(jié)構(gòu)是一個 tree 結(jié)構(gòu)，需要用到的無非就是那幾類：得到某個 Key 的 value，或者得到某個Key 的 name，或者要遍歷 node 下面所有的 Key，沒有其它更多的。我們的文檔基本上提供了所有可能用到的語法案例。
ZooKeeper 有兩個配置文件，一個叫 zoo.cfg，一個叫 myid。
先看 zoo.cfg.toml 配置文件，該配置文件下有個 src，即 ZooKeeper 應(yīng)用的配置模板。src 會更新 ZooKeeper 配置的內(nèi)容，即 dest 指定的文件。更新過程通過 watch 的 keys 變更觸發(fā)，更新完之后，reload_cmd 定義的命令根據(jù)你的業(yè)務(wù)需求來選擇觸發(fā)與否，比如當(dāng) ZooKeeper 配置文件發(fā)生改變時，ZooKeeperservice 需要重啟。
再來看 zoo.cfg.template，range 這個模板語法可以獲取 hosts 集群信息。先是 lsdir，獲取主機集群目錄下所有的 instanceid，然后獲取每個主機的 serverid 和 IP 信息，把變量替換之后就變成了類似于 server.1=192.168.100.2：28888：38888 這樣的配置。myid的更新就更簡單了，直接拿到本機的 serverID 更新就行了。
這樣一來，包含兩個配置文件的 image 就做好了，再結(jié)合前面的創(chuàng)建集群輸入 json 信息，就可以實現(xiàn)應(yīng)用的云化了。
應(yīng)用管理僅需做好三件事情
前面講的是一個具體的實例 ZooKeeperinstance 以及 json 里面指定了幾顆 CPU、幾個節(jié)點。對于應(yīng)用中心的一名應(yīng)用開發(fā)者，要提供 ZooKeeper 服務(wù)的話，肯定不能指定幾個 CPU，而是要讓最終用戶去選擇，需要幾個節(jié)點和幾顆 CPU 等信息。
要開發(fā)這樣的應(yīng)用，就要加兩個文件，config.json 和 cluster.json.mustache。這兩個文件加起來，經(jīng)過渲染就變成了一個應(yīng)用的實例信息即前面講的創(chuàng)建集群輸入?yún)?shù)信息 cluster.json。
青云調(diào)度系統(tǒng)根據(jù) config.json 這個文件展現(xiàn)給用戶進(jìn)行選擇，比如有一個 key 叫 CPU，它的 default 值是一顆 CPU，前端根據(jù)這個信息配置文件，展現(xiàn)給最終用戶以選擇幾個 CPU。
cluster.json.mustache 和 cluster.json 很像，mustache 里的變量比如 name 是最終用戶根據(jù)前面的 config.json 在 UI 上填的內(nèi)容，如 cluster.name、CPU 數(shù)量、nodecount、volumesize。也就是說{{}} 里面是個變量，來自于 configjson 里最終用戶填的具體值，把它渲染完以后就變成了一個集群的實例信息，即前面講的 cluster.json。此時系統(tǒng)就會自動調(diào)用 CreateCluster，創(chuàng)建這個應(yīng)用實例。
所以，開發(fā)者要開發(fā)應(yīng)用給最終用戶使用，他需要寫這兩個文件，一個是 config.json，一個是 cluster.json.mustache。把這兩個文件寫好之后，打包上傳到 AppCenter 平臺上就 OK 了。
除了以上兩個文件，還要制作相應(yīng)的鏡像。
基本上就這三件事情，寫 config.json，寫 cluster.json.mustache 以及制作鏡像。
AppCenter 2.0 集群管理引擎的運用：應(yīng)用編排
相信大家看到這里肯定有一個感覺，AppCenter 2.0 集群管理引擎可以有很多使用方法。
使用方法一，開發(fā)者可以利用這個引擎寫很復(fù)雜的應(yīng)用，甚至不用 link，ZooKeeper 和 Kafka 也不用分開。比如說一個日志系統(tǒng)，可以把 ZooKeeper、Kafka、Storm、Hadoop 寫進(jìn)同一個 App，賦予不同的角色就行了，按照前面的一套方法就可以做這個事情。
還有一種使用方法就是應(yīng)用嵌套。當(dāng)開發(fā)者要做一個系統(tǒng)，發(fā)現(xiàn)已經(jīng)有人做了某些需要用到的應(yīng)用，開發(fā)者就不需要重復(fù)做這個事情，只需要直接 link，就可以把小的應(yīng)用組成一個大的應(yīng)用。比如日志系統(tǒng)，有人做了 ZooKeeper、Kafka、Storm、Hadoop，你可以把這些應(yīng)用組成大的日志系統(tǒng)應(yīng)用提供給最終用戶使用，在這些小應(yīng)用之上你可以額外收費，這些小應(yīng)用的提供者同時也能收取他應(yīng)得的報酬，這些是通過青云收費系統(tǒng)自動完成的。
這是應(yīng)用編排的示意圖，第三方合作伙伴和青云的App都會展現(xiàn)在這里。最終用戶和開發(fā)者都可以對這些 App 進(jìn)行拖拽，可以把它分層，底層是基礎(chǔ)層，中間是 middleware 層，再上層是應(yīng)用層，每一層都是 App，把它們?nèi)筷P(guān)聯(lián)起來然后封裝成一個大的 App。
舉例來說，日志系統(tǒng)中的 Kafka、ZooKeeper、Hadoop、Storm 全拖拽進(jìn)來之后，再拖拽主機進(jìn)來。主機對青云來說是一個系統(tǒng) App，在這個主機里可以部署程序，程序可以從Kafka取數(shù)據(jù)、消費數(shù)據(jù)，結(jié)合 Storm 處理這些數(shù)據(jù)，Storm 處理結(jié)果輸出到 Redis、MySql、Hadoop 等，把這個模板做好之后就可以發(fā)布，使用過程中還可以通過對象存儲不停地迭代程序，因為在主機程序里，可以通過 environment 的方式把 Link 傳進(jìn)對象存儲，每次把代碼上傳到對象存儲里面，點一下部署，主機會自動把代碼拉進(jìn)來，自動更新。
結(jié)語
以上是我們在做 QingCloud AppCenter 2.0 的思考。我們已經(jīng)看到，無論是公有云、私有云或混合云，還是 IaaS、PaaS 或 SaaS，越來越多的企業(yè)和個人已經(jīng)在使用云上提供的各類豐富服務(wù)，云計算的常態(tài)化在全世界已成為不可逆轉(zhuǎn)的趨勢。
青云 QingCloud AppCenter 2.0 志在建立一個學(xué)習(xí)使用成本低的高度標(biāo)準(zhǔn)化平臺，使得原有不論多復(fù)雜的產(chǎn)品和應(yīng)用的架構(gòu)都可以在“以天計算”的時間成本內(nèi)完成產(chǎn)品和應(yīng)用的云化，變成一個擁有所有云計算內(nèi)置能力的新產(chǎn)品和應(yīng)用。
除此之外，平臺上所有的產(chǎn)品和應(yīng)用都可以以服務(wù)的形式和其它產(chǎn)品和應(yīng)用一起靈活簡潔的集成編排，形成更具價值的大服務(wù)�？梢韵胂�，這種以生態(tài)系統(tǒng)為形式的融合創(chuàng)造，將會為最終用戶提供無限廣闊的價值。
AppCenter 2.0 會貫通資源和應(yīng)用，將是一個非常強大的平臺。今年 7 月份的 QingCloud Insight 大會我們會推出更多激動人心的產(chǎn)品。歡迎大家到時來參加。
