企業(yè)級(jí)云應(yīng)用平臺(tái)的實(shí)踐和思考

作者：賈琨 2015-10-15 17:17:33
云計(jì)算 本文作者有豐富的云平臺(tái)研發(fā)經(jīng)驗(yàn)，本文結(jié)合作者經(jīng)驗(yàn)，以親身參與開發(fā)的兩個(gè)系統(tǒng)的功能和設(shè)計(jì)為主講解關(guān)于一些基于云環(huán)境的應(yīng)用構(gòu)建的技術(shù)。

10年積累的成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)、成都外貿(mào)網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有嘉峪關(guān)免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

今天要講的題目是《企業(yè)級(jí)云平臺(tái)的實(shí)踐和思考》， 主要涉及一些基于云環(huán)境的應(yīng)用構(gòu)建的技術(shù)， 講一下我在這方面的一些實(shí)踐經(jīng)歷和一些思考， 主要講兩個(gè)參與開發(fā)的系統(tǒng)的功能和設(shè)計(jì)為主，不會(huì)涉及太多細(xì)節(jié)技術(shù)。 當(dāng)然，我們也可以就一些點(diǎn)具體討論一下。

資源管理和應(yīng)用管理

基于云的應(yīng)用平臺(tái)，我將它分成兩類：

一塊是資源管理技術(shù)， 比如私有云如OpenStack、CloudStack或者公有云技術(shù); 還有就是資源集群管理技術(shù)， 在Docker這個(gè)技術(shù)領(lǐng)域，個(gè)人感覺集群技術(shù)更適用。

另一塊就是應(yīng)用的構(gòu)建和管理技術(shù)， 包括應(yīng)用資源管理，應(yīng)用構(gòu)建、部署、維護(hù)、 監(jiān)控和彈性擴(kuò)展等技術(shù)，以下我會(huì)就這兩塊來分享。

先看集群技術(shù)，大家都知道，云計(jì)算、大數(shù)據(jù)相關(guān)的技術(shù)最早都是從集群管理技術(shù)開始的，”Google的幾篇經(jīng)典論文介紹了當(dāng)前大數(shù)據(jù)技術(shù)格局的相關(guān)基礎(chǔ)技術(shù)，包括GFS、MapReduce、BigTable及Chubby等。另外就是Borg這個(gè)技術(shù)，它是Google內(nèi)部一切服務(wù)的基礎(chǔ)。最近朋友圈大家也不斷轉(zhuǎn)發(fā)最新的Borg的論文， 其實(shí)國內(nèi)外互聯(lián)網(wǎng)公司也有類似的系統(tǒng)，如Twitter中使用的由加州大學(xué)伯克利分校AMPLab開發(fā)的Mesos，國內(nèi)公司如百度的Volunteer Computing平臺(tái)以及騰訊SOSO部門開發(fā)的臺(tái)風(fēng)系統(tǒng)。 Hadoop社區(qū)2.X版本引入的Yarn也是類似思路的產(chǎn)物。這些技術(shù)因?yàn)镈ocker或者Linux上的容器技術(shù)的出現(xiàn)都有了新的變化， 就是我們大家都知道的k8s、Mesos+Marathon、百度Matrix、騰訊Gaia等。

以上技術(shù)都是立足互聯(lián)網(wǎng)應(yīng)用的，企業(yè)級(jí)其實(shí)也有類似的技術(shù)。 分布式領(lǐng)域有一篇著名的論文《Utopia: a Load Sharing Facility for Large, Heterogeneous Distributed Computer Systems 》，這個(gè)算是分布式計(jì)算領(lǐng)域的開山幾篇論文之一，1993年發(fā)表的，包括Google的幾篇著名論文就引用了它，它描述的就是當(dāng)前流行的分布式計(jì)算體系，論文作者就是分布式計(jì)算公司Platform Computing的創(chuàng)始人。

資源管理器：Platform EGO

下來我們要介紹的Platform EGO就是這個(gè)技術(shù)在HPC等分布式企業(yè)領(lǐng)域演進(jìn)10年后的2.0架構(gòu)中的資源管理技術(shù)， 在最近北京、西安的Mesos Meetup都有所介紹， 就是所謂的IBM Platform DCOS技術(shù)，下面是其中一張PPT。

