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