經過了十個城市的路演，華為HDG線下沙龍終于來到了首都。在北京，開發人員之多，關注的技術領域之廣，討論的話題之深入，堪稱HDG歷屆參與討論者之最。

趙陽是華為PaaS平臺資深架構師，也是北京站***位發言的講師。他本次演講的題目是《華為PaaS公有云服務實戰分享》，他告訴記者，他主要是想分享華為FusionStage團隊在公有云上的實踐，包括華為公有云交付的挑戰、華為FusionStage團隊在公有云上提供的容器服務Cloud Container Engine(CCE)，以及華為對容器技術、容器服務的理解。

以下是他的現場演講實錄：

容器云的簡介。我不知道大家看完之后是什么感覺，我是覺得挺專業公司做出來的視頻比自己做的好很多，這也是我們今年的感想，自己一定要做自己擅長的事，因為之前我們是自己做的，無論是自己看還是給別人看，大家都覺得比較low，我們就請了一個專業公司。如果大家覺得做視頻很有趣，也是一個很有前途的行業。

今天我們主要的話題，我是***個話題，當然全天都是圍繞華為的PaaS平臺來展開的。我們為什么一上來先講公有云呢，也是因為現在大家很多的工作已經在公有云上面使用了，大家除了使用國外的亞馬遜，還是國內的阿里，還是其他的公有云，大家都有一些直觀的感覺。所以我們先講一個比較接地氣的題目，逐漸再展現到技術細節。

我不知道大家有沒有用過華為的公有云，如果用過的可以舉一下手，說明我們還有很大的空間。華為的公有云已經做了好幾年了，從開始我們并沒有大幅的去推廣，因為當時最早做的時候，主要是以一個技術驗證和支持大型企業客戶為目的。大家可以看到，2011年我們就開始搞，但實際那時候整個行業對于云的理解都是比較混合的，有人說虛擬化就是云，有人說把一些機器堆起來外服務器也是云。逐漸到了2014年、2015年大家真的切實使用的云，大家覺得概念無所謂，主要是用起來好不好。基本上我們認為針對云***的市場還是應用的開發者，其實對于企業來講他們現在還有很大的疑慮，就是我到底放到云上有什么好處。我們總是說云是可以省錢的，但是對于很多土豪的企業來說不在乎這個點，或者他有很多的考慮，我的數據會不會被人偷走了，或者哪天宕機了，我會不會有業務損失，這些都是問題，這也是我們云要實際改進的。這個表格里面對于開發者來說，很多時候我們不會那么在乎，比如說我今天一個代碼跑在上面，可能晚上12點機器停5分鐘，對于大多數人來說都是不接受的。我們覺得這個市場對于開發者是很重要的。

我們這個里面做了很多的服務，這個服務很多也是對著亞馬遜，因為亞馬遜是行業的一個標桿，所以我們沒有必要跟它搞的那么的不一樣，所以我們還是對著它做的。我們做了云計算、存儲、網絡，上面的應用服務，還有一些附加的安全服務，這個基本是一個IaaS+PaaS的平臺。我們可以看到現在華為主要想的是什么，我們首先要把國內的市場覆蓋，所以我們一定要爭取在各個省，或者是主干的節點上建數據中心。因為華為一直是做網絡的公司，我們一定要保證網絡的體驗，不能讓大家覺得布了幾個點以后，時延那么大，這是最主要的考慮。所以我們現在一直在建設各種的數據中心。整個建設過程中提出了很多要求，對于數據中心的能源，還有對數據中心的可靠性，這些可能在成本上會提高，但是對于大家的業務也是有好處的。