上面的圖中所有綠色都是IBM Platform的產(chǎn)品，其中一個(gè)核心就是它的資源管理器 Resource Manager(EGO/DCOS)。 它是2004~2005年開始設(shè)計(jì)開發(fā)，和上層的任務(wù)負(fù)載調(diào)度系統(tǒng)LSF，Symphony合起來構(gòu)成業(yè)界最早出現(xiàn)的二層調(diào)度系統(tǒng)，至少是針對(duì)企業(yè)市場交付的第一款類似產(chǎn)品。

我2005年在騰訊開始接觸分布式系統(tǒng)設(shè)計(jì)開發(fā)， 2006年加入Platform Computing，我2006~2010年之間四年多一直參與開發(fā)這個(gè)產(chǎn)品和基于它的云管理產(chǎn)品Platform ISF。Platform ISF在2011年被Forrester評(píng)價(jià)為私有云業(yè)界第一， 但是IBM收購Platform后相關(guān)的策略變化導(dǎo)致它從產(chǎn)品序列中退出作為IBM Platform Cluster Manager的一部分保留。

EGO架構(gòu)

下面來看EGO的一個(gè)模塊圖 ：

這是一個(gè)非官方的架構(gòu)圖，是我根據(jù)對(duì)系統(tǒng)的理解和當(dāng)時(shí)的一些規(guī)劃畫的，不代表現(xiàn)在情況。它是一個(gè)典型的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。 我有意將它畫得像一個(gè)人，有手有腳，有大腦主要想表達(dá)其中核心資源管理問題3塊， 一是收集信息，一直執(zhí)行任務(wù)，一是資源分配調(diào)度， 調(diào)度就是大腦，收集信息和執(zhí)行任務(wù)就是手腳。

從上面的圖中能夠看出來，EGO核心Master它是基于插件的架構(gòu)， 包括資源插件、安全插件、調(diào)度插件、部署(provision)插件、 事件插件和執(zhí)行插件。

LIM( Load Information Manager)是一個(gè)用來收集信息的Master-Slave分布式系統(tǒng)，作為默認(rèn)的資源插件使用。 實(shí)際上EGO Master會(huì)保留標(biāo)準(zhǔn)的API，外部系統(tǒng)可以容易地增加新的資源類型， 比如軟件License，網(wǎng)絡(luò)拓?fù)涔芾淼荣Y源信息。 EGO將各種資源被抽象為有類型的Resource Entity和具有一組屬性，用name-type-value 3元組來描述， 這個(gè)概念等價(jià)于DMTF組織定義的CIM(Common Information Modle)并具有同樣的表達(dá)能力，實(shí)踐中也確實(shí)覆蓋了軟件，硬件等各種需求。

PEM(Process Execution Manager)是執(zhí)行系統(tǒng)， 也是一個(gè)主從結(jié)構(gòu)的分布式系統(tǒng)， 默認(rèn)master內(nèi)嵌在EGO Maser中，但后續(xù)設(shè)計(jì)會(huì)將它拆除來通過插件完成， 同時(shí)支持其他各種執(zhí)行系統(tǒng)。 這里EGO會(huì)為每個(gè)外部系統(tǒng)分配一部分資源(抽象單位為slot，可以通過配置定義slot具體對(duì)應(yīng)為多少M(fèi)EM、CPU或者其他資源)， 然后遠(yuǎn)程執(zhí)行一個(gè)任務(wù)。一個(gè)任務(wù)的早期抽象概念叫Container，后來更改為Activity， 我看到的設(shè)計(jì)文檔中關(guān)于這部分提到了容器/分區(qū)等各種Unix類系統(tǒng)上的虛擬化技術(shù)， 不過沒有具體的實(shí)現(xiàn)。在Linux上，后來也出現(xiàn)對(duì)LXC的需求，應(yīng)該也沒有實(shí)現(xiàn)。

調(diào)度插件是資源管理的重要組成部分，EGO支持多個(gè)調(diào)度器， 可以同時(shí)支持進(jìn)程分配，虛擬機(jī)資源分配， 批處理任務(wù)資源調(diào)度等多種資源分配需求。 我在Platform的最后一階段工作還設(shè)計(jì)了開發(fā)調(diào)度策略的DSL語言和默認(rèn)實(shí)現(xiàn)，支持管理員用python語言開發(fā)自定義的調(diào)度策略。

