愛奇藝基于 Docker 的 App Engine 實踐
楊成偉：大家好，我是來自愛奇藝的楊成偉，現在在愛奇藝公司內部負責彈性計算云方面的建設，之前我是做移動操作系統的，之前在因特爾做MeeGo和Python，有幾年的經驗，主要是在操作系統的核心層，但是是在UserSpace這一塊，所以對于像Systemd DBUS比較了解，然后也是一個DBUS的 Upstream Commiter。但是現在來到愛奇藝之后主要是從事云計算這一塊的工作。
內容提要
今天我主要給大家介紹一下愛奇藝 App Engine設計與實現： ## 大標題
1、背景、出發點、目標
第一部分是一些背景、出發點以及目標，因為愛奇藝在Iaas起步比較早，我們公司大部分的業務都已經從物理機實現到虛機的遷移，也就是第一步的這種Iaas基礎架構已經有了，包括公司非常多的像DB、MQ中間件之類的幾乎都已經實現了云化。為什么要從虛機到基于Docker的這種轉變的話，我們從最早的時候是13年底開始接觸Mesos，我們有非常強的mesos的背景，我們首先考慮的是從資源效率的方面考慮的，所以最早的時候想要實現一個App Engine，主要是借助Docker的靈活性然后實現業務的橫向擴展以及對資源的節約。
2、iQIYI App Engine 設計與實現
第二部分我們會詳細的分析一下App Engine的設計與實現
3、一些經驗（坑）
第三部分因為這個App Engine現在長成這樣，之前也不是這樣的，我們也積累了一些經驗，包括踩了一些坑
4、現狀與展望
最后一部分是App Engine在我們公司的現狀包括業務的現狀以及開發狀態，最后是一點展望。
5、Q & A
背景、出發點、目標
背景 — 業務上
因為業務很大部分已經遷移到虛機，而虛機我們其實提供了各種類型的業務，最常見的就是后臺服務，而且非常大的一部分是基于java+Tomcat這種后臺的業務，還有一些非常常見的worker業務，它們會接受一些MQ里面的任務然后自己處理，再把處理結果入庫或者上云之類的，其他占大部分的就是一些中間件或者是DB Cache，因為不太適合Docker這種應用場景，所以我們首先會著力改造將適合Docker的設計理念的一些業務首先遷移到Docker上，之后我們才會考慮說從滿足各種更豐富的應用場景。
背景 — 技術上
這是我們的技術背景，我們在13年底的時候是接觸Mesos，然后14年上半年我們把公司的大約30%左右的轉碼（圖片、視頻）任務都已經跑在了容器里面，當時我們上線的Docker版本是1.0，當然我們在調研的時候是從0.8開始調研，所以那個時候Mesos對于Docker的支持實際上還沒有，因為從0.16開始它是只有自己builtin容器環境，當然Docker出現之后就有開源的項目，就是讓Mesos來支持Docker，所以我們在上線了基于時間批處理業務之后我們就有精力來考慮另外一種業務類型，也就是Long—Running的業務類型，這個業務類型當時官方提供的是基于mesos的Marathon框架，這個框架主要是為了Mesos設計的，現在也經不能運行在其他的框架上。當時還有一個是推ter 框架，但是那個框架比較原始，而且使用起來非常復雜，所以我們就很自然選擇了基于Mesos的Marathon框架來搭建我們的App Engine，所以App Engine主要是面向這種Long—Running service來服務的，一個方面是因為作為一個執行調度層的話，它是內建了一些對Long—Running service支持的，比如說像之前大家都說到的，要它保持幾個容器的話，它會通過健康檢查來發現死掉的容器，然后確保在任意時刻是有指定數量的容器在運行。還有一些內建的服務發現機制。
出發點
出發點其實很簡單，Mesos的設計原理就是說把靜態分區的一些數據中心把它整合在一起運行，有一些業務：比如spark可能是非常耗內存的，比如mapreduce可能在CPU計算或者磁盤IO上面會比較高，但是如果你都把單獨搭集群的話，它的綜合利用率不會高，因為有一些資源可能是閑置的，有一些資源可能就會非常的忙。所以從Mesos設計理念出發的，最早做App Engine出發點是考慮到要省資源，相應的也就是要省錢、要省人。
但是目標當時是非常模糊的，因為我們對于這種具體的業務能夠省多少資源是沒有精確的這種測量過的，因為業務也在時時的變化，但是我們相信基于Docker這種彈性計算的話，它和虛機相比有一個非常大的好處，也就是它的橫向擴容能力非常強。因為基于虛機模式的話，實際上是說你在上線業務之前實際上你要預估你這個業務的量，但是因為虛機部署和上線以及擴容就是太麻煩，往往肯定是會留很大的buffer，至少是留一倍的buffer出來，應對你在緊急的時候能夠支撐上你的業務，但是一旦上了這種Docker彈性云的話，這種buffer顯然是不需要的，因為它能夠時時的擴容。所以我們知道后面可以節省的資源實際上是非常多的。
目標會變的，隨著我們慢慢的深入，就是有業務去接入，我們會發現其實讓用戶從一個基于虛機的開發環境遷移到一個基于容器的這種開發模式下，實際上改變是非常大的，我們也主要在用戶的學習成本上以及應用性還有用戶受益方面做了一些工作，比如說像學習成本方面的話，一個是文檔，一個是開發。因為最早Docker還沒有像Docker include這個功能，我們在內部實現了這個功能，所以就可以實現Dockerfile的重用，減少用戶寫Dockerfile的難度。
用戶受益
用戶受益主要是這幾方面：
? 資源到位快
因為我們底層是有多個DC的Mesos的彈性資源池，這個資源池會按一定的規律去建設的，所以對于業務來說的話，這個資源池里面總是可以夠單個業務使用的，而不是需要業務臨時的去申請，我們再加物理機再往里面擴資源池，所以和虛機相比的話這個資源就到位非常快
? 部署快（上線、升級）
部署快的話主要是在上線升級還有持續集成發布這方面，因為如果是基于虛機方式的話，很多開發者需要管理它一套的這種部署環境，因為一個Long—Running它肯定會用很多的虛擬機，然后管理這幾十臺虛擬機的環境一致性，其實就是一個非常大的問題。我們這邊也遇到過一些情況，就是非常多的用戶對于Linux 操作系統這一塊并不是非常熟練，特別是對于一些performance tuning之類的。用戶說：我的環境全部是一致的。但是這一致的話是它口頭上說的------就是我部署都是一致的，但是你具體一不一致的話，這個是很難去排查的，因為對于外面的人來說，等你操作完之后，實際上就是一個黑盒子，但是有docker的話，這種環境的一致性就會非常的方便。
? 擴容快
擴容快和資源到位快是差不多，但是分為兩個時段，一個就是業務上線之前它的資源到位，一個是在業務上線之后擴容快，這里對于用戶來說是對于他們業務的擴容快，但是對于我們這個基礎平臺的話，Mesos這個資源層本身的擴容是非常快的。
? 自動故障轉移，免運維
自動故障轉移、免運維。Mesos本身就實現了這種結算節點的故障轉移，所以一旦有上面的task因為底層的計算節點失敗的話，它會轉移到其他的節點去，所以這個對于和虛機相比的話，虛機故障了以后，是不去處理線上故障，一旦從第一個業務遷移到我們平臺之后，實際上就不用晚上起來運維了。
? 完善的監控預警
完善的監控預警，這個相當于是我們在監控預警方面會對業務做一些內置的監控預警，所以這樣子每個開發者也就是我們的用戶不用自己去部署這些系統層面的監控、預警以及它的業務層面方面的監控預警，因為畢竟非常多的后臺應用的開發者對于Linux 系統層面的這種監控、調優實際上不是非常熟練的。
iQIYI App Engine 設計與實現
這一部分主要介紹一下App Engine的設計與實現。這是一個功能框圖（如圖），我們最下面 是有Marathon和Mesos的彈性資源池，當然這個資源池是多DC的一個集群，對于每一個DC，比如說一套Mesos上面可能會跑多套的Marathon，如果業務有需求的話可能會進行一些物理節點方面的隔離。然后再上面是愛奇藝的App Engine，所以App Engine從設計上是可以跨DC部署你的應用的，主要包含的功能模塊一個是自動擴展，然后是任務的管理。主要是因為要從業務的APP邏輯轉化為Marathon的task去調度，包括一些生存期的管理。對于CI和CD，現在我們是正在prototype，還沒有正式上線。事件總線，對于這種Long—Running來說，另外一個必須的功能實際上還有服務發現，所以服務發現和事件總線，實際上是可以完美的結合起來：基于事件總線來實現這種服務的發現。監控就分為三層，一層是對于底層Mesos彈性計算集群平臺的監控，實際上這一層對于用戶來說是不用感知的，因為這一層是我們集群運維的工作。預警系統，公司內部的一個預警系統支持多種方式的預警。日志就是對于傳統的基于虛機的開發者來說，日志盡量不要改，不要為了去迎合Docker導致只能把日志打成Stdout或者是Stderr。所以日志這一塊也是需要提供額外的功能。當然最上面就是API和webUI。然后接下來我們會分模塊探討一下這幾大模塊的實現。
QAE — 監控和預警
首先介紹一下監控和預警，因為監控非常重要，因為它對于用戶來說必須要知道他這個業務遷移到一個陌生的環境、一個陌生的平臺，必須要知道它的運營狀態，Docker的最佳實踐是不推薦用戶在容器里面跑 多個進程，包括像SSHD之類的，但是在我們的實際經驗中其實很多用戶依然會裝SSHD進去，即使它有這些監控數據，我們會在每一個計算節點上有一個容器的監控engine叫dAdviser，（后面會介紹）。這個dAdviser它會負責監控所有的QAE啟動的這種容器，并且采集包括像CPU、內存、磁盤、網絡、數據，當然還有可能是其他數據，這一塊其他數據我們后面應該會再繼續做，目前還沒有做，其他數據可能包括進程里面的數據，可能更詳細一些，包括像對比較common的業務，比如像tomcat這種業務包括服務器、內部的監控，這樣的話就可以更方便用戶去排障、debug以及監視，這些數據全部都會打到一個Time Series DB，然后我們這一塊是采用的Graphite，后面我們會介紹為什么采用這個東西。
那除了容器這一層做監控，另外就有業務層的監控，因為一個業務的話肯定是由多個容器組成的，即使是一個容器的話，其實它也是有一些業務數據的，包括對于QAE Core里面能夠看到的比如說你處于各種狀態的容器數量，這個可以給用戶一個相當于一個提醒，就是說有沒有容器，現在處于說是一種不健康的狀態，所以一旦有了這種支持負載均衡的template，它可以在控制遷入的量，可以在nginx節點上把需要遷移的流量部署上去。實際上它是支持一個template概念，在template我們只會替換說需要替換的地方，也就是說它實際上是支持虛機和Docker混布的，所以即使是在一臺Nginx 上，你也是可以同時把流量分發到后面的虛機或者分發到我們的Docker，所以這對于業務的推廣還有用戶的接入是比較方便的，而不是說一次性就讓把用戶都遷過來，因為他們的擔憂確實是比較大。
QAE — 日志
QAE日志，日志我們現在采用的方案也是經過幾輪的變化的，因為上線之后用戶會有反饋，我們這種架構在QAE Core在啟動容器的時候，會注入一個日志卷，注入到容器里的日志卷在主機上有一個唯一的目錄。因為根據我們對公司內部業務開發者，這些收集的反饋就是一個日志目錄，是能夠滿足他們的需求的。但是如果你讓所有的用戶都把日志打到Stdout、Stderr的這個是他們不能接受的，比如像開發代碼也好，或者是tomcat也好，他們都需要改代碼或者是改配置，所以這個的工程量是非常大的，因此我們就支持這種日志卷的注入，相當于把日志打到這個目錄，然后會在每一個計算節點上會有一個log—agent，然后這個agent主要是做兩部分的工作，一部分是要負責對日志的采集，然后將日志備份，采集的方案我們現在會有flume，venus是一個公司內部基于flume然后打造的一個相當于服務平臺，所以會采用這個方案去把日志上云，上云之后用戶可以在這個云平臺上面進行一些加工，比如說寫一些spark的job，然后來計算它的日志，還可以接入像ELK之類的然后做一些日志統計分析、報表呈現。另外一塊就是非常重要的一塊，就是時時日志，因為非常多的用戶對于日志來說他們很多情況下，如果發現這個業務有一點問題，或者是說失敗率過高或者是有一些異常，或者是它依賴的后端服務有異常，就需要時時去看這個容器的日志輸出，所以對于上云的那種日志的話它的有一定的延時的，可能在分鐘級別，所以對于時時日志的話這個Log—agent會實現一個相當于 websockie 的 server，所以我們的QAE Core會知道說每一個容器它的日志是放在哪一臺機器上的，這個Log—agent服務地址會呈現給用戶，讓用戶有一個時時的鏈接可以點擊，當它點擊這個鏈接之后就會和Log—agent建立websockie 的這種實時流的通信機制，所以用戶就能在瀏覽器里面看到實時的日志這種輸出和docker logs -f比較類似。當然這個對于那種日志量非常非常大的可能不太適用，因為他們根本就看不過來，但是這個功能對于很多用戶來說就是非常需要的。
QAE — CI/CD
最后是CI和CD，我們這里選用的是GitLab，而非就是傳統的像Gerrit和Jenkins，Gerrit是用的非常早，當然最早規模化是谷歌在用，當然后來因特爾內部也是用這個，但是Gerrit對于用戶入門的門檻非常高，它的項目配制和用戶權限的管理，包括每一個branche需要的權限，配制的話幾乎是需要專門的管理人員才能搞得定，另外一個是看起來比較不美觀。CI的話實際上也是采用了GitLab內制的CI，因為CI在它一款軟件里面集成的比較好，比較類似像Github和CherryS這種CI的集成，然后沒有選用Jenkins的話，也是因為Jenkins對于用戶的要求也是比較高的，因為它是從底到上所有都需要用戶來配制的，如果我們想要提供一種像CI as a service 實際上是不需要用戶來關心下層的這種CI的worker的，也就是你worker在哪跑，你需要給用戶隱藏的，當然像GitLab的話實際上就能夠把這一部分剝離，這一部分挪到了相當于管理員的任務，然后用戶只需要關心他的job，而不需要關心底層的配制，所以GItLab總的來說就是和Gerrit和Jenkins相比的話就是它的用戶門檻會低一些，而且它工作方式會比較現代，和Github是比較類似的。所以從Code Hosting/Review到CI ，（GitLab），以及一些開發的工作，Gitlab它的 api和hook機制是非常完備的，支持像json數據格式。所以我們的開發主要就集中在對于像built docker鏡像以及像傳輸到Docker Registry 。另外可以提供自動上線的功能，當用戶選擇自動上線的話，就可以在QAE里面自動啟動你新的鏡像。這一塊我們現在還在prototype當中，一個原因也是因為GitLab的話它的開發非常活躍，我們在去年年終調研的時候，他們是對于Docker是不支持的，但現在是支持的，所以這一塊工作我們會盡快的啟動。所以對于QAE平臺來說，也就是它不僅會解決業務上線到業務運維這一個緯度，還會解決開發這一個緯度，開發者從他的代碼開發一直到生成鏡像，就是開發打包和built ceph這一條路的話也會cover。
一些經驗（坑）
第三部分是一些經驗，前面講的設計實際上QAE現在長成的一個狀態，一些經驗的會介紹一下我們從開始到現在走過的一些彎路。
容器監控 — Zabbix
? 優勢
? 已有 Zabbix 基礎服務
? Auto Discovery 能發現容器啟動/消失事件
? 劣勢
? 需要在容器內部安裝 zabbix, overhead 太大
? 不是很穩定
? 數據統計比較復雜
首先在容器監控方面，因為虛機已經規模非常大，在虛機監控以及物理機監控方面都是采用的Zabbix，因為Zabbix也是開源的，所以這一塊對于我們的優勢就是能夠沿用已有的基礎服務，并且zabbix有Auto Discovery 這種機制，所以它能夠發現你在主機上如果有容器啟動或者消失事件，它是能夠發現的，它能實現自動的去感知，并且自動的去監控，所以當時看來也是能夠直接采用的。但是后來Zabbix的問題也是比較明顯的，一個是在鏡像安裝Zabbix這個overhead比較大，因為你在一個計算節點上很可能會跑非常多的容器，那么在每一個容器內部如果你都運行一個Zabbix的話，overhead很大。另一個也是不符合Docker這種最佳實踐。還有一個問題是-----不是很穩定，因為一旦量很大之后，到Zabbix proxy 還有一些地方都會導致它不是非常的穩定。數據統計比較復雜。因為我們做一個App Engine實際上是以APP為中心的，而不是像以前虛機那樣子，虛機比較重，所以會以虛機為中心，但是Zabbix它沒有內置的數據的統計，就是將多個容器的數據整合成一個APP的數據，從容器的緯度轉換成APP的緯度，所以這個是需要自己開發的，而且Zabbix的API實際上真的寫的是不怎么樣，所以用起來會非常麻煩，后來我們就完全拋棄了用Zabbix來監控容器。
容器監控 — cAdvisor
? 優勢
? 背靠 Google 且開源
? 監控數據詳盡
? 劣勢
? 集群化開發成本較高，Kubernetes heapster 實現
? influxDB 而非 graphite（當時有基礎服務）
在14年谷歌開放了，因為我們在Kubernetes之前就做這個東西，所以我們后來決定放棄Zabbix之后也調研了谷歌的cAdvisor，一個是背靠谷歌且開源，跟一些小項目來比的話，它的持續開發和社區的質量是能夠保證的。另外一個就是它的監控數據是非常詳盡的，包括我們general想要的，像一些CPU memory的統計，它還會有更詳細的，比如說每一個核的統計，包括每一個核的IDL或者是User time and Sys time之類的都會有統計。劣勢，就是cAdvisor它是一個單機版的監控，集群化開發成本較高，Kubernetes heapster實現的，所以對于像不采用Kubernetes你需要自己去實現這個集群化的工作。另外一個就是cAdvisor它的backend的存儲只有兩種可選，一種就是In-Memory，In-Memory顯然是不適合的，而且它的memory是有限制的，所以你只能看到最近10分鐘的數據，顯然用戶不可能只看最近10分鐘的數據。另外一種持久化的存儲采用的是influxDB，influxDB 也是一個非常新興的一個time series DB。而當時我們對于像內部有這種現成的graphite服務，而且對于graphite使用起來也比較熟練，所以我們也沒有同時去上cAdvisor。
容器監控 — dAdvisor
? Docker Advisor
? 采集：CPU, 內存，磁盤，網絡
? 集成現有 Graphite
? 統計數據方便（Graphite 內置一些操作符）
? 呈現方便（Graphite Render URL API）
? 開發量不大
最后我們考慮到簡單我們就自己寫了一個容器監控，我們也就follow谷歌的這種 cAdvisor命名方式，因為C的話是代表contianer，所以我們就直接叫了一個Docker的dAdvisor。它的功能實際上就非常簡單的，主要就采集這幾個方面的數據，CPU、內存、磁盤、網絡，這些數據實際上都可以從kernel cgroup直接就能拿到。另一方面和現有的 Graphite 集成，開發量也不大，所以容器監控這一塊就可以非常快速的滿足現有的需求。
Time Series Database — Graphite
? 優勢
? 老牌（Since 1999），已有服務，經過驗證
? 簡單、內置 aggregator，Render URL API
? 劣勢
? 項目及社區已經幾乎停滯
? 集群化配置復雜，需要詳細規劃
? 缺乏多用戶認證，授權機制，黑白名單太單薄
? 數據刪除缺少 API
Time Series Database 現在用的Graphite，一個是因為它非常老牌，已經有10多年歷史了，用的地方非常多，在公司內部也是非常多的地方在用，所以我們也就相對于是現有的這種background 直接就用 Graphite。另外粗看起來Graphite好處就是比較簡單，包括它有一些內置的aggregator的進程，類似于proxy的東西，所以這個 aggregator，它可以實現一些數據簡單的算法（sum ，average等算法），所以對我們來說非常的好用，比如我可以將所有的計算節點上的同一個服務的容器監控，然后經過像這種求average后，我們能夠拿到這個服務的平均值，所以這些內置的功能的話相比Zabbix來說就會非常方便。除了像aggregator這一方面的話，還有就是它的呈現非常方便，也就是它的輸出，它的Render URL API 是非常簡單好用的，包括能夠進行一些簡單的算法，包括對于多種數據類型的輸出，像一些圖片或者是json或者是一些裸數據的輸出。這樣子在業務層面上實際上是能夠快速的就把這些數據以多種方式展現給用戶，當然最常見的就是一些監控圖片展現給用戶。或者我們可以拿一些json數據，就是用一些JS的畫圖工具自己重繪，這個也是非常方便的。
當然它的劣勢也經過一段時間使用的話也比較明顯，一個是項目和社區幾乎已經停了，如果你發現現在有不太滿足你的功能的話，在短時間內的話你幾乎是可以預計這些功能是肯定不會有人再需開發的。如果要自己去彌補這些功能的話，對于像可能只有公司規模更大可能會投入一些資源去自研或者是彌補它的功能缺陷。另外一個就是集群化的配制非常復雜，Graphite是有三個進程，你要實現數據的shading和數據的replication，這個是需要詳細規劃的，否則的話你后面要實現數據的遷移，這些幾乎都是一些運維的成本。我們如果作為一個平臺的話，實際上它會缺乏很多的API，包括像數據刪除，還有多用戶認證、授權，這些機制實際上都沒有的，所以對于數據安全這一塊的話是非常弱的，也就是它僅有的安全機制就在于黑白名單，黑白名單的話顯然是不太可用的，因為你即使限制了數據的這種合法值，但是你沒有認證授權的機制的話，實際上每個人都可以去寫的，這樣的話數據可能保證不了安全。
服務發現（Service Discovery）
? 負載均衡/反向代理方案
? HAProxy：Marathon 支持，用戶少
? Nginx：大量用戶
? 服務發現
? Flask 推送，SSH，不可靠，不安全
? Ansible 推送，SSH，不可靠，不安全
? event bus + guardro-template
服務發現，在Marathon upstream原生是支持這種 HAProxy來作為服務發現機制的，但是 HAProxy在公司內部大部分業務都是采用的Nginx， HAProxy用戶非常少，所以我們也沒有支持HAProxy，所以選用的是Nginx。服務發現，我們實際上有三個過程，因為我們的項目是用python寫的，所以最早是用Flask，有關我們的Marathon整個集群是用的Ansible，對于Ansible這塊也比較熟悉，后來換到Ansible，都會發現SSH都不是非常可靠，因為對于有一些主機來說，它的SSH狀態可能是不太穩定的，或者是說你要配制一些Key之類的，就是對于這種要服務發現來說都顯得比較重，所以我們后面就實現了基于event bus+ guardro-template的方式來實現服務發現。所以前面兩種方式都沒有用了，都全部采用后面這種方式，而且工作的也非常好。
日志
? ELK (Elasticsearch + Logstash + Kibana)
? 延時較高（分鐘級）
? 只支持格式化后的日志（for machine）
? 用戶訴求
? 低延時（秒級），準實時
? 裸日志（for real person）
? 備份日志（Apache Flume）
日志，我們最早采用的是ELK，也是考慮到也是有限額的服務，但是采用之后用戶對于真正使用ELK去排障去做呈現、做報表做一些搜索、檢索之類的，在我們看來幾乎沒有，因為很多用戶都不習慣這種使用方式。另外一個就是延時也比較高，支持格式化后的日志的話，所以它對于要仍可讀的話理解上會比較困難，因為即使是你把所有的裸日志都采出來的話，因為它每一條日志都切片，都打了一些tag所以看起來也非常頭疼。用戶最終的需求目前來看就是低延時，我需要一些準實時的日志，另外就是要裸日志，裸日志好處就是我仍可以讀，我一旦有了裸日志實際上就對這種裸日志進行任何的處理，包括像上云做一些計算，然后再包括到ELK之類的都是可以的。
現狀與展望
現狀
? 處于活躍開發狀態
? 接入了幾十個業務
? 主要業務類型：服務型，RPC，Worker
? 服務型業務 QPS 大于 10 萬
? 4 個數據中心
關于現狀：我們項目已經開發了挺久了，從2014年到現在超過一年了，現在還處于一個活躍開發狀態，因為我們的人手確實也不太夠，因為彈性計算平臺包括像底層的建設還有整個公司所有的這種轉碼業務實際上都接到我們的平臺，包括短任務這種量是非常大的，我們的容器每周會達到200多萬的量級。現在開發這個業務的人手遠遠不夠，目前也接入了一些業務，但主要在這幾種類型，一個就是服務型的，就是Long-running service，另外像RPC，因為很多RPC的發現實際上都不需要我們做的，因為他們自己會基于JK或者是基于其他機制來實現RPC的服務發現，所以RPC和這種Worker類型的話，實際上對于我們來說它需要的服務的要求是最低的，這三種業務實際上現在是主要接入的業務類型。目前在線的業務QPS我們已經超過10萬了。
展望
? 支持短任務
? Quota 和計費
? Web Console
? 內置典型服務（如：Tomcat）數據統計
? Docker 持久化卷和跨主機通信
? 支持更多類型服務：Cache, DB, MQ 等
最后是一些展望，第一個是Web Console ，Web Console 也是為了迎合用戶對于虛機使用習慣，你雖然提供了一些容器給我，但是對于他是一個黑盒子來說，總是會有強烈的需求我想進去看一下到底是什么樣的，所以Web Console 我們希望能夠改變用戶在里面裝SSHD這種服務的習慣，然后通過也是類似于像Web VNC或者這種WebSocket（39：52英文）的這種類似，讓用戶在瀏覽器上獲得一個交互的Console，能夠對于每一個容器能夠進行交互式的操作。內置典型服務的數據統計，這個也是我們根據接的業務來看的話，實際上有非常多的是基于Tomcat這種java的這種后臺服務，所以這一方面我們可以針對這種服務做一些builtin的數據統計、監控，然后就是給用戶一些額外的監控數據。第三個Quota 和計費，其實Quota 和計費在私有云來說對于公司內部來說，基本上相當于優先級非常低的一個功能，如果業務需要的話，需要這么多資源，實際上你都得給他。Docker 持久化卷和跨主機通信，實際上我們現在因為接入的這些數據類型對于持久化卷和跨主機通信這一方面的要求實際上都不高，因為服務的話都是通過服務發現來接入的。因為我們內部的云平臺實際上對非常多的中間件服務還有DB cache、MQ就是各種公共的服務實際上都有專門的團隊，都已經把它云化了，所以各種后臺寫業務邏輯的開發者的話，實際上大部分都是用的公司的私有云服務，所以對于持有化卷的需求的話也是比較少的。支持更多類型的服務，也就是我們在支持像long-running 的web service ，worker，RPC這些業務之后，也就是隨著Docker的這種開發對于持久化卷和跨主機通信方面的進展，我們也會在業務類型上進行一些橫向擴展，比如說支持一些Cache、DB、MQ之類的業務類型。最后還有可能會支持短任務，因為對于短任務來說實際上API是最方便的，很少有人會通過WebUI去提交一些短任務，那樣子的話效率太低了，所以我們現在的短任務是跑在一個cronnos平臺上面，那個任務量是非常大的，我們后面也考慮會把那個任務接入到QAE平臺上，可以進行一些數據統計之類的工作。我的分享就結束了，謝謝。