PaaS是我們整個公有云的一部分，PaaS的定位是什么，就是服務應用開發者。應用開發者就是整個應用全生命周期的管理，就是應用的開發、測試、部署、上線、運維，還有在業務有些變化的時候做彈性伸縮、擴容等等。這個過程里面我們定義了一些服務，最開始的一個服務我們把它叫做云的應用引擎，這個比較像PaaS，就是我把代碼扔上去，別的什么都不用管，我也不知道代碼跑在哪兒，我也不知道它有沒有一些共享之類的。但是我通過云服務保證你的代碼可以被通過網絡來訪問的。所以我部署上面以后會有一個域名，我通過域名來訪問。隨著到去年的時候，由于docker的火熱，整個容器市場被炒的很熱。很多用戶說我希望往下沉一點，不需要只是把代碼扔上去，我還想操控我的容器，或者我想自己管理我的集群的可靠性、可用性，或者說我應該配它的網絡存儲等等。這個時候我們做了一個新的服務，叫做云的容器服務，這個基本也是跟其他廠商的PaaS服務去對應的。另外我們現在還在規劃一個服務，叫做云的編排服務，這個服務對于應用來說，尤其對一些復雜的業務系統來說是比較有益的，我很難保證有一兩個節點跑一個完整的系統。比如很典型的像電商的系統，從一個用戶登錄，到搶購，下訂單，購物車，***的結算，物流等等，這里面可能會有十幾個模塊，這些模塊之間的依賴關系是誰來管理，我們希望通過云的編排的服務來完成。當然這個服務現在還在做，大家現在到公有云是看不到，還在做內部的內測。

我們現在想強調的是什么呢?我們無論做多少個云服務，下面是一樣的，這是我們華為的核心理念，就是我們一定要有一個公共的底座。這個底座既能服務私有云，也能服務公有云。大家可能會覺得有點不可思議，公有云和私有云的場景是有很多區別的，但是我們希望把這個公共的組件，包括我們下面講的基礎的框架，還有一些云上的中間鍵，和云上會用到的管理服務，把它們都抽象出來。抽象出來的好處是什么呢?就是我針對各種不同的場景，可以靈活的去組裝，把它組裝在一起以后，能夠支撐我一個或者多個場景。大家知道華為同時還在做很多通信的行業，包括網絡，包括物聯網，包括無線通信等等。這些場景下我們也要用PaaS，這個大家在傳統的認知上是不太理解的，就是為什么要有基站，要有網關，這些東西要用PaaS。這也是華為現在強調的理念，因為我們在做專有設備，無論從運營商的角度，還是從客戶的角度，都是覺得不符合現在的潮流，所以我們要做一個全部軟件化的、云化的平臺。這個平臺里面具體的細節我們到下午的時候，幾位架構師都會詳細的講，所以這一塊我只是強調整個的概念，就是同一個底座，去支撐上面各種場景和各種云服務。這種大家也會聯想到阿里***的平臺，其實也是很像的。

我們再轉到云容器服務里面，云容器服務我們想做的就是一個PaaS和CaaS的混合體。大家應該都用過一些各種各樣的容器服務，容器服務本質上講就是想要用戶很容易的把，比如說docker，Kuberentes，這些開源的東西用起來。這個用的過程中我們首先要保證用戶不要自己再去捕捉抓這些東西，因為你從網上下載docker引擎，再找linux的機器裝起來，再配網絡啊，各種東西，再裝Kuberentes，就算是熟練一點的老司機，估計也要搞一兩天的時間。這個時候對于你應用開發的過程，這個過程是無效的，就是你學了那么多，你的應用代碼不太能跑上去。我們希望的是通過一個封裝好的服務，能夠讓用戶不要關心這些東西，我只需要把我的容器鏡像，或者我的源代碼直接扔到上面就可以跑。這個對于用戶的好處就是，還是像傳統的PaaS那樣去用容器，這是我們整個的理念。它的好處就是你同時享受到了容器的好處，比如快速部署、快速啟動、快速擴容等等。