EGO調(diào)度策略

來看一個(gè)經(jīng)典的EGO調(diào)度策略：

從上面的PPT來看， EGO的調(diào)度策略會(huì)考慮應(yīng)用的Topo結(jié)構(gòu)、資源的負(fù)載、資源拓?fù)溥壿?、網(wǎng)絡(luò)速率、包括應(yīng)用的運(yùn)行時(shí)間(比如分時(shí)運(yùn)行、周期性運(yùn)行等各種模型)。另外也考慮了運(yùn)行期中的資源分片問題，提供了資源整理和遷移的功能。

安全插件支持基本的User/Password、Token/Credential、SSL等， 還包括各種商業(yè)的系統(tǒng)如Kerberos、SiteMinder等，當(dāng)然也支持企業(yè)常用的AD、LADP系統(tǒng)，也支持基于RABC的權(quán)限管理。這里要多說一點(diǎn)， 經(jīng)常大家會(huì)聽到3A或者4A這種說法， 就是認(rèn)證Authentication、賬號(hào)Account、授權(quán)Authorization、審計(jì)Audit,中文名稱為統(tǒng)一安全管理平臺(tái)解決方案。 EGO的這部分設(shè)計(jì)就是為了cover企業(yè)在這方面的需求， 當(dāng)時(shí)相關(guān)的功能陸續(xù)做了近1年才基本滿足相關(guān)的需求。EGO原生設(shè)計(jì)就支持多租戶， 很容易切換到當(dāng)前云的環(huán)境和需求。

部署插件是為了滿足各種上層應(yīng)用系統(tǒng)二進(jìn)制軟件分發(fā)的需求，有基于FTP，NFS等各種實(shí)現(xiàn)。事件插件主要是將系統(tǒng)中關(guān)于資源生命周期的各種事件通知出去的， 支持SNMP等協(xié)議。

與Mesos、Yarn、Kubernetes的對(duì)比

比較EGO和Mesos、Yarn和現(xiàn)在的Kubernetes， 我們發(fā)現(xiàn)企業(yè)級(jí)應(yīng)用系統(tǒng)除了核心的功能，管理功能非常重要，基本是3分功能， 7分管理。

細(xì)說一下，為了描述資源使用者， 設(shè)計(jì)了用戶、消費(fèi)者、client/session等概念來描述使用資源的人、組織和應(yīng)用程序。 資源的抽象考慮各種擴(kuò)展，采用業(yè)界標(biāo)準(zhǔn)CIM模型。資源分配過程支持優(yōu)先級(jí)，預(yù)分配，實(shí)時(shí)分配，資源搶占等各種機(jī)制。資源支持運(yùn)行進(jìn)程、VM、容器等各種資源消耗模式， 當(dāng)年我們經(jīng)常講的一句話， “分配資源后拿來什么也不干，也是一種資源使用方式”。 如果大家有興趣，可以去看看《面向模式的軟件架構(gòu)卷3：資源管理模式》， 這本書將資源管理中的問題和解決方案都進(jìn)行了抽象，值得一讀。 綜合來看， 對(duì)于企業(yè)級(jí)的資源管理或者集群技術(shù)， 可管理是個(gè)重要的需求。它要求的管理是細(xì)粒度的，全方位的。 另外它要和企業(yè)已有的IT架構(gòu)和管理整合， 在軟件架構(gòu)靈活性和適應(yīng)性要求較高。

#p#

應(yīng)用管理

剛才講的是資源管理或者集群管理的技術(shù)，再來看看應(yīng)用層面的技術(shù)。先看一下天云SkyForm應(yīng)用管理產(chǎn)品的架構(gòu)圖：

這個(gè)產(chǎn)品設(shè)計(jì)能夠自動(dòng)的按照模板定義自動(dòng)申請(qǐng)資源、部署軟件、配置系統(tǒng)，可以支持OpenStack、CloudStack等開源云平臺(tái)，支持各種常見的 Apache Tomcat、MySQL，還支持Hadoop、HPC系統(tǒng)的自動(dòng)部署和配置， 同時(shí)支持分布式運(yùn)維任務(wù)執(zhí)行管理、軟件倉庫管理等。開發(fā)這個(gè)系統(tǒng)是在2012年，當(dāng)時(shí)社區(qū)還沒有好成型的類似系統(tǒng)，尤其是沒有統(tǒng)一的業(yè)界認(rèn)可的軟件分發(fā)格式。所以我們自己基于RPM等格式定義了一套軟件包格式和描述語言， 另外還設(shè)計(jì)了圖形化應(yīng)用設(shè)計(jì)器，支持拖拽式應(yīng)用設(shè)計(jì)，效果如下 ：

