作者｜牛繼賓編輯｜Bella云計算最終的目標是提供服務，將資源進行管理并變現為服務，進而支撐應用。本次內容主要介紹云計算服務與技術交付的關鍵一環——云管理平臺的架構與功能設計，通過演講者在云計算行業的多年實踐，從需求、實踐、應用支撐等角度對云管理平臺的定義、功能規劃、架構設計與發展、微服務化改造等進行全面的闡述，涉及的技術層次包括IaaS、PaaS、SaaS等。1 云管理平臺的定義、需求、功能與架構設計
云管理平臺的定義是提出來的，總結起來就是兩塊，第一是管理，管理公有云、私有云，形成混合云。第二是自服務，鏡像劃分，計量與計費，負載優化。云管理平臺最終的目標是應用在云平臺上運行時取得最優化的效果。大家熟悉的公有云有上云服務，能最大限度的保證應用的可靠性，我們自己設計一個云管理平臺時也要考慮這方面，還附加了一些外部系統的對接與管理功能。
說到云計算，大家會想到，跟云管理平臺有什么區別，是不是可以基于做一些云管理平臺？目前從我們自己的定義以及市場上的反饋來看，我們認為云管理平臺是更廣的范圍。我們可以把看作是云管理平臺下屬的資源模塊，云管理平臺可以管理多個版本。
有些企業會在不同的數據中心里部署不同的資源池管理模塊，在之上也需要一個云管理平臺來管理多個資源池以及管理不同的版本，另外還有很多虛擬化不是由+KVM實現的，比如、Xen等虛擬化，所以云管理平臺還要針對這種虛擬化做對接。從層次上來看，云管理平臺是解決用戶最后的資源使用一公里的問題，最終提供給用戶服務的是云管理平臺的自服務平臺。
我們實現的云管理平臺主要分三大功能：
云管理平臺主要有資源管理、運營、自服務三個功能，資源提供方比如存儲、計算、網絡。資源池最終交付給用戶的是一個一個服務，比如計算服務、存儲服務、網絡服務等IaaS層面的，中間件服務、數據服務等PaaS層面的。怎么交付給用戶的？是云管理平臺將資源管理起來，通過運營，在公有云上這種運營可以是計量計費，之后通過自服務界面把應用提供給用戶使用。
這是云管理整體的定位，它是承上啟下的。對下管理資源、對上提供應用使用的界面和API。如果創業公司自己設計一個云管理平臺的話，五個模塊必不可少，一是資源管理，二是運營管理，三是服務提供管理（使用界面與API），還有運維管理與安全管理。
這是我們設計CMP1.0時第一版的架構，拆分一下有資源管理系統、運營管理系統。資源管理系統負責物理機管理、存儲管理、網絡管理、多數據中心管理。架構圖右上角的模塊是一個專門的虛擬化管理系統，它也可以看做是一個資源管理模塊。
為什么把虛擬化管理系統拆分出來？因為虛擬化管理系統是云管理平臺一個比較核心的模塊，需要對它做更精細的設計，所以單獨拆分出來。 運營管理系統最終的目標就是將資源管理系統、虛擬化管理系統管理出來的資源運營成為一種服務，比如服務目錄就是將資源發布成云計算產品，工單管理、流程管理、計量計費負責用戶申請一個虛擬機或一塊存儲空間，怎么做計量計費，怎么發布出去。
再往上是用戶使用的自服務，運營門戶、管理員門戶，當然也要開放統一API，因為有些應用使用的不是自服務界面，而是使用API調用虛擬化、存儲、網絡。要做好一個系統，運維管理，比如監控還有日志分析等等，是必不可少的。在云管理平臺之外我們單獨設計一個運維管理系統，通過等采集模塊采集系統運行狀態，實時呈現給云管理平臺的管理員，這是CMP總體架構設計的1.0版本。
1.0版本的資源管理系統
首先看資源管理系統。 虛擬化管理系統可以看作是資源管理系統的子模塊。目前市場上常用的虛擬化大的用戶里最多的是。我們統計過電信運營商、銀行等等，占有量大概在80%以上。第二個是中小企業，用微軟hyper-v的比較多，還有、kvm、蘇研虛擬化。
我們在做虛擬化管理系統時是做虛擬化適配層，針對每一個虛擬化平臺做一個，這個可以下發指令、并反饋狀態，同時開放API針對管理層使用。比如虛擬機的基礎管理，像開機關機都可以通過做。在基于KVM去做的時候引用了虛擬化管理的nova模塊，主要目的是有了nova我們也沒有必要完全重寫針對KVM虛擬化管理的功能。
我們在設計私有云的時候，用戶對應用支撐這塊有很高的要求，比如數據庫服務，他會明確要求放在物理機上。 所以資源管理模塊需要做物理機管理，目前是基于IPMI實現的，可以做物理機的分配、自動安裝、自動服務提供。跟虛擬化的區別就是物理機的分配單位是一臺一臺的物理機，虛擬化的分配單位可以在物理機上做更小的切分。
還有存儲模塊。目前說云計算的時候大家一提存儲往往是提分布式存儲或者云存儲，類似對象存儲的實現。如果在傳統企業做存儲管理并將存儲形成存儲服務的話，還有一塊就是傳統存儲，也叫SAN存儲，包括FC存儲和iSCSI存儲。這種存儲管理的實現我們是通過標準的SMIS協議，如果沒有這個協議就要對接cmd line/shell腳本實現。
資源管理的網絡管理。云計算里面經常介紹SDN的管理，除此之外還有路由、交換機、防火墻，這塊的管理需要在上面自動劃分網絡服務，劃分一個VPC或者子網，需要通過網絡管理模塊API做對接和呈現。
最后是多數據中心管理。比如要幫一個公有云的客戶實現一個云管理平臺，這個公有云可能會在全國部署多個數據中心。涉及到一個云管理平臺對多個數據中心的管理，這是一種分布式架構的實現。比如說在數據中心里把或者作為一個資源池模塊，最終是一個云管理平臺去管理多個數據中心，并做整體平臺的運營和服務。
剛才簡單的給大家總結了資源管理這一部分，包括計算資源、存儲資源、網絡資源的統一管理。
2 1.0版本的運營管理
管理完之后是運營的過程。運營包括將管理完的資源發布成服務，需要一種服務模板的規劃設計。服務模板包括把一個虛擬機定義成一個服務，包括虛擬機的定義、發布、審核以及在界面上的呈現。在服務目錄之后，我們有了服務的概念，還要做計量計費，用戶使用資源時要做統計，公有云上可以收費用，私有云可以做跨部門之間的資源使用統計，這是訂單管理和用戶管理、資源使用計量計費三塊合一，也就是要確定一個用戶或者一個部門使用的資源時間時長以及最終的計量計費的過程。最后是運營門戶，運營管理員可以運營這些服務。比如公有云廠商定期有新的云服務發布，基本是在運營管理層面上做的。
我們做了一個總結， 應用在使用時主要可以分為兩種類型：實時交易類型和在線批處理。這兩種應用遷移到云平臺的時候都有自己的特定要求。
首先看傳統的交易系統，比如電商系統或者是CRM人力資源管理系統，它分三層：Web、App、DB。以前中大型的企業，比如銀行或者運營商都是放在小型機上承載的，Web用X86服務器，App可能用、放在小型機上運行，還有DB用或者DB2的數據庫，都放在小型機上。
阿里一直在提的去IOE，實際上是一種分布式架構改造，改造之后傳統的數據庫、DB2數據庫，逐步去做分布式數據庫或者是關聯不復雜的數據逐步往非結構化數據、內存數據庫做遷移，還有NoSQL數據庫，實際上數據庫是在逐步做新技術的引入，實現模塊化分布式改造。
如果我們把原先單一的數據庫改造成分布式數據庫，需要分布式數據庫的數據路由和集中訪問。到應用這層，以前我們說、，現在就改成微服務，比如一個一個的應用，每個應用單一化改造成單一的服務。有了微服務之后，在微服務上層還需要微服務的治理，比如服務編排、服務訪問路由。再上層就是用戶交互層。
3 傳統應用云化改造對云管理平臺功能設計的新需求
傳統的應用在改造成云化架構時帶來了很多需求：
總結一下交易系統跟批處理系統在上云過程中對云管理平臺的新的需求。第一是彈性計算，Web節點實時彈性伸縮。第二是App中間件層逐漸引入微服務，微服務架構有很多，設計出的微服務也很多，需要對微服務做統一管控。第三是越來越多的模塊，需要對產生的數據監控做更多分析。比如一個用戶三年前上云，現在數據中心積累了海量的監控數據，監控數據對他也是很有用的，可以做歷史趨勢的分析。第四是需要支持大數據類、開源數據庫類的開源組件對接與管理。
我們做了幾點，第一是虛擬機編排跟彈性伸縮。大家知道有自帶的彈性伸縮，在虛擬機這一層也需要彈性伸縮。第二是資源管理系統引入了微服務管理。第三是開源組件的支持，引入了+，把和spark的一些內容往彈性計算體系遷移，這樣云管理平臺新的針對應用的設計演進了一步。這是2013年1.3版本的設計，到2014、2015年3.1版本的設計，逐步引入彈性子計算系統。
云管理平臺最開始1.0的設計只是對資源的管理，到了2.0、3.0的設計時webapp數據存儲到db，我們逐步發現上云的過程中，應用會對云管理平臺提出新的需求，如何調整、如何增加新的技術實現對應用的支撐。接下來看一下容器跟微服務引入之后對云管理平臺本身設計架構的改變。
4 容器與微服務化對云管理平臺新的架構設計的支撐
兩張圖的對比。左邊是1.0的架構，它的部署架構包括自服務門戶、門戶后臺、用戶服務、運營服務、運維管理。運營服務里面有訂單管理、計費管理、AZ配置。所有業務都是耦合的，如果要升級一個功能整個服務都要升級。這是一個不利點，而且開發測試團隊也不明晰webapp數據存儲到db，升級任何功能點都要對模塊進行重構。所以我們在微服務上考慮引入這樣一個架構，運營服務、產品支撐和運維管理里面每一個功能點都單獨做成一個微服務。
微服務的系統架構主要是兩個分離： 第一是客戶交互與業務邏輯分離。前臺的JS與后臺java分離。 第二就是微服務化，把這些服務都通過服務管理、服務注冊、服務發現管理起來，前臺對服務的使用都通過微服務管理平臺發現相應的服務，導流到各個服務節點上。云管理平臺最終提供很多產品，像云主機產品、塊存儲產品等等，我們會把這些產品做成一個一個的服務，通過微服務化可以實現數據中心里每個服務的自治，不同服務的升級可以完全基于自己去做，只需要保證對外API是統一的。
再一個就是分布式，我們做了無狀態化可以做更好的云管理平臺本身的彈性。比如一個大的運營商是集團級的，用戶量有上千萬，每次促銷時云管理平臺自身的壓力也是一個比較大的點。每次促銷都是先備很多虛擬機上去，現在微服務化之后通過無狀態化可以實施自動的擴展。
微服務化之后每一個管理平臺最終的狀態是什么樣的？第一是運營管理門戶，每個門戶有訂單查詢、產品目錄、工單等等呈現。在門戶選擇一個服務就會通過REST API的形式到運營管理API上，每一個API都是一個單獨的服務。點了一個服務之后，這個服務的邏輯實現是在后臺，通過微服務管理平臺上找相應的已經注冊的服務，然后服務將最終的邏輯實現。
資源管理平臺也是同樣的概念，比如說資產管理、故障告警等功能最終會落在一個個服務的API上，再通過服務發現、服務管理功能導流在后臺服務做統一處理。
微服務化之后有一個比較重要的就是對服務能力的監控。目前我們是兩種方式，一種方式是用實時采集呈現，還有一種是實時呈現完之后歷史數據的存儲，目前是用Spark集群做。需要對每個做實時呈現跟監控，這是做平臺必不可少的模塊。
再就是日志，比如說調用的日志，從用戶申請一個虛擬機的服務到每個服務之間的調用是7步左右，這7步任何一步出現了問題都要做產品回退，因為這會影響最終使用，所以需要對每一步的調用日志進行監控和采集，以確保可以排查哪一步出了問題。日志我們采用了開源的 ，做了一些封裝和改造。最終在日志管理的界面上呈現。
最后就是微服務化之后系統模塊之間的關系圖。以前就Web、App、DB三個服務，微服務化之后變成30幾個服務，每個服務之間也有調用關系，這種關系圖是維護系統運行的最重要的模塊。CMP1.0的時候我們很少強調總架構師的功能，微服務化引入之后我們在后臺研發上專門設立總架構師的功能，他來維護模塊之間的關系定義及關系服務之間的架構設計。
微服務化達到的效果就是變快，從迭代、變革上大大加速了產品響應速度。以前公有云廠商每次找我們開發頁面時，好幾個晚上都要加班上線，達到微服務化后基本上白天做版本更新，可以做到快速響應跟上線。
5 云管理平臺未來的定位展望
最后說一下云管理平臺未來的展望。我自己總結了幾點：
今日薦號
細說云計算
探討云計算的一切，關注云平臺架構、網絡、存儲與分發。這里有干貨，也有閑聊。
微信ID:
今日薦文
點擊下方圖片即可閱讀
云計算的2016年度點評