我們把這個服務打開看一看，大家可以看到也沒有那么復雜，真的做一個容器的服務，其實核心不在于你用了什么***的技術，而在于你能夠把它調養的比較好。這個有點像買一個車一樣，你買一個300的引擎，輪子特別小，也沒有用，我們主要是整合在一起。里面用了很多開源的組建，包括Kuberentes，包括docker的鏡像倉庫，包括一些開源運維的工具，像kafuka、ELK這些東西。我們主要做的包裝一個是給用戶一個界面，一個是圖象化編排的，剛才視頻也講到了，還有我們在Kuberentes之上自己定義了一層所謂的容器編排或者是急性調度的一個封裝層，這個封裝層的目的是為了提高Kuberentes的應用性。我相信很多同事都看過Kuberentes的一些簡介，它的模型對于我們比較學院的同學來說感覺是奇怪的，它定義的無論是名字還是概念都比較特別。所以在這個階段我們是希望把它封起來，你不要再把pod，server，什么node的這些概念，你要的其實是資源池，我要部署容器，我要應用跑起來，我能夠訪問。在這上面我們也額外加了一些自己添加的特性，包括我們講的怎么去支持多個Kuberentes集群的，怎么去做這種比較好的調度，怎么在這個平臺上面通過一些策略，去實現灰度發布，應用升級等等。還有剛才一直在講的圖形化編排的工具，幫助用戶組裝自己的應用。還有整個平臺，因為我們是放在公有云上，公有云上用戶最關心的三個點，***是可用性，第二是用戶體驗，第三是安全。所以我們一定要把安全搞好。再有這上面會有很多網絡相關的條約，現在容器本身已經比較成熟了，但是容器的存儲和網絡還是在不斷演進的過程，所以我們會把各種新的開源的，或者結果調優的容器網絡的內容都整合到這個服務里面。

展開來講幾個小點，我們跟標準社區的東西不太一樣的東西。***我們做了一個鏡像倉庫，這個鏡像倉庫本質上也是基于標準dockerhad，但是我們主要做的是一個租戶的隔離，就是保證不同租戶之間的鏡像是不能互訪的。這個對公有云是很有意義的，因為很多人用公有云就是想把它當私有云池子用，這時候你要保證安全性。所以首要的***步是要隔離起來。后續我們還會加一些新的跟鏡像相關的，基于開源社區的一些特性，比如說基于docker我們做鏡像的簽名，還有基于OS的另外一個項目進行鏡像的掃描，這些都是為了保證安全性。對于用戶來說，對于他上傳的每一個鏡像生成一個報告，***你的鏡像有沒有被鉆該，第二你的鏡像里面有沒有含有一些安全漏洞或者威脅，這樣對于他的應用是很關鍵的一點。

第二個就是剛才講到的我們怎么去做大規模的部署，因為在公有云上面很典型的場景，電商啊或者網站，這里面都會有一個對于量的要求。所以我們不能說只用比較少的資源，能滿足所有的場景。所以在這個場景下我們需要做很多的調優，比如現在基于社區版的Kuberentes，對它做一些規模和性能上的調整。當然這個調整最終還是要回歸到社區，當然可以在我們的服務上先用起來，但是最終我們會在Kuberentes里面看到這些新的特性。再一塊就是我們講的，你在部署容器的時候，如果大家用過默認的docker，你在部署的時候需要添很多環境變量啊，端口啊，還有依賴管理。這些東西我們做一個簡單的封裝，我們管它叫一個部署的模板，這個模板里面簽了很多用戶常用的配置項和參數，用戶可以基于這個模塊，可以快速的、批量的部署它的容器，而不需要一個一個的管。這個大家可能覺得docker也是類似的，其實從理念上確實是這樣。

這個圖形編排我們也講到了，我們希望通過一個界面，可能對程序員來說，很多程序員是厭惡界面的，但是對于應用的開發者或者是上層的系統設計的人員來說，他希望能夠很直觀的看到我整個系統的關系，所以我們認為還是必要的。我們的愿景是在整個的視圖上能夠看到很多別的云的服務，比如我現在只是容器服務，未來可以用容器去對接數據庫，去容器去對接負載均衡，對接大數據等等，這樣我的容器服務就變成一個應用總的入口，大家可以在上面組裝出自己的應用系統。