在用戶處實(shí)際使用的效果并不理想， 比如用戶的應(yīng)用不能或很難改造， 更需要應(yīng)用拓?fù)湔故荆?另外我們定義的軟件包格式也很難推行。用戶需要應(yīng)用性能監(jiān)控?cái)?shù)據(jù)， 同時(shí)希望基于性能的AutoScaling能力。 具體實(shí)現(xiàn)AutoScaling的過程中，也有兩種需求： 一種是用戶應(yīng)用自主控制的方式，即通過API來擴(kuò)展系統(tǒng); 一種是采用系統(tǒng)提供的AutoScaling服務(wù)， 通過配置擴(kuò)展策略和原始監(jiān)控策略有系統(tǒng)自動(dòng)實(shí)現(xiàn)。從管理的角度， 應(yīng)用平臺(tái)的建設(shè)和管理者的關(guān)注點(diǎn)在于應(yīng)用的全貌， 比如應(yīng)用的資源使用情況， 應(yīng)用的運(yùn)行數(shù)據(jù)(包括資源利用率， 業(yè)務(wù)處理能力)， 應(yīng)用彈性管理能力， 繼而得到整體系統(tǒng)資源的使用情況以此為系統(tǒng)建設(shè)和再投資決策做出數(shù)據(jù)支撐。

架構(gòu)演進(jìn)

基于以上的用戶需求，我們參考AWS的實(shí)踐將原來的一體化設(shè)計(jì)拆分并擴(kuò)展為部署服務(wù)， cloudwatch服務(wù)和AutoScaling服務(wù)。未來的應(yīng)用基本都有大量數(shù)據(jù)處理的需求，所以需要支持大數(shù)據(jù)技術(shù)，再加上Docker的出現(xiàn)， 整體軟件架構(gòu)演進(jìn)到下面的階段：

架構(gòu)演進(jìn)有以下幾點(diǎn)動(dòng)機(jī)：

• 互聯(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)用管理平臺(tái)需要針對(duì)它做一定設(shè)計(jì)。

在這個(gè)產(chǎn)品開發(fā)過程中的經(jīng)驗(yàn)就是基于服務(wù)的架構(gòu)和服務(wù)內(nèi)部的微服務(wù)架構(gòu)是滿足當(dāng)前云化應(yīng)用的一個(gè)好的實(shí)踐。

綜合以上兩個(gè)產(chǎn)品的經(jīng)驗(yàn)和教訓(xùn)，建議設(shè)計(jì)和開發(fā)人員多研究一下AWS，它的服務(wù)設(shè)計(jì)和定義在企業(yè)領(lǐng)域有很多可借鑒的， 比如它就有專門的IAM服務(wù)來管理人、組織、安全、權(quán)限方面的需求。而且它的設(shè)計(jì)已經(jīng)從局部模塊的插件化的抽象方式上升到了整體架構(gòu)的服務(wù)化抽象， 如何具體應(yīng)用需要大家認(rèn)真揣摩。我的實(shí)踐總結(jié)下來為：功能層級(jí)化、架構(gòu)SOA化、服務(wù)內(nèi)插件化、 配合開發(fā)技術(shù)平臺(tái)化。

Q&A

Q：你認(rèn)為面向資源和面向應(yīng)用架構(gòu)的區(qū)別是?

A：一個(gè)關(guān)注的資源的供給，一個(gè)關(guān)注應(yīng)用的架構(gòu)、實(shí)現(xiàn)第2個(gè)其中會(huì)有一部分資源的申請(qǐng)、管理問題。面向應(yīng)用更關(guān)注業(yè)務(wù)，所以上層的應(yīng)用往往叫做負(fù)載管理系統(tǒng)或任務(wù)管理系統(tǒng)。

Q：大數(shù)據(jù)HDFS是在虛擬機(jī)VM里面還是真實(shí)物理機(jī)里面?

A：建議不要使用虛擬機(jī)，除非能將IOPS搞到類似物理機(jī)的程度，或者就是用來做算法驗(yàn)證，要不對(duì)存儲(chǔ)系統(tǒng)沖擊太大。

Q：目前 作者分享的一般都是基于互聯(lián)網(wǎng)，針對(duì)企業(yè)級(jí)其實(shí)也有類似的技術(shù)，具體有哪些，怎么實(shí)現(xiàn)?

A：我介紹的第一個(gè)產(chǎn)品EGO就是完全面向企業(yè)的， 主要給金融等領(lǐng)域使用，比如花旗銀行，倒閉的雷曼兄弟等 ，現(xiàn)在也在電信等行業(yè)使用，互聯(lián)網(wǎng)行業(yè)基本沒有用戶。

Q：在服務(wù)化的過程中，架構(gòu)如何同時(shí)兼顧老的非服務(wù)化的部件和服務(wù)化的服務(wù)?

A：其實(shí)我們有個(gè)實(shí)踐就是，有的服務(wù)或部件就讓它隨著時(shí)間over吧。 重要的考慮云化，實(shí)在不行考慮蓋個(gè)帽子封裝成服務(wù)，就是經(jīng)典的設(shè)計(jì)模式中的門面，adapter等的在服務(wù)層面的使用，也可以叫做服務(wù)網(wǎng)關(guān)之類的。

Q：你們是如何對(duì)集群資源做到細(xì)粒度的管理的，能說說你們遇到過哪些坑嗎?

A：主要通過設(shè)計(jì)了資源組和各種資源tag來過濾資源，同時(shí)設(shè)計(jì)了一種規(guī)則語言和引擎支持select、order，支持各種數(shù)學(xué)運(yùn)算和與、或非的邏輯關(guān)系來讓用戶定義資源的需求。最大的坑其實(shí)就是資源粒度定義有點(diǎn)問題，一度都出現(xiàn)零點(diǎn)幾個(gè)slot的情況，其實(shí)簡單點(diǎn)就好了，甚至隨機(jī)分配都會(huì)有個(gè)很好的效果，畢竟這個(gè)宇宙也是混沌的，呵呵。當(dāng)然只是個(gè)人的看法，其他人不一定同意。

Q：你們肯定有考慮過硬件資源使用情況負(fù)載的問題，Docker容器上前段時(shí)間倒是出了監(jiān)控寶，可以監(jiān)控容器的各種資源使用情況，但是想問下今天您提到的“應(yīng)用的資源使用情況”，你們是做的實(shí)時(shí)監(jiān)控嗎?這個(gè)是怎么實(shí)現(xiàn)的?

A：原來EGO的調(diào)度策略一直有個(gè)基于負(fù)載的規(guī)則，LIM會(huì)準(zhǔn)實(shí)時(shí)的收集系統(tǒng)的負(fù)載，包括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)控寶我們也看過，類似的都有幾個(gè)，不過這是應(yīng)用開發(fā)團(tuán)隊(duì)需要自己選擇的。

Q：Auto Scaling過程中是需要停止服務(wù)嗎?

A：不需要停止服務(wù)，參考AWS和具體業(yè)務(wù)，我們?cè)O(shè)計(jì)了多個(gè)AutoScaling group，一部分用于系統(tǒng)基本運(yùn)行需要的最少的資源，其他則為動(dòng)態(tài)改變的，也就是說會(huì)保留最少的服務(wù)節(jié)點(diǎn)。

Q：天云的云平臺(tái)如何解決單點(diǎn)問題，除了熱備冷備，實(shí)現(xiàn)了分布式嗎，怎么實(shí)現(xiàn)的，分布式的事務(wù)怎么處理的?

A：天云云平臺(tái)一開始就是Load Balance模式設(shè)計(jì)，類似OpenStack，單點(diǎn)主要就是數(shù)據(jù)庫。DB的問題也是采用常規(guī)的做法，當(dāng)然也可以采用類似etcd、zk的方式，不過規(guī)模大不了。

Q：我覺得云平臺(tái)最吸引人是彈性調(diào)度，能否就彈性調(diào)度如何實(shí)現(xiàn)這個(gè)問題，分享些經(jīng)驗(yàn)給我們?

A：個(gè)人建議，多研究一下AWS的autoScaling服務(wù)，比如QingCloud的調(diào)度服務(wù)其實(shí)也是它的簡化版。它支持定時(shí)、手動(dòng)、規(guī)則驅(qū)動(dòng)等觸發(fā)方式，對(duì)執(zhí)行的動(dòng)作也有很多可配置的方式，比如發(fā)消息、自動(dòng)執(zhí)行動(dòng)作等。

Q：EGO中對(duì)容錯(cuò)機(jī)制是怎么理解的么，能否講下?

A：EGO的容錯(cuò)分了2部分，一部分是系統(tǒng)本身的，主要靠共享存儲(chǔ)來保存核心數(shù)據(jù)，然后每個(gè)模塊做到可以隨意重啟。 應(yīng)用主要靠其中的egosc，它會(huì)監(jiān)視應(yīng)用的模塊，做到按照定義的規(guī)則執(zhí)行重啟等動(dòng)作，應(yīng)用本身的數(shù)據(jù)一致問題，則要應(yīng)用自己處理。

Q：能介紹下Symphony在DCOS中的作用么?

A：Symphony整體是個(gè)SOA的任務(wù)或負(fù)責(zé)管理系統(tǒng)，底層需要一個(gè)資源管理系統(tǒng)，類似Hadoop、Habase與Yarn的關(guān)系。

Q：EGO核心Master它是基于插件的架構(gòu)，支持熱插拔嗎?

A：沒有采用熱插拔。 因?yàn)橄到y(tǒng)的每個(gè)組件都能夠做到重啟不丟數(shù)據(jù)，啟動(dòng)時(shí)會(huì)和相關(guān)模塊同步數(shù)據(jù)并糾正不一致的地方，所以對(duì)系統(tǒng)穩(wěn)定運(yùn)行沒有影響，類似Google的思路，做到每個(gè)點(diǎn)都能很容易的重啟。

Q：能否介紹一個(gè)典型的調(diào)度器實(shí)現(xiàn)策略?如何考慮資源和需求的?

A：簡單來說，就是將所有的資源請(qǐng)求先放到隊(duì)列中，然后針對(duì)請(qǐng)求采用背包算法，或者線性規(guī)劃算法來找一個(gè)次優(yōu)解就行。因?yàn)橐鼘?shí)時(shí)的給出資源分配結(jié)果，所以沒有最優(yōu)解。

Q：云平臺(tái)的容災(zāi)措施是怎么樣，有什么好的方案?

A：容災(zāi)關(guān)鍵還是數(shù)據(jù)，關(guān)鍵在企業(yè)的存儲(chǔ)設(shè)計(jì)，我也沒有太多建議。

Q：Docker網(wǎng)絡(luò)選擇是host還是nat，性能損失分別是多少?

A：Docker網(wǎng)絡(luò)真實(shí)只在自己環(huán)境管理自己SkyForm使用過，其他的都是實(shí)驗(yàn)室環(huán)境，沒有真實(shí)線上環(huán)境測試，沒法給出實(shí)際數(shù)據(jù)，建議去看一下新浪、雪球等公司的建議。 當(dāng)前只是在一些項(xiàng)目中實(shí)驗(yàn)Docker，沒有大規(guī)模去推。

Q：目前我們都提倡服務(wù)抽象、組合化，我們目的是為了向穩(wěn)定、便捷的方向進(jìn)取，那么，我想問是著重管理，還是著重技術(shù)功能方向呢?

A：具體分析，建議按照建設(shè)、實(shí)用、運(yùn)維、優(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ái)等分布式系統(tǒng)研發(fā)，歷任騰訊Qzone、IBM Platform Computing資源管理調(diào)度系統(tǒng)，華為FusionSphere等產(chǎn)品的開發(fā)、架構(gòu)及產(chǎn)品設(shè)計(jì)工作。精通各種IaaS平臺(tái)、資源管理、資源調(diào)度等相關(guān)技術(shù)，2010年開始從事OpenStack研發(fā)、社區(qū)活動(dòng)，當(dāng)前主要關(guān)注Docker及相關(guān)資源管理技術(shù)，如Mesos、Yarn等。

原文鏈接：http://www.dockone.io/article/740

標(biāo)題名稱：企業(yè)級(jí)云應(yīng)用平臺(tái)的實(shí)踐和思考
網(wǎng)站鏈接：http://fisionsoft.com.cn/article/cddoieg.html