云管理平臺的定義是Gartner提出來的，總結(jié)起來就是兩塊，第一是管理，管理公有云、私有云，形成混合云。第二是自服務(wù)，鏡像劃分，計量與計費，負(fù)載優(yōu)化。云管理平臺最終的目標(biāo)是應(yīng)用在云平臺上運行時取得最優(yōu)化的效果。大家熟悉的公有云有上云服務(wù)，能最大限度的保證應(yīng)用的可靠性，我們自己設(shè)計一個云管理平臺時也要考慮這方面，還附加了一些外部系統(tǒng)的對接與管理功能。
說到云計算，大家會想到OpenStack，OpenStack跟云管理平臺有什么區(qū)別，是不是可以基于OpenStack做一些云管理平臺？目前從我們自己的定義以及市場上的反饋來看，我們認(rèn)為云管理平臺是更廣的范圍。我們可以把OpenStack看作是云管理平臺下屬的資源模塊，云管理平臺可以管理多個OpenStack版本。
有些企業(yè)會在不同的數(shù)據(jù)中心里部署不同的OpenStack資源池管理模塊，在OpenStack之上也需要一個云管理平臺來管理多個OpenStack資源池以及管理不同的OpenStack版本，另外還有很多虛擬化不是由OpenStack+KVM實現(xiàn)的，比如Vmware、Xen等虛擬化，所以云管理平臺還要針對這種虛擬化做對接。從層次上來看，云管理平臺是解決用戶最后的資源使用一公里的問題，最終提供給用戶服務(wù)的是云管理平臺的自服務(wù)平臺。
我們實現(xiàn)的云管理平臺主要分三大功能：
異構(gòu)的虛擬化管理。OpenStack天生對接KVM平臺，在Xen、hyper-v、VMware對接上是相對劣勢的一點， 我們實現(xiàn)的是同等能力的管理。
多個OpenStack版本、多個資源池管理還有多數(shù)據(jù)中心擴(kuò)展。
調(diào)度、計量計費、外部系統(tǒng)集成。
云管理平臺主要有資源管理、運營、自服務(wù)三個功能，資源提供方比如存儲、計算、網(wǎng)絡(luò)。資源池最終交付給用戶的是一個一個服務(wù)，比如計算服務(wù)、存儲服務(wù)、網(wǎng)絡(luò)服務(wù)等IaaS層面的，中間件服務(wù)、數(shù)據(jù)服務(wù)等PaaS層面的。怎么交付給用戶的？是云管理平臺將資源管理起來，通過運營，在公有云上這種運營可以是計量計費，之后通過自服務(wù)界面把應(yīng)用提供給用戶使用。
這是云管理整體的定位，它是承上啟下的。對下管理資源、對上提供應(yīng)用使用的界面和API。如果創(chuàng)業(yè)公司自己設(shè)計一個云管理平臺的話，五個模塊必不可少，一是資源管理，二是運營管理，三是服務(wù)提供管理（使用界面與API），還有運維管理與安全管理。
這是我們設(shè)計CMP1.0時第一版的架構(gòu)，拆分一下有資源管理系統(tǒng)、運營管理系統(tǒng)。資源管理系統(tǒng)負(fù)責(zé)物理機(jī)管理、存儲管理、網(wǎng)絡(luò)管理、多數(shù)據(jù)中心管理。架構(gòu)圖右上角的模塊是一個專門的虛擬化管理系統(tǒng)，它也可以看做是一個資源管理模塊。
為什么把虛擬化管理系統(tǒng)拆分出來？因為虛擬化管理系統(tǒng)是云管理平臺一個比較核心的模塊，需要對它做更精細(xì)的設(shè)計，所以單獨拆分出來。 運營管理系統(tǒng)最終的目標(biāo)就是將資源管理系統(tǒng)、虛擬化管理系統(tǒng)管理出來的資源運營成為一種服務(wù)，比如服務(wù)目錄就是將資源發(fā)布成云計算產(chǎn)品，工單管理、流程管理、計量計費負(fù)責(zé)用戶申請一個虛擬機(jī)或一塊存儲空間，怎么做計量計費，怎么發(fā)布出去。
再往上是用戶使用的自服務(wù)，運營門戶、管理員門戶，當(dāng)然也要開放統(tǒng)一API，因為有些應(yīng)用使用的不是自服務(wù)界面，而是使用API調(diào)用虛擬化、存儲、網(wǎng)絡(luò)。要做好一個系統(tǒng)，運維管理，比如監(jiān)控還有日志分析等等，是必不可少的。在云管理平臺之外我們單獨設(shè)計一個運維管理系統(tǒng)，通過Zabbix等采集模塊采集系統(tǒng)運行狀態(tài)，實時呈現(xiàn)給云管理平臺的管理員，這是CMP總體架構(gòu)設(shè)計的1.0版本。
首先看資源管理系統(tǒng)。 虛擬化管理系統(tǒng)可以看作是資源管理系統(tǒng)的子模塊。目前市場上常用的虛擬化大的用戶里最多的是VMware。我們統(tǒng)計過電信運營商、銀行等等，VMware占有量大概在80%以上。第二個是中小企業(yè)，用微軟hyper-v的比較多，還有citrix、kvm、蘇研虛擬化。
我們在做虛擬化管理系統(tǒng)時是做虛擬化適配層，針對每一個虛擬化平臺做一個driver，這個driver可以下發(fā)指令、并反饋狀態(tài)，同時開放API針對管理層使用。比如虛擬機(jī)的基礎(chǔ)管理，像開機(jī)關(guān)機(jī)都可以通過driver做。在基于KVM去做的時候引用了OpenStack虛擬化管理的nova模塊，主要目的是有了nova我們也沒有必要完全重寫針對KVM虛擬化管理的功能。
我們在設(shè)計私有云的時候，用戶對應(yīng)用支撐這塊有很高的要求，比如數(shù)據(jù)庫服務(wù)，他會明確要求放在物理機(jī)上。 所以資源管理模塊需要做物理機(jī)管理，目前是基于IPMI實現(xiàn)的，可以做物理機(jī)的分配、自動安裝、自動服務(wù)提供。跟虛擬化的區(qū)別就是物理機(jī)的分配單位是一臺一臺的物理機(jī)，虛擬化的分配單位可以在物理機(jī)上做更小的切分。
還有存儲模塊。目前說云計算的時候大家一提存儲往往是提分布式存儲或者云存儲，類似對象存儲的實現(xiàn)。如果在傳統(tǒng)企業(yè)做存儲管理并將存儲形成存儲服務(wù)的話，還有一塊就是傳統(tǒng)存儲，也叫SAN存儲，包括FC存儲和iSCSI存儲。這種存儲管理的實現(xiàn)我們是通過標(biāo)準(zhǔn)的SMIS協(xié)議，如果沒有這個協(xié)議就要對接cmd line/shell腳本實現(xiàn)。
資源管理的網(wǎng)絡(luò)管理。云計算里面經(jīng)常介紹SDN的管理，除此之外還有路由、交換機(jī)、防火墻，這塊的管理需要在上面自動劃分網(wǎng)絡(luò)服務(wù)，劃分一個VPC或者子網(wǎng)，需要通過網(wǎng)絡(luò)管理模塊API做對接和呈現(xiàn)。
最后是多數(shù)據(jù)中心管理。比如要幫一個公有云的客戶實現(xiàn)一個云管理平臺，這個公有云可能會在全國部署多個數(shù)據(jù)中心。涉及到一個云管理平臺對多個數(shù)據(jù)中心的管理，這是一種分布式架構(gòu)的實現(xiàn)。比如說在數(shù)據(jù)中心里把OpenStack或者vCenter作為一個資源池模塊，最終是一個云管理平臺去管理多個數(shù)據(jù)中心，并做整體平臺的運營和服務(wù)。
剛才簡單的給大家總結(jié)了資源管理這一部分，包括計算資源、存儲資源、網(wǎng)絡(luò)資源的統(tǒng)一管理。
管理完之后是運營的過程。運營包括將管理完的資源發(fā)布成服務(wù)，需要一種服務(wù)模板的規(guī)劃設(shè)計。服務(wù)模板包括把一個虛擬機(jī)定義成一個服務(wù)，包括虛擬機(jī)的定義、發(fā)布、審核以及在界面上的呈現(xiàn)。在服務(wù)目錄之后，我們有了服務(wù)的概念，還要做計量計費，用戶使用資源時要做統(tǒng)計，公有云上可以收費用，私有云可以做跨部門之間的資源使用統(tǒng)計，這是訂單管理和用戶管理、資源使用計量計費三塊合一，也就是要確定一個用戶或者一個部門使用的資源時間時長以及最終的計量計費的過程。最后是運營門戶，運營管理員可以運營這些服務(wù)。比如公有云廠商定期有新的云服務(wù)發(fā)布，基本是在運營管理層面上做的。
我們做了一個總結(jié)， 應(yīng)用在使用時主要可以分為兩種類型：實時交易類型和在線批處理。這兩種應(yīng)用遷移到云平臺的時候都有自己的特定要求。
首先看傳統(tǒng)的交易系統(tǒng)，比如電商系統(tǒng)或者是CRM人力資源管理系統(tǒng)，它分三層：Web、App、DB。以前中大型的企業(yè)，比如銀行或者運營商都是放在小型機(jī)上承載的，Web用X86服務(wù)器，App可能用weblogic、websphere放在小型機(jī)上運行，還有DB用Oracle或者DB2的數(shù)據(jù)庫，都放在小型機(jī)上。
阿里一直在提的去IOE，實際上是一種分布式架構(gòu)改造，改造之后傳統(tǒng)的Oracle數(shù)據(jù)庫、DB2數(shù)據(jù)庫，逐步去做分布式數(shù)據(jù)庫或者是關(guān)聯(lián)不復(fù)雜的數(shù)據(jù)逐步往非結(jié)構(gòu)化數(shù)據(jù)、內(nèi)存數(shù)據(jù)庫做遷移，還有NoSQL數(shù)據(jù)庫，實際上數(shù)據(jù)庫是在逐步做新技術(shù)的引入，實現(xiàn)模塊化分布式改造。
如果我們把原先單一的數(shù)據(jù)庫改造成分布式數(shù)據(jù)庫，需要分布式數(shù)據(jù)庫的數(shù)據(jù)路由和集中訪問。到應(yīng)用這層，以前我們說weblogic、websphere，現(xiàn)在就改成微服務(wù)，比如一個一個的應(yīng)用，每個應(yīng)用單一化改造成單一的服務(wù)。有了微服務(wù)之后，在微服務(wù)上層還需要微服務(wù)的治理，比如服務(wù)編排、服務(wù)訪問路由。再上層就是用戶交互層。
傳統(tǒng)的應(yīng)用在改造成云化架構(gòu)時帶來了很多需求：
第一個關(guān)鍵點是Web接入，比如從單機(jī)變成負(fù)載均衡+后端多節(jié)點。從客戶流量變化上大家都知道有彈性伸縮，節(jié)點數(shù)量隨著流量變化而變化。
第二是X86集群部署，小型機(jī)的年代是單機(jī)或者是HA的部署，到了云化的時候，從Web到App到數(shù)據(jù)層，都是x86集群化部署，所以要有集群管理功能。
第三是數(shù)據(jù)分布式部署，原先的單一數(shù)據(jù)庫在存儲幾億條數(shù)據(jù)之后，查詢交易上延遲性和響應(yīng)上比較大，所以會考慮數(shù)據(jù)庫的拆分，比如數(shù)據(jù)庫表的垂直拆分或者水平拆分。拆分之后會帶來新的問題，比如數(shù)據(jù)對外的統(tǒng)一訪問，原先是一個表如果拆成多個表，每個表跨庫join、跨表join都是新的問題，所以在云平臺上要構(gòu)建數(shù)據(jù)路由層或者統(tǒng)一數(shù)據(jù)訪問引擎。開源的有Hibernate、Shards、Ibatis-Sharding，但是開源的訪問引擎如果集成到云平臺上，云平臺對他們的監(jiān)控、調(diào)用邏輯的呈現(xiàn)是必要的需求。
第四是數(shù)據(jù)平臺化。以前App跟數(shù)據(jù)庫邏輯一般是綁死的，比如在數(shù)據(jù)庫里寫一些存儲過程，這種存儲過程往往跟中間件層有很強(qiáng)的邏輯關(guān)聯(lián)性。微服務(wù)化之后，需要后臺單一的每個不同的數(shù)據(jù)庫存儲，需要有集中的存儲平臺的概念，最終要做存儲分析、訂單的歷史趨勢呈現(xiàn)，都需要數(shù)據(jù)平臺來做。
還有一塊是聯(lián)機(jī)分析處理。以前做數(shù)據(jù)倉庫就是大的Oracle數(shù)據(jù)倉庫，Hadoop技術(shù)出現(xiàn)之后大家就想用Hadoop做Oracle的數(shù)據(jù)倉庫功能。最開始的架構(gòu)就是在原先的Oracle DW之外，逐步引入Hadoop技術(shù)，如果要做關(guān)聯(lián)復(fù)雜的歷史數(shù)據(jù)分析，比如銀行的復(fù)雜的用戶數(shù)據(jù)畫像需要MPP數(shù)據(jù)庫，如果不復(fù)雜也可以用Hadoop做。最開始的聯(lián)機(jī)處理分析引入的是Hadoop并列割裂式的架構(gòu)。如果需要在Hadoop分析，可以把數(shù)據(jù)倉庫上的數(shù)據(jù)導(dǎo)到Hadoop上進(jìn)行分析。這種方式有一個問題，相互獨立的信息系統(tǒng)缺乏數(shù)據(jù)交互性，演進(jìn)路線受限。后來大家提企業(yè)級數(shù)據(jù)平臺，是從ETL層到數(shù)據(jù)匯總，統(tǒng)一做拉開。
總結(jié)一下交易系統(tǒng)跟批處理系統(tǒng)在上云過程中對云管理平臺的新的需求。第一是彈性計算，Web節(jié)點實時彈性伸縮。第二是App中間件層逐漸引入微服務(wù)，微服務(wù)架構(gòu)有很多，設(shè)計出的微服務(wù)也很多，需要對微服務(wù)做統(tǒng)一管控。第三是越來越多的模塊，需要對產(chǎn)生的數(shù)據(jù)監(jiān)控做更多分析。比如一個用戶三年前上云，現(xiàn)在數(shù)據(jù)中心積累了海量的監(jiān)控數(shù)據(jù)，監(jiān)控數(shù)據(jù)對他也是很有用的，可以做歷史趨勢的分析。第四是需要支持大數(shù)據(jù)類、開源數(shù)據(jù)庫類的開源組件對接與管理。
我們做了幾點，第一是虛擬機(jī)編排跟彈性伸縮。大家知道Docker有自帶的彈性伸縮，在虛擬機(jī)這一層也需要彈性伸縮。第二是資源管理系統(tǒng)引入了微服務(wù)管理。第三是開源組件的支持，引入了Docker+Kubernetes，把hadoop和spark的一些內(nèi)容往彈性計算體系遷移，這樣云管理平臺新的針對應(yīng)用的設(shè)計演進(jìn)了一步。這是2013年1.3版本的設(shè)計，到2014、2015年3.1版本的設(shè)計，逐步引入彈性子計算系統(tǒng)。
云管理平臺最開始1.0的設(shè)計只是對資源的管理，到了2.0、3.0的設(shè)計時，我們逐步發(fā)現(xiàn)上云的過程中，應(yīng)用會對云管理平臺提出新的需求，如何調(diào)整、如何增加新的技術(shù)實現(xiàn)對應(yīng)用的支撐。接下來看一下容器跟微服務(wù)引入之后對云管理平臺本身設(shè)計架構(gòu)的改變。
兩張圖的對比。左邊是1.0的架構(gòu)，它的部署架構(gòu)包括自服務(wù)門戶、門戶后臺、用戶服務(wù)、運營服務(wù)、運維管理。運營服務(wù)里面有訂單管理、計費管理、AZ配置。所有業(yè)務(wù)都是耦合的，如果要升級一個功能整個服務(wù)都要升級。這是一個不利點，而且開發(fā)測試團(tuán)隊也不明晰，升級任何功能點都要對模塊進(jìn)行重構(gòu)。所以我們在微服務(wù)上考慮引入這樣一個架構(gòu)，運營服務(wù)、產(chǎn)品支撐和運維管理里面每一個功能點都單獨做成一個微服務(wù)。
微服務(wù)的系統(tǒng)架構(gòu)主要是兩個分離： 第一是客戶交互與業(yè)務(wù)邏輯分離。前臺的JS與后臺java分離。 第二就是微服務(wù)化，把這些服務(wù)都通過服務(wù)管理、服務(wù)注冊、服務(wù)發(fā)現(xiàn)管理起來，前臺對服務(wù)的使用都通過微服務(wù)管理平臺發(fā)現(xiàn)相應(yīng)的服務(wù)，導(dǎo)流到各個服務(wù)節(jié)點上。云管理平臺最終提供很多產(chǎn)品，像云主機(jī)產(chǎn)品、塊存儲產(chǎn)品等等，我們會把這些產(chǎn)品做成一個一個的服務(wù)，通過微服務(wù)化可以實現(xiàn)數(shù)據(jù)中心里每個服務(wù)的自治，不同服務(wù)的升級可以完全基于自己去做，只需要保證對外API是統(tǒng)一的。
再一個就是分布式，我們做了無狀態(tài)化可以做更好的云管理平臺本身的彈性。比如一個大的運營商是集團(tuán)級的，用戶量有上千萬，每次促銷時云管理平臺自身的壓力也是一個比較大的點。每次促銷都是先備很多虛擬機(jī)上去，現(xiàn)在微服務(wù)化之后通過無狀態(tài)化可以實施自動的擴(kuò)展。
微服務(wù)化之后每一個管理平臺最終的狀態(tài)是什么樣的？第一是運營管理門戶，每個門戶有訂單查詢、產(chǎn)品目錄、工單等等呈現(xiàn)。在門戶選擇一個服務(wù)就會通過REST API的形式到運營管理API上，每一個API都是一個單獨的服務(wù)。點了一個服務(wù)之后，這個服務(wù)的邏輯實現(xiàn)是在后臺，通過微服務(wù)管理平臺上找相應(yīng)的已經(jīng)注冊的服務(wù)，然后服務(wù)將最終的邏輯實現(xiàn)。
資源管理平臺也是同樣的概念，比如說資產(chǎn)管理、故障告警等功能最終會落在一個個服務(wù)的API上，再通過服務(wù)發(fā)現(xiàn)、服務(wù)管理功能導(dǎo)流在后臺服務(wù)做統(tǒng)一處理。
微服務(wù)化之后有一個比較重要的就是對服務(wù)能力的監(jiān)控。目前我們是兩種方式，一種方式是用ceilometer實時采集呈現(xiàn)，還有一種是實時呈現(xiàn)完之后歷史數(shù)據(jù)的存儲，目前是用Spark集群做。需要對每個Hypervisor做實時呈現(xiàn)跟監(jiān)控，這是做平臺必不可少的模塊。
再就是日志，比如說調(diào)用的日志，從用戶申請一個虛擬機(jī)的服務(wù)到每個服務(wù)之間的調(diào)用是7步左右，這7步任何一步出現(xiàn)了問題都要做產(chǎn)品回退，因為這會影響最終使用，所以需要對每一步的調(diào)用日志進(jìn)行監(jiān)控和采集，以確?？梢耘挪槟囊徊匠隽藛栴}。日志我們采用了開源的Elastic Search，做了一些封裝和改造。最終在日志管理的界面上呈現(xiàn)。
最后就是微服務(wù)化之后系統(tǒng)模塊之間的關(guān)系圖。以前就Web、App、DB三個服務(wù)，微服務(wù)化之后變成30幾個服務(wù)，每個服務(wù)之間也有調(diào)用關(guān)系，這種關(guān)系圖是維護(hù)系統(tǒng)運行的最重要的模塊。CMP1.0的時候我們很少強(qiáng)調(diào)總架構(gòu)師的功能，微服務(wù)化引入之后我們在后臺研發(fā)上專門設(shè)立總架構(gòu)師的功能，他來維護(hù)模塊之間的關(guān)系定義及關(guān)系服務(wù)之間的架構(gòu)設(shè)計。
微服務(wù)化達(dá)到的效果就是變快，從迭代、變革上大大加速了產(chǎn)品響應(yīng)速度。以前公有云廠商每次找我們開發(fā)頁面時，好幾個晚上都要加班上線，達(dá)到微服務(wù)化后基本上白天做版本更新，可以做到快速響應(yīng)跟上線。
最后說一下云管理平臺未來的展望。我自己總結(jié)了幾點：
精細(xì)化管理，管理能力更強(qiáng)、更精。SDN、SDS等的管理，打通編排的所有環(huán)節(jié)。
計費方向的細(xì)化。我們需要去做基礎(chǔ)設(shè)施更精細(xì)的計費，以前按天按月，現(xiàn)在按時按分。
云+應(yīng)用的一體化管控。從用戶系統(tǒng)的接入到對云服務(wù)組件的調(diào)用，全流程的監(jiān)控分析體系。
混合云管理。公有云是不可阻擋的趨勢，私有云和公有云的混合管理也是一個方向。
行業(yè)云和社區(qū)云的建設(shè)與支撐。如果你抓住一種特定的行業(yè)或者特定的應(yīng)用場景，比如說渲染云、高性能計算云等，它的盈利點還是比較多的。
大規(guī)模節(jié)點管理時，考慮結(jié)合AI，針對資源池的運行數(shù)據(jù)進(jìn)行分析與運營，形成運維知識的深度學(xué)習(xí)。
探討云計算的一切，關(guān)注云平臺架構(gòu)、網(wǎng)絡(luò)、存儲與分發(fā)。這里有干貨，也有閑聊。
微信ID:CloudNote
點擊下方圖片即可閱讀
云計算的2016年度點評