還有一個很重要的就是應用的運維層面，大家都知道我這個應用跑起來以后，整個應用的生命周期里面部署是一次性的活動，部署以后可能會長期的運行。長期的運行過程中其實有很多的指標是需要關注的，比如說我的資源使用率，我的系統有沒有異常的事件，有沒有告警，還有各種應用程序輸出的日志。這些東西我們都是借助于docker和Kuberentes已經定型的一些通道，比如說它的監控的代理，它的docker后臺的API，把它們集中的導出出來，放在我們基于ELK和一些改進的統一的運維系統里面。基于這個系統我們可以做到，***用戶可以實時的看到自己應用的健康狀況，資源使用情況，日志告警。再一個就是基于這個數據，我們可以做彈性伸縮，可以做擴容。這個就可以應對很多典型的電商，或者是網站的場景。

另外一個我們一直在強調的，也是今天開發者社區一直想跟大家強調的一個理念，我們一定是基于開源的。這個東西現在的趨勢很明顯，你再自己搞的話，就算你公司有幾萬人，也搞不過全世界的開源力量。所以我們現在整個策略一定是源于開源社區，把我們做的一些改進回饋到里面。當然這個是動態變化的，如果大家去網站上找，可能有些順序不太一致，但是基本上我們可以說我們現在國內的貢獻度是一樣的，就是對于docker社區和Kuberentes社區。這兩個社區大家可以看到里面有很多熟悉的面孔，像谷歌，(18：59)，docker公司，還有IBM等等，所以這些公司我們也可以認為，其實大家都有活干，雖然我們在某些客戶的時候，大家是去搶錢的，但是從技術整體的愿景上，大家都認可我一定要搞一個公共的平臺，一定要搞一個所有人不會再重復建設的平臺。這個應該是一個生產力上的提升，大家不要蓋一樣的房子養活自己，這個對整個社會沒有太大的效益可言。

我們也可以基于現有的服務分享幾個案例，當然這個案例大家應該都比較熟悉這種典型的場景，就是電商的場景，無論是京東也好，阿里也好，或者是很多網站，唯品會，美麗說，大家都會有這種場景。就是雙十一或者某一天來了，我今天就要搞促銷，搞促銷的時候，跟平常的業務量是有幾十倍、上百倍的變化。也時候怎么辦呢?傳統的情況下我會提前兩三天把資源準備好，當然這樣肯定是最保險的。當然其中也有一些我認為沒有那么關鍵的業務，在整個電商系統里面搶購至少不會死人，不會造成用戶的錢被不正常的透掉，或者是數據庫的內容不一致。我們覺得這個系統可以作為容器改造的試點，所以我們拿它做了一個嘗試。這個嘗試在前兩天雙十一的時候已經產生效果了，就是我們做了一個手機的預約搶購的模塊，這個模塊大概在兩三天之內服務了幾十萬的搶購的請求。在這個請求來的時候，我們會通過容器服務實時的創建事例，一旦這個請求沒有了，我們就把這個事例刪掉。這樣首先保證了業務的敏捷性，保證幾分鐘之內擴出很多的節點。再一個對于研發的人員來說，這也是一個很大的好處，我不需要再去準備各種各樣不同的環境。我們一直在講DevOps，其實DevOps大概在上個世紀就開始有人講了，但是真正能夠落地，容器是很關鍵的要素，它保證了我真的可以實現一次代碼處處運行。所以通過這個，我們也改變整個研發的流程，最終的效果也是不斷的改進電商網站，或者追求新的特性的時候，可以做到非常快的周期，這應該也是從業務上直接的好處。

另外還有一個也是我們測試的客戶，他們做的是一個有點像租車管理，有點像滴滴或者神州這樣的，大家會做一些基于手機的APP。以前的場景下是說我做一個大的應用，這個應用里面把所有的組件都綁在一起。現在因為從手機APP里面，兩三天就會下一個新版本。這時候如果你天天打一個大包的話，效率是很低下的。客戶主導做了一個微服務的改造，這個改造把APP里面切出很多很碎的功能點，每個點是一個獨立的微服務。這個情況下如果我還用原來的虛機的形式去部署，就是我拿一個很大的資源跑了這么多的服務，其實是達不到微服務資源隔離的要求的。這個場景下很自然的也會切換到容器，通過容器首先保證系列路的隔離，再一個保證快速的升級和部署。這個我相信大家也都能理解，作為容器應該是很典型的場景。

講了這些場景之后，大家應該會有一些問題，你做了一個云服務上好像也沒有什么奇怪的，把docker、Kuberentes自己加點代碼，包一包，發上去就完了。在這個里面公有云從我們的角度看來，或者從我們的經驗看來，困難并不在于你寫代碼，困難在于整個運維的過程。因為公有云大家都知道，競爭很激烈，任何一個廠商基本上像賽馬一樣，一會你超過去了，一會我超過去了。這個場景下你怎么能夠保證你的服務持續的會有人用呢，這個服務本身就是一個DevOps的方式。所以我們現在基本定的是每個季度就會有一個大的發布版本，這個版本里面會加很多的東西，這些東西基本上都是一個逐漸去疊加的過程。這個疊加的過程我們發現，我可能改系統，我可能改了一些后臺的東西，或者加了一些用戶可見的特性。這些東西一步一步的堆上去，對于整個工程來說是很大的一個挑戰。這個挑戰是內部的。還有一個問題是外部的，大家都知道華為只在國內運營了自己的云，在國外我們的策略是幫助運營商客戶去建立云。所以大家假如出國或者看到一些新聞報道會發現，現在很多運營商在搞云，可能很多傳統的我們以前的知識是，這些互聯網的新貴，像亞馬遜、谷歌他們在搞云。實際從華為的理解，他們是面向一類場景，但是從傳統的客戶，或者是一些成熟市場，像歐洲或者拉美，大家都覺得最可靠的人還是運營商。***運營商從來不會亂扣大家的錢，第二運營商過兩天就倒閉了。所以運營商建云的話，對于很多人來說是一個可以理解的事情。所以我們現在是幫著大家一起建，大家會看到我們一方面在自己不停的做東西的情況下，還要不停的跑到外面去部署，我們會跑到歐洲，跑到拉美。這些每一個版本，我們都要去升級，都要去保證在業務不終端的情況下升上來。所以這是一個非常大的挑戰。

這對我們整個團隊和工程能力是很大的要求，在這個要求之下，我們也是首先自己在做DevOps，就是我們不再是一個口號。DevOps可以從天上一直做到地上，我們覺得真正從搞一個公有云的場景下，一定要搭建一個完整的，基本可以做到全自動化的流程。當然這個過程是很痛苦的，就是我們怎么去建這些環境，怎么打通之間的網絡，怎么保證它們的一致性，怎么去構建一個全自動的流程。這個結果是什么呢，結果就是我們能夠做到發布一個新版本，在一周之內能夠發送到全球的各個節點去，通過一些自動化的腳本，或者運維的工具，做到無損的升級。這是公有云后來大家去比拼的一個關鍵點，就是你的軟實力是什么，而不是你的特性點比別人多多少，你的功能比別人強多少，或者你的版本里面有多少版本。所以這是我們現在還在運營建設的一個過程。這個里面我們也發現了很多問題，把它再沉淀到剛才講到的版本里面，再不斷的滾動式的改進。所以這個也是我們很多華為部署到的一個新的世界，比如以前我們做電信的，基本上可以半年或者一年一個版本，版本出去了，就穩定運行，沒有太多的回饋或者是迭代的過程。但是在云的時代里，大家都是在一個起點上。

好，今天我講的內容主要是這些。

(結束)