企業(yè)級云應(yīng)用平臺的實踐和思考
今天要講的題目是《企業(yè)級云平臺的實踐和思考》， 主要涉及一些基于云環(huán)境的應(yīng)用構(gòu)建的技術(shù)， 講一下我在這方面的一些實踐經(jīng)歷和一些思考， 主要講兩個參與開發(fā)的系統(tǒng)的功能和設(shè)計為主，不會涉及太多細節(jié)技術(shù)。 當(dāng)然，我們也可以就一些點具體討論一下。
資源管理和應(yīng)用管理
基于云的應(yīng)用平臺，我將它分成兩類：
一塊是資源管理技術(shù)， 比如私有云如OpenStack、CloudStack或者公有云技術(shù); 還有就是資源集群管理技術(shù)， 在Docker這個技術(shù)領(lǐng)域，個人感覺集群技術(shù)更適用。
另一塊就是應(yīng)用的構(gòu)建和管理技術(shù)， 包括應(yīng)用資源管理，應(yīng)用構(gòu)建、部署、維護、 監(jiān)控和彈性擴展等技術(shù)，以下我會就這兩塊來分享。
先看集群技術(shù)，大家都知道，云計算、大數(shù)據(jù)相關(guān)的技術(shù)最早都是從集群管理技術(shù)開始的，”Google的幾篇經(jīng)典論文介紹了當(dāng)前大數(shù)據(jù)技術(shù)格局的相關(guān)基礎(chǔ)技術(shù)，包括GFS、MapReduce、BigTable及Chubby等。另外就是Borg這個技術(shù)，它是Google內(nèi)部一切服務(wù)的基礎(chǔ)。最近朋友圈大家也不斷轉(zhuǎn)發(fā)最新的Borg的論文， 其實國內(nèi)外互聯(lián)網(wǎng)公司也有類似的系統(tǒng)，如Twitter中使用的由加州大學(xué)伯克利分校AMPLab開發(fā)的Mesos，國內(nèi)公司如百度的Volunteer Computing平臺以及騰訊SOSO部門開發(fā)的臺風(fēng)系統(tǒng)。 Hadoop社區(qū)2.X版本引入的Yarn也是類似思路的產(chǎn)物。這些技術(shù)因為Docker或者Linux上的容器技術(shù)的出現(xiàn)都有了新的變化， 就是我們大家都知道的k8s、Mesos+Marathon、百度Matrix、騰訊Gaia等。
以上技術(shù)都是立足互聯(lián)網(wǎng)應(yīng)用的，企業(yè)級其實也有類似的技術(shù)。 分布式領(lǐng)域有一篇著名的論文《Utopia: a Load Sharing Facility for Large, Heterogeneous Distributed Computer Systems 》，這個算是分布式計算領(lǐng)域的開山幾篇論文之一，1993年發(fā)表的，包括Google的幾篇著名論文就引用了它，它描述的就是當(dāng)前流行的分布式計算體系，論文作者就是分布式計算公司Platform Computing的創(chuàng)始人。
資源管理器：Platform EGO
下來我們要介紹的Platform EGO就是這個技術(shù)在HPC等分布式企業(yè)領(lǐng)域演進10年后的2.0架構(gòu)中的資源管理技術(shù)， 在最近北京、西安的Mesos Meetup都有所介紹， 就是所謂的IBM Platform DCOS技術(shù)，下面是其中一張PPT。
上面的圖中所有綠色都是IBM Platform的產(chǎn)品，其中一個核心就是它的資源管理器 Resource Manager(EGO/DCOS)。 它是2004~2005年開始設(shè)計開發(fā)，和上層的任務(wù)負載調(diào)度系統(tǒng)LSF，Symphony合起來構(gòu)成業(yè)界最早出現(xiàn)的二層調(diào)度系統(tǒng)，至少是針對企業(yè)市場交付的第一款類似產(chǎn)品。
我2005年在騰訊開始接觸分布式系統(tǒng)設(shè)計開發(fā)， 2006年加入Platform Computing，我2006~2010年之間四年多一直參與開發(fā)這個產(chǎn)品和基于它的云管理產(chǎn)品Platform ISF。Platform ISF在2011年被Forrester評價為私有云業(yè)界第一， 但是IBM收購Platform后相關(guān)的策略變化導(dǎo)致它從產(chǎn)品序列中退出作為IBM Platform Cluster Manager的一部分保留。
EGO架構(gòu)
下面來看EGO的一個模塊圖 ：
這是一個非官方的架構(gòu)圖，是我根據(jù)對系統(tǒng)的理解和當(dāng)時的一些規(guī)劃畫的，不代表現(xiàn)在情況。它是一個典型的SOA架構(gòu)，核心包括的LIM、PEM和Master組成的核心服務(wù)， 上層包括initd Service EGOSC、name Service egosd、crond Service - Cron、web api service- wsg、自服務(wù)門戶、分析服務(wù)等，也支持C、Java、Python API，后來也有Restful API。 我有意將它畫得像一個人，有手有腳，有大腦主要想表達其中核心資源管理問題3塊， 一是收集信息，一直執(zhí)行任務(wù)，一是資源分配調(diào)度， 調(diào)度就是大腦，收集信息和執(zhí)行任務(wù)就是手腳。
從上面的圖中能夠看出來，EGO核心Master它是基于插件的架構(gòu)， 包括資源插件、安全插件、調(diào)度插件、部署(provision)插件、 事件插件和執(zhí)行插件。
LIM( Load Information Manager)是一個用來收集信息的Master-Slave分布式系統(tǒng)，作為默認的資源插件使用。 實際上EGO Master會保留標(biāo)準(zhǔn)的API，外部系統(tǒng)可以容易地增加新的資源類型， 比如軟件License，網(wǎng)絡(luò)拓撲管理等資源信息。 EGO將各種資源被抽象為有類型的Resource Entity和具有一組屬性，用name-type-value 3元組來描述， 這個概念等價于DMTF組織定義的CIM(Common Information Modle)并具有同樣的表達能力，實踐中也確實覆蓋了軟件，硬件等各種需求。
PEM(Process Execution Manager)是執(zhí)行系統(tǒng)， 也是一個主從結(jié)構(gòu)的分布式系統(tǒng)， 默認master內(nèi)嵌在EGO Maser中，但后續(xù)設(shè)計會將它拆除來通過插件完成， 同時支持其他各種執(zhí)行系統(tǒng)。 這里EGO會為每個外部系統(tǒng)分配一部分資源(抽象單位為slot，可以通過配置定義slot具體對應(yīng)為多少MEM、CPU或者其他資源)， 然后遠程執(zhí)行一個任務(wù)。一個任務(wù)的早期抽象概念叫Container，后來更改為Activity， 我看到的設(shè)計文檔中關(guān)于這部分提到了容器/分區(qū)等各種Unix類系統(tǒng)上的虛擬化技術(shù)， 不過沒有具體的實現(xiàn)。在Linux上，后來也出現(xiàn)對LXC的需求，應(yīng)該也沒有實現(xiàn)。
調(diào)度插件是資源管理的重要組成部分，EGO支持多個調(diào)度器， 可以同時支持進程分配，虛擬機資源分配， 批處理任務(wù)資源調(diào)度等多種資源分配需求。 我在Platform的最后一階段工作還設(shè)計了開發(fā)調(diào)度策略的DSL語言和默認實現(xiàn)，支持管理員用python語言開發(fā)自定義的調(diào)度策略。
EGO調(diào)度策略
來看一個經(jīng)典的EGO調(diào)度策略：
從上面的PPT來看， EGO的調(diào)度策略會考慮應(yīng)用的Topo結(jié)構(gòu)、資源的負載、資源拓撲邏輯、網(wǎng)絡(luò)速率、包括應(yīng)用的運行時間(比如分時運行、周期性運行等各種模型)。另外也考慮了運行期中的資源分片問題，提供了資源整理和遷移的功能。
安全插件支持基本的User/Password、Token/Credential、SSL等， 還包括各種商業(yè)的系統(tǒng)如Kerberos、SiteMinder等，當(dāng)然也支持企業(yè)常用的AD、LADP系統(tǒng)，也支持基于RABC的權(quán)限管理。這里要多說一點， 經(jīng)常大家會聽到3A或者4A這種說法， 就是認證Authentication、賬號Account、授權(quán)Authorization、審計Audit,中文名稱為統(tǒng)一安全管理平臺解決方案。 EGO的這部分設(shè)計就是為了cover企業(yè)在這方面的需求， 當(dāng)時相關(guān)的功能陸續(xù)做了近1年才基本滿足相關(guān)的需求。EGO原生設(shè)計就支持多租戶， 很容易切換到當(dāng)前云的環(huán)境和需求。
部署插件是為了滿足各種上層應(yīng)用系統(tǒng)二進制軟件分發(fā)的需求，有基于FTP，NFS等各種實現(xiàn)。事件插件主要是將系統(tǒng)中關(guān)于資源生命周期的各種事件通知出去的， 支持SNMP等協(xié)議。
與Mesos、Yarn、Kubernetes的對比
比較EGO和Mesos、Yarn和現(xiàn)在的Kubernetes， 我們發(fā)現(xiàn)企業(yè)級應(yīng)用系統(tǒng)除了核心的功能，管理功能非常重要，基本是3分功能， 7分管理。
細說一下，為了描述資源使用者， 設(shè)計了用戶、消費者、client/session等概念來描述使用資源的人、組織和應(yīng)用程序。 資源的抽象考慮各種擴展，采用業(yè)界標(biāo)準(zhǔn)CIM模型。資源分配過程支持優(yōu)先級，預(yù)分配，實時分配，資源搶占等各種機制。資源支持運行進程、VM、容器等各種資源消耗模式， 當(dāng)年我們經(jīng)常講的一句話， “分配資源后拿來什么也不干，也是一種資源使用方式”。 如果大家有興趣，可以去看看《面向模式的軟件架構(gòu)卷3：資源管理模式》， 這本書將資源管理中的問題和解決方案都進行了抽象，值得一讀。 綜合來看， 對于企業(yè)級的資源管理或者集群技術(shù)， 可管理是個重要的需求。它要求的管理是細粒度的，全方位的。 另外它要和企業(yè)已有的IT架構(gòu)和管理整合， 在軟件架構(gòu)靈活性和適應(yīng)性要求較高。
#p#
應(yīng)用管理
剛才講的是資源管理或者集群管理的技術(shù)，再來看看應(yīng)用層面的技術(shù)。先看一下天云SkyForm應(yīng)用管理產(chǎn)品的架構(gòu)圖：
這個產(chǎn)品設(shè)計能夠自動的按照模板定義自動申請資源、部署軟件、配置系統(tǒng)，可以支持OpenStack、CloudStack等開源云平臺，支持各種常見的 Apache Tomcat、MySQL，還支持Hadoop、HPC系統(tǒng)的自動部署和配置， 同時支持分布式運維任務(wù)執(zhí)行管理、軟件倉庫管理等。開發(fā)這個系統(tǒng)是在2012年，當(dāng)時社區(qū)還沒有好成型的類似系統(tǒng)，尤其是沒有統(tǒng)一的業(yè)界認可的軟件分發(fā)格式。所以我們自己基于RPM等格式定義了一套軟件包格式和描述語言， 另外還設(shè)計了圖形化應(yīng)用設(shè)計器，支持拖拽式應(yīng)用設(shè)計，效果如下 ：
在用戶處實際使用的效果并不理想， 比如用戶的應(yīng)用不能或很難改造， 更需要應(yīng)用拓撲展示， 另外我們定義的軟件包格式也很難推行。用戶需要應(yīng)用性能監(jiān)控數(shù)據(jù)， 同時希望基于性能的AutoScaling能力。 具體實現(xiàn)AutoScaling的過程中，也有兩種需求： 一種是用戶應(yīng)用自主控制的方式，即通過API來擴展系統(tǒng); 一種是采用系統(tǒng)提供的AutoScaling服務(wù)， 通過配置擴展策略和原始監(jiān)控策略有系統(tǒng)自動實現(xiàn)。從管理的角度， 應(yīng)用平臺的建設(shè)和管理者的關(guān)注點在于應(yīng)用的全貌， 比如應(yīng)用的資源使用情況， 應(yīng)用的運行數(shù)據(jù)(包括資源利用率， 業(yè)務(wù)處理能力)， 應(yīng)用彈性管理能力， 繼而得到整體系統(tǒng)資源的使用情況以此為系統(tǒng)建設(shè)和再投資決策做出數(shù)據(jù)支撐。
架構(gòu)演進
基于以上的用戶需求，我們參考AWS的實踐將原來的一體化設(shè)計拆分并擴展為部署服務(wù)， cloudwatch服務(wù)和AutoScaling服務(wù)。未來的應(yīng)用基本都有大量數(shù)據(jù)處理的需求，所以需要支持大數(shù)據(jù)技術(shù)，再加上Docker的出現(xiàn)， 整體軟件架構(gòu)演進到下面的階段：
架構(gòu)演進有以下幾點動機：
- 互聯(lián)網(wǎng)技術(shù)在企業(yè)逐步推廣，我們看到傳統(tǒng)企業(yè)在不斷學(xué)習(xí)互聯(lián)網(wǎng)的技術(shù)。
- 企業(yè)環(huán)境一般為混搭結(jié)構(gòu)， 需要支持容器， VM和傳統(tǒng)的遺產(chǎn)應(yīng)用。
- 微服務(wù)架構(gòu)正在互聯(lián)網(wǎng)和企業(yè)軟件開發(fā)中大量使用，應(yīng)用管理平臺需要針對它做一定設(shè)計。
在這個產(chǎn)品開發(fā)過程中的經(jīng)驗就是基于服務(wù)的架構(gòu)和服務(wù)內(nèi)部的微服務(wù)架構(gòu)是滿足當(dāng)前云化應(yīng)用的一個好的實踐。
綜合以上兩個產(chǎn)品的經(jīng)驗和教訓(xùn)，建議設(shè)計和開發(fā)人員多研究一下AWS，它的服務(wù)設(shè)計和定義在企業(yè)領(lǐng)域有很多可借鑒的， 比如它就有專門的IAM服務(wù)來管理人、組織、安全、權(quán)限方面的需求。而且它的設(shè)計已經(jīng)從局部模塊的插件化的抽象方式上升到了整體架構(gòu)的服務(wù)化抽象， 如何具體應(yīng)用需要大家認真揣摩。我的實踐總結(jié)下來為：功能層級化、架構(gòu)SOA化、服務(wù)內(nèi)插件化、 配合開發(fā)技術(shù)平臺化。
Q&A
Q：你認為面向資源和面向應(yīng)用架構(gòu)的區(qū)別是?
A：一個關(guān)注的資源的供給，一個關(guān)注應(yīng)用的架構(gòu)、實現(xiàn)第2個其中會有一部分資源的申請、管理問題。面向應(yīng)用更關(guān)注業(yè)務(wù)，所以上層的應(yīng)用往往叫做負載管理系統(tǒng)或任務(wù)管理系統(tǒng)。
Q：大數(shù)據(jù)HDFS是在虛擬機VM里面還是真實物理機里面?
A：建議不要使用虛擬機，除非能將IOPS搞到類似物理機的程度，或者就是用來做算法驗證，要不對存儲系統(tǒng)沖擊太大。
Q：目前 作者分享的一般都是基于互聯(lián)網(wǎng)，針對企業(yè)級其實也有類似的技術(shù)，具體有哪些，怎么實現(xiàn)?
A：我介紹的第一個產(chǎn)品EGO就是完全面向企業(yè)的， 主要給金融等領(lǐng)域使用，比如花旗銀行，倒閉的雷曼兄弟等 ，現(xiàn)在也在電信等行業(yè)使用，互聯(lián)網(wǎng)行業(yè)基本沒有用戶。
Q：在服務(wù)化的過程中，架構(gòu)如何同時兼顧老的非服務(wù)化的部件和服務(wù)化的服務(wù)?
A：其實我們有個實踐就是，有的服務(wù)或部件就讓它隨著時間over吧。 重要的考慮云化，實在不行考慮蓋個帽子封裝成服務(wù)，就是經(jīng)典的設(shè)計模式中的門面，adapter等的在服務(wù)層面的使用，也可以叫做服務(wù)網(wǎng)關(guān)之類的。
Q：你們是如何對集群資源做到細粒度的管理的，能說說你們遇到過哪些坑嗎?
A：主要通過設(shè)計了資源組和各種資源tag來過濾資源，同時設(shè)計了一種規(guī)則語言和引擎支持select、order，支持各種數(shù)學(xué)運算和與、或非的邏輯關(guān)系來讓用戶定義資源的需求。最大的坑其實就是資源粒度定義有點問題，一度都出現(xiàn)零點幾個slot的情況，其實簡單點就好了，甚至隨機分配都會有個很好的效果，畢竟這個宇宙也是混沌的，呵呵。當(dāng)然只是個人的看法，其他人不一定同意。
Q：你們肯定有考慮過硬件資源使用情況負載的問題，Docker容器上前段時間倒是出了監(jiān)控寶，可以監(jiān)控容器的各種資源使用情況，但是想問下今天您提到的“應(yīng)用的資源使用情況”，你們是做的實時監(jiān)控嗎?這個是怎么實現(xiàn)的?
A：原來EGO的調(diào)度策略一直有個基于負載的規(guī)則，LIM會準(zhǔn)實時的收集系統(tǒng)的負載，包括CPU、MEM、DISK等信息然后匯總到master LIM供 EGO master使用。 天云的系統(tǒng)構(gòu)建了一套自己的監(jiān)控體系、也支持zabbix采集信息，還支持名的APM公司newrelic的agent 協(xié)議，另外也開放了API，可以自己定制監(jiān)控采集系統(tǒng)。 監(jiān)控寶我們也看過，類似的都有幾個，不過這是應(yīng)用開發(fā)團隊需要自己選擇的。
Q：Auto Scaling過程中是需要停止服務(wù)嗎?
A：不需要停止服務(wù)，參考AWS和具體業(yè)務(wù)，我們設(shè)計了多個AutoScaling group，一部分用于系統(tǒng)基本運行需要的最少的資源，其他則為動態(tài)改變的，也就是說會保留最少的服務(wù)節(jié)點。
Q：天云的云平臺如何解決單點問題，除了熱備冷備，實現(xiàn)了分布式嗎，怎么實現(xiàn)的，分布式的事務(wù)怎么處理的?
A：天云云平臺一開始就是Load Balance模式設(shè)計，類似OpenStack，單點主要就是數(shù)據(jù)庫。DB的問題也是采用常規(guī)的做法，當(dāng)然也可以采用類似etcd、zk的方式，不過規(guī)模大不了。
Q：我覺得云平臺最吸引人是彈性調(diào)度，能否就彈性調(diào)度如何實現(xiàn)這個問題，分享些經(jīng)驗給我們?
A：個人建議，多研究一下AWS的autoScaling服務(wù)，比如QingCloud的調(diào)度服務(wù)其實也是它的簡化版。它支持定時、手動、規(guī)則驅(qū)動等觸發(fā)方式，對執(zhí)行的動作也有很多可配置的方式，比如發(fā)消息、自動執(zhí)行動作等。
Q：EGO中對容錯機制是怎么理解的么，能否講下?
A：EGO的容錯分了2部分，一部分是系統(tǒng)本身的，主要靠共享存儲來保存核心數(shù)據(jù)，然后每個模塊做到可以隨意重啟。 應(yīng)用主要靠其中的egosc，它會監(jiān)視應(yīng)用的模塊，做到按照定義的規(guī)則執(zhí)行重啟等動作，應(yīng)用本身的數(shù)據(jù)一致問題，則要應(yīng)用自己處理。
Q：能介紹下Symphony在DCOS中的作用么?
A：Symphony整體是個SOA的任務(wù)或負責(zé)管理系統(tǒng)，底層需要一個資源管理系統(tǒng)，類似Hadoop、Habase與Yarn的關(guān)系。
Q：EGO核心Master它是基于插件的架構(gòu)，支持熱插拔嗎?
A：沒有采用熱插拔。 因為系統(tǒng)的每個組件都能夠做到重啟不丟數(shù)據(jù)，啟動時會和相關(guān)模塊同步數(shù)據(jù)并糾正不一致的地方，所以對系統(tǒng)穩(wěn)定運行沒有影響，類似Google的思路，做到每個點都能很容易的重啟。
Q：能否介紹一個典型的調(diào)度器實現(xiàn)策略?如何考慮資源和需求的?
A：簡單來說，就是將所有的資源請求先放到隊列中，然后針對請求采用背包算法，或者線性規(guī)劃算法來找一個次優(yōu)解就行。因為要近實時的給出資源分配結(jié)果，所以沒有最優(yōu)解。
Q：云平臺的容災(zāi)措施是怎么樣，有什么好的方案?
A：容災(zāi)關(guān)鍵還是數(shù)據(jù)，關(guān)鍵在企業(yè)的存儲設(shè)計，我也沒有太多建議。
Q：Docker網(wǎng)絡(luò)選擇是host還是nat，性能損失分別是多少?
A：Docker網(wǎng)絡(luò)真實只在自己環(huán)境管理自己SkyForm使用過，其他的都是實驗室環(huán)境，沒有真實線上環(huán)境測試，沒法給出實際數(shù)據(jù)，建議去看一下新浪、雪球等公司的建議。 當(dāng)前只是在一些項目中實驗Docker，沒有大規(guī)模去推。
Q：目前我們都提倡服務(wù)抽象、組合化，我們目的是為了向穩(wěn)定、便捷的方向進取，那么，我想問是著重管理，還是著重技術(shù)功能方向呢?
A：具體分析，建議按照建設(shè)、實用、運維、優(yōu)化管理的次序來考慮。
=======================================================================================
本文根據(jù)Dockone技術(shù)分享整理而成。分享人賈琨，云基地旗下初創(chuàng)公司北京天云融創(chuàng)軟件技術(shù)有限公司產(chǎn)品研發(fā)總監(jiān)兼架構(gòu)師，2005年開始從事大規(guī)模Web服務(wù)、HPC/網(wǎng)格及云管理平臺等分布式系統(tǒng)研發(fā)，歷任騰訊Qzone、IBM Platform Computing資源管理調(diào)度系統(tǒng)，華為FusionSphere等產(chǎn)品的開發(fā)、架構(gòu)及產(chǎn)品設(shè)計工作。精通各種IaaS平臺、資源管理、資源調(diào)度等相關(guān)技術(shù)，2010年開始從事OpenStack研發(fā)、社區(qū)活動，當(dāng)前主要關(guān)注Docker及相關(guān)資源管理技術(shù)，如Mesos、Yarn等。
