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