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