《專家觀察 | 湯人杰：“浙江移動DCOS規模實踐與演進”》要點：
本文介紹了專家觀察 | 湯人杰：“浙江移動DCOS規模實踐與演進”，希望對您有用。如果有疑問，可以聯系我們。

由工業和信息化部指導,中國信息通信研究院主辦,業界知名組織云計算開源產業聯盟(OSCAR)承辦的2017全球云計算開源大會于4月19日-20日在北京國家會議中心順利召開.本文為本屆大會嘉賓分享的大會演講速記內容,敬請瀏覽.

嘉賓介紹:湯人杰

公司職務：中國移動通信集團浙江有限公司高級架構師

大會演講速記

非常榮幸有機會來這里跟大家分享我們浙江移動在云計算方面的實踐.我主要分享的議題是DCOS,可以說谷歌很早就有,在運營商內部我們自主研發這個平臺還是做得比較早.先講一下整個驅動力,云計算的驅動力有很多種說法,把大家也都說得云里霧里.

有很多的名詞,比如像去IOE、DevOps敏捷開發,在這些東西的背后,云計算最根本的商業驅動力是什么,更高的效率、更低的成本以及更敏捷的業務響應,這樣就能支撐我們降低TCO,第二是小前臺、大前臺的快速業務敏捷的變化.

為了達到云計算的效果,我們浙江公司這幾年來從傳統的IT孤島到最后的DCOS化,中間也經歷了一個漫長的歷程,前前后后七八年總是有的.
最早的時候我們用的都是小型機和高端存儲,在上面獨立做應用,都是孤島的程序,每一套應用有很多套,每套都是獨立的,機器也百花齊放,有用惠普的芯片,也用Spark的芯片,還有用IBM的,各不相同.

那時候我們做了標準化,都用了X86芯片.再接下來我們在IaaS層做了資源池化,我們當時用VMware軟件做了虛擬化,我們實現了虛擬機級的彈性伸縮,超過單臺物理機就沒辦法彈性伸縮了,所以是非常有局限的.后來我們又做了PaaS化,做了集群級的彈性伸縮,通過集群間的負載均衡,做了PaaS的云化,我們在中間件這個層面做了切換.

最后我們參考了谷歌和阿里云的架構,做了DCOS化,真正做到細粒度的資源貢獻,實現大云,這時候我們資源調度和彈性伸縮不再局限單臺物理機,而是在整個浙江移動的數據中心就可以快速切換,實現了數據中心級的彈性伸縮,這也就是DCOS名稱的來源.這種級別的彈性伸縮和資源隔離是DCOS化一個非常大的特點.

這個歷程里面,IaaS層云化不足的問題有幾個地方,一個是部署是靜態的,快速的應用部署受到很大的制約.

其實說到底,虛擬化無非就是裝了個VMware軟件,上面把它格成幾個虛擬機,跟在物理機上除了管理方便一點,沒有特別大的區別,可能資源的利用率更細一點,大的區別沒有,因為它的應用還是要完全重新部署的.

彈性伸縮更加談不上,在一個虛擬機內部彈性伸縮,客觀上講,當時我們甚至沒有在物理機內部做彈性伸縮,沒有必要,找不到任何的驅動.利用率低,CPU平均利用率10%.

在這個情況下,我們提出了我們整個云平臺的藍圖,我們要構建我們的大云,我們要建浙江移動自主研發的大云,做我們的DCOS.這個DCOS大概是在2015年、2016年這個時間完成的,大概分成這么幾個部分.底層還是IaaS層,IaaS層不細講了,重點講PaaS層.PaaS層上面我們做了一個彈性計算服務平臺,其實跟阿里的飛天是一樣的.

我們做了一套分布式協調服務、分布式調度服務和負載均衡的一套東西,整個一套東西能夠實現我們在數據中心層面的資源調度.上面我們到底調度了什么進程,比如說有中間件的進程,有數據庫服務平臺,還有大數據的一些服務,這是在它之上的承載的一些服務,網管的支撐系統,業務的支撐系統,還有管理信息系統等,這個是大類,不重點展開了.需要去運維的東西還有一個云管理平臺,通過這個云管理平臺我們可以做一些一站式的開發,可以做一些運維、配置管理等等,包括一些容量的管理.

什么是DCOS,數據中心操作系統,是整個移動公司所有的異地的機房全部加進去,所有機房里的所有服務器我當成一個大型計算機來調度.

通過這個思路,我們打破靜態隔離,實現資源共享.云化有兩個重要的特點,一個是資源調度,一個是資源隔離.在資源調度方面,DCOS實現了數據中心級的資源調度.

在資源隔離方面,我們也拋棄了傳統虛擬機比較笨重的模式,采用容器進行資源隔離.

下面是個互聯網的圖,不同的幾種運算模式,可能有些說是晚上運算比較密集,有些說白天比較密集,如果聯合起來統一的資源調度,整體的CPU利用率就會非常高,削峰填谷,云化的集約效果真正體現出來了,不像以前純粹的虛擬化模式下,CPU利用率仍然非常低.

這一頁是我們當初1.0版本的DCOS平臺整體架構,可以看到核心是采用Mesos這個平臺,用馬拉松作為一個任務型的調度器,Mesos作為一級調度,去分配資源,通過MesosSlave啟我的一個任務,里面的Container主要做仲裁的一些功能.

DCOS總體推進策略,DCOS這個平臺研發出來以后,在內部是有爭議的,大家認為比較先進,但是不一定穩定,確實也是這樣.我們當時就考慮了采用先前端后后端推進的DCOS平臺,先推進的是手機營業廳和CRM,然后是PaaS企業的核心服務,中心全部做了DCOS的改造.

看一下我們改造的順序,第一個改造的是我們的手機營業廳,手機營業廳做秒殺的時候性能不行,確實存在著瓶頸,當秒殺的時候基本上手機訪問量是平時訪問量幾百倍,這個時候確實性能產生很大的瓶頸,這個瓶頸有兩方面,中間件和數據庫,我們都做了改進,重點講一下中間件方面的改進.Web服務全部建議到了DCOS,服務的可用性99.99%,基本上很好的完成了當時秒殺的活動.

第二個是實體營業廳,所有營業廳的服務,我們十年以前就是三層架構了,首先是WEB層,后面是APP層,還有數據庫層.要改造,瞬間遷移,快速failover,把WEB信息無狀態化,前端能夠動態注冊,就像前面寫的服務的動態注冊和發現一樣,要能動態注冊和發現.

通過對它的改造,把有狀態信息都放在了Redis里面.這是我們浙江移動整體的架構,前端是WEB這一層,全部都把它做上去了.

我們當時第二個改造的時候做了一個中心化的改造,我們根據高內聚、低耦合、高自治、高復用原則,都說高內聚,怎么內聚,我認為是按照領域模型內聚的,以微服務的技術手段對它進行一個服務的部署和服務的設計.最終這些服務都承載在我們的DCOS平臺上去.

當時整個SaaS層規劃了14個核心的能力中心,當時有線建設的是訂單中心、開通中心、賬戶中心、計費中心和渠道中心.到這個節點上,基本上我們整體的系統已經全部搬到了DCOS上面去.當然大家也應該聽出來,我說的搬到DCOS上面去指的是WEB層和APP這一層,就是中間件的那一層,數據庫的服務到目前為止肯定還不可能實現數據中心級的伸縮.

DCOS建設至今,我們整體已經接入65套系統,從地市怎么分的,兩個分發,一個是按照地市支撐和省支撐.地勢支撐有24套系統,省業務支撐有41套系統.

如果按互聯網系統、前端系統、后端核心系統、外圍系統劃分,互聯網類有15套,前端系統有12套,后端核心類有14套,APP這一層,相當于復用的核心能力層已經遷移上去了.外圍的系統有24套系統已經遷上去了,包括金華綜合管理平臺、臺州考試系統等等.

DCOS無論在技術上還是實用性上還是應用的遷移上都應該經受了考驗,應該說相當的穩定和可靠.

這套系統我們有哪些創新點,一個,我們有一套ADCloud的平臺,通過和DCOS平臺對接,通過ADCloud平臺能夠打通開發、測試交付、運維部署全流程,實現代碼編譯、單元測試和生產部署的一鍵化和自動化,極大提高軟件開發部署效率.

第二個,向租戶開放一站式運維服務,整個DCOS平將發布、擴容、重啟、日志下載等等這些工作全部做到標準化、自動化,通過可視化界面讓運維管理人員、租戶人員自行管理,做到理解一致、執行一致、結果一致.

彈性擴縮容,傳統的在虛擬機時代我們說彈性擴縮容多么困難,如果平時部署在那邊不用又浪費大量的資源.

從傳統的方式2-3天縮短到秒級,業務進來以后,會收集各方面的信息,根據一個自己學習的策略,做到自動彈性擴縮容.

這是原來的開源產品不具備的功能,雖然說我們也是整合了開源的產品.這里講彈性擴縮容怎么做,我們從各個層面,Docker、Mesos、Marathon、HAProxy、Application,最后形成了給Marathon下發的擴容的任務.

 

最后講一下DCOS3.0后續的演進規劃,第一點是統一API,現在是用Python寫的,后面會用Golang全部重構.

微服務設計,容器部署支持用戶自定義開發API,依托API功能擴展服務范圍安全加固.鏡像庫,企業級自定義鏡像倉庫.

融合支持,新增kubernetes、Spark、Hadoop支持,新增Array調度管理功能,支持灰度發布.服務集成除了現有的無狀態服務以外,我們將加入有狀態的服務,比如Redis、ES、MySQL、MQ.

另外一塊,我們將會增加數據持久化的一些服務,還會采用一些網絡層面的,使得DCOS平臺變得更加完善,能夠支撐更多類型的應用.

這個是我們的云管理平臺,我們現在也在自主研發云管理平臺,云管理平臺會有一個統一的門戶,通過一個總線下面有四大中心,通過一套資源接口平臺去對接底層的能力層.

最后是我們的數據資源池,Oracle這些目前包括跟阿里交流,他們也都是直接用物理機上做,因為Oracle這種東西太重,有狀態的服務實在太重,也不適合放到DCOS這樣的平臺里去,所以我的資源對大概就對接一個是數據庫、大數據、DCOS還有IaaS層,我們會把它對接統一封裝之后,在我們的云管理平臺里進行統一的運營、資源管理、運維開發的一鍵式支撐.

謝謝大家.

文章來自微信公眾號：云計算開源產業聯盟

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4094.html