摘要：月日數(shù)人云在上海舉辦金融沙龍，邀請(qǐng)上交所和近二十家來(lái)自銀行保險(xiǎn)證券的技術(shù)專家一同探討容器技術(shù)在金融業(yè)中的最佳實(shí)踐。數(shù)人云肖德時(shí)在會(huì)上將傳統(tǒng)金融行業(yè)通過(guò)容器可以解決的四大問(wèn)題做了逐一解讀。如何動(dòng)態(tài)的分配，就是剛才上交所介紹的一些治理的方法。

7月29日數(shù)人云在上海舉辦金融沙龍，邀請(qǐng)上交所和近二十家來(lái)自銀行、保險(xiǎn)、證券的IT技術(shù)專家一同探討容器技術(shù)在金融業(yè)中的最佳實(shí)踐。數(shù)人云CTO肖德時(shí)在會(huì)上將傳統(tǒng)金融行業(yè)通過(guò)容器可以解決的四大問(wèn)題做了逐一解讀。

以下是演講實(shí)錄：

容器技術(shù)基本上是2013年出來(lái)的，2014年開(kāi)始在中國(guó)傳播。在2016年，大家可以感覺(jué)到Docker技術(shù)的發(fā)展加速，在生產(chǎn)環(huán)境中也有很多的成功案例。在DockerCon 2016上我們發(fā)現(xiàn)，Docker已經(jīng)從原來(lái)的一個(gè)工具變成一個(gè)真正的生態(tài)圈，Docker已經(jīng)具備整套的解決方案，同時(shí)上下游生態(tài)也已經(jīng)非常完備。這都在告訴大家，你能想到的、和你需要的一些最佳實(shí)踐，Docker基本上都能提供。目前，基本上是大公司在不斷的追求Docker的技術(shù)，因?yàn)樾」居肈ocker技術(shù)解決問(wèn)題產(chǎn)生的收益比還比較不明顯，而大公司原來(lái)冗余的架構(gòu)通過(guò)使用Docker確實(shí)可以產(chǎn)生效益，所以一些傳統(tǒng)企業(yè)對(duì)Docker會(huì)比較關(guān)注。

最新的資料顯示，現(xiàn)在是應(yīng)用Docker技術(shù)的比較好的時(shí)機(jī)。全球雇員超過(guò)500人的公司中73%已使用Docker技術(shù)。國(guó)內(nèi)的很多公司也都在關(guān)注這項(xiàng)技術(shù)，尤其是金融行業(yè)，因?yàn)榻鹑跇I(yè)的IT發(fā)展的比較成熟，他們對(duì)新技術(shù)比較關(guān)注，Docker已經(jīng)有很多生產(chǎn)應(yīng)用在里面產(chǎn)生。

用Docker能干什么是大家比較關(guān)心的問(wèn)題。第一個(gè)比較常見(jiàn)的場(chǎng)景是DevOps，DevOps實(shí)際上就是提高生產(chǎn)力。原來(lái)，開(kāi)發(fā)能做運(yùn)維的事，運(yùn)維能做開(kāi)發(fā)的事。但實(shí)際上從真實(shí)的場(chǎng)景里，術(shù)業(yè)有專攻，在創(chuàng)業(yè)公司可以這么干，但傳統(tǒng)公司做不了。Docker可以幫助企業(yè)進(jìn)行業(yè)務(wù)的轉(zhuǎn)型，提供標(biāo)準(zhǔn)的接口，這樣開(kāi)發(fā)提供標(biāo)準(zhǔn)運(yùn)維能知道，運(yùn)維提供標(biāo)準(zhǔn)開(kāi)發(fā)也能知道。傳統(tǒng)企業(yè)的開(kāi)發(fā)流程不像創(chuàng)業(yè)公司，一個(gè)人要干很多事，傳統(tǒng)企業(yè)強(qiáng)調(diào)的是標(biāo)準(zhǔn)化，是業(yè)務(wù)的轉(zhuǎn)型，而在原有的老的制度下很難實(shí)現(xiàn)這種標(biāo)準(zhǔn)，用Docker技術(shù)可以加快轉(zhuǎn)型。

第二個(gè)場(chǎng)景，云化。2016年云計(jì)算開(kāi)始了新的增長(zhǎng)，云計(jì)算發(fā)展到了新的技術(shù)點(diǎn)，老的虛擬化技術(shù)已經(jīng)不能滿足企業(yè)對(duì)動(dòng)態(tài)資源和快速響應(yīng)的需求，不能起到資源復(fù)用的作用。Docker可以應(yīng)用在物理機(jī)上，也可以應(yīng)用在虛擬機(jī)上，可以快速構(gòu)建應(yīng)用管理平臺(tái)，或者構(gòu)建IaaS、PaaS，或者service都可以。原來(lái)部門做不了，因?yàn)闆](méi)有技術(shù)棧的改變，仍然要用老設(shè)施，那些老設(shè)施都是為大企業(yè)設(shè)計(jì)的。但是Docker出來(lái)的時(shí)候就是為開(kāi)發(fā)者服務(wù)的，它是一個(gè)工具，一個(gè)人也可以做一個(gè)私有云。從這個(gè)點(diǎn)來(lái)看，在云端的轉(zhuǎn)變這個(gè)場(chǎng)景里Docker是目前比較推薦的技術(shù)棧，它能夠快速構(gòu)建應(yīng)用管理平臺(tái)，可以有很好的基礎(chǔ)。

另外，用了Docker一定要無(wú)狀態(tài)，這只是表象，以前的應(yīng)用架構(gòu)和原來(lái)的狀態(tài)是不是就一定不能滿足現(xiàn)在的需求？不是的，原來(lái)的單體仍然可以用，為什么要做微服務(wù)？因?yàn)闃I(yè)務(wù)里有多個(gè)Function，其中有一個(gè)Function是特別熱的，這時(shí)候怎么能抽出來(lái)？最簡(jiǎn)單的辦法就是重構(gòu)，因?yàn)橄氚阉槌鰜?lái)，抽出來(lái)以后，如果沒(méi)有一些工具怎么做后面的工作？這都是限制問(wèn)題。Docker公司提供的方案就是用Docker把它包裹一下，成為一個(gè)標(biāo)準(zhǔn)的小組件，然后利用分布式的概念，把它scale out，scale out以后再進(jìn)行后面的工作。在現(xiàn)代的應(yīng)用中，用了云，資源更容易獲得，所以客戶想快速地創(chuàng)造一些環(huán)境，這些環(huán)境里面的資源利用率解決了，但是應(yīng)用的復(fù)雜度仍然存在。如何動(dòng)態(tài)的分配，就是剛才上交所介紹的一些治理的方法。在Modern APP之上會(huì)面臨一些問(wèn)題，但是如何快速響應(yīng)，這個(gè)情況是需要一些工具的，這些工具我們認(rèn)為Docker是可以做到。

大背景，之前IOE的架構(gòu)存在，不是說(shuō)不好，從技術(shù)層面來(lái)講，我并不認(rèn)為IOE有什么不好，只是我加了一些策略做這件事，它比較擁堵，但不代表它不好。還有“十三五”規(guī)劃，自主可控的要求，這些背景讓企業(yè)對(duì)開(kāi)源工具的需求變得會(huì)越來(lái)越多，數(shù)人云這種開(kāi)源公司也是應(yīng)勢(shì)而生，我們給企業(yè)提供的解決方案就是自主可控，把開(kāi)源、透明的技術(shù)交給客戶。

在2015年，當(dāng)時(shí)去跟客戶說(shuō)我們上一個(gè)Docker，人家說(shuō)你的Docker和VM比有什么好處？VM用的多好，為什么要上Docker？當(dāng)時(shí)我們是無(wú)言以對(duì)的，因?yàn)榘踩?，還有各種生態(tài)圈的工具鏈也不成熟。但是慢慢的，我們?cè)谧鲞@件事的時(shí)候發(fā)現(xiàn)，其實(shí)這是需要和企業(yè)一起成長(zhǎng)，我們也總結(jié)一些步驟。

總結(jié)一下我們想解決的問(wèn)題，首先，Docker能不能解決快速發(fā)布的問(wèn)題，實(shí)際上用Docker以后，管理起來(lái)是更復(fù)雜的。所以才會(huì)有數(shù)人云這種PaaS的存在，把復(fù)雜的東西用計(jì)算機(jī)的方式管理，因?yàn)橛脗€(gè)人的方式是沒(méi)法管理那么多資源的和實(shí)例的；二是原來(lái)多套環(huán)境相互隔離，客戶需要的是多套環(huán)境多租戶的分發(fā)，真正的隔離，因?yàn)槭莾?nèi)部系統(tǒng)，對(duì)于隔離的要求還是可以分級(jí)的。環(huán)境的快速搭建涉及編排，怎么把DB分成兩個(gè)，上面分成多個(gè)，然后都能訪問(wèn)DB，還有如何將手工操作變成自動(dòng)的；三是大版本升級(jí)回滾，很難做這種升級(jí)回滾，怎么去做；四是各種設(shè)備，有的CPU，有的是VM，有的在物理機(jī)上，這么多設(shè)備怎么統(tǒng)一的管理起來(lái)。這是我們現(xiàn)實(shí)的一些場(chǎng)景，我們?cè)趺唇鉀Q這些問(wèn)題是我今天想和大家一起探討的問(wèn)題。

第一個(gè)問(wèn)題是快速部署，還有緩慢的升級(jí)，基本上就是用容器和微服務(wù)解。微服務(wù)是一個(gè)框架，如果把現(xiàn)有的服務(wù)拆成微服務(wù)，一定是一個(gè)統(tǒng)一的架構(gòu)，那這個(gè)架構(gòu)里面一定是包含這樣的元素：首先，一定要有一個(gè)API網(wǎng)關(guān)的Server，微服務(wù)里面的API網(wǎng)關(guān)不涉及Nginx，因?yàn)镹ginx沒(méi)法動(dòng)態(tài)的改配置，得手動(dòng)去改，這是滿足不了需求的，因?yàn)榈紫碌膽?yīng)用無(wú)數(shù)，所以上面一定要構(gòu)建自己的API網(wǎng)關(guān)，這個(gè)網(wǎng)關(guān)可以解決所有的問(wèn)題，要不然下面每個(gè)API的服務(wù)，它的服務(wù)請(qǐng)求SLA都是可以經(jīng)過(guò)網(wǎng)關(guān)控制的，這也是新型微服務(wù)架構(gòu)里面經(jīng)常不被人提起的，被忽略的地方。但是這是非常重要的一點(diǎn)，因?yàn)榈紫碌姆?wù)特別多。發(fā)到集群里，怎么管控這些服務(wù)的質(zhì)量，就是API的請(qǐng)求，出錯(cuò)怎么辦，怎么來(lái)控制？這些都要通過(guò)API網(wǎng)關(guān)來(lái)控制，所以這個(gè)一定要去注意一下。

另外是幾個(gè)大塊的認(rèn)證，如果你的內(nèi)部認(rèn)證沒(méi)有統(tǒng)一的認(rèn)證，就沒(méi)法做標(biāo)準(zhǔn)化的雙向通行，而且API網(wǎng)關(guān)也沒(méi)有辦法給下面的應(yīng)用下發(fā)東西，因?yàn)闆](méi)法認(rèn)證。還有Configuration server一定要加上，Service Discovery單純靠容器解決不了，需要PaaS的容器平臺(tái)解決。做端口、應(yīng)用的發(fā)現(xiàn)，方便其他應(yīng)用訪問(wèn)它。還有監(jiān)控、報(bào)警，然后就是常規(guī)的日志分析，這就是常規(guī)的需求。這些需求里面最特殊的就是容器，因?yàn)楹芏鄠€(gè)要做逐一監(jiān)控，沒(méi)有一個(gè)平臺(tái)是不行的。對(duì)日志也是一樣，每個(gè)容器起來(lái)以后就死掉了，怎么知道這個(gè)容器是應(yīng)用呢？一般都是要通過(guò)容器的ID來(lái)標(biāo)識(shí)，然后收集回來(lái)。

還有一個(gè)API網(wǎng)關(guān)里面最大的特點(diǎn)，快速的熔斷，什么意思呢？就是底下的服務(wù)很可能出問(wèn)題。微服務(wù)架構(gòu)里都打散，上面掛一個(gè)Nginx，如果業(yè)務(wù)量大了，如何快速關(guān)閉某個(gè)API呢？沒(méi)有可編程的接口是做不到的。但是要采取微服務(wù)解決，這個(gè)架構(gòu)的的組織形式就是這樣。微服務(wù)里面承載的這些組件特別復(fù)雜，需要一個(gè)標(biāo)準(zhǔn)的組件來(lái)封裝起來(lái)，這個(gè)封裝組件的方式用Docker是比較合適的。微服務(wù)的架構(gòu)確實(shí)可以解決這個(gè)問(wèn)題，因?yàn)槊總€(gè)組件的升級(jí)很快，如果把整個(gè)組件升級(jí)一下，還有一些其他的東西，會(huì)很麻煩。我們會(huì)想到能給一個(gè)這樣的架構(gòu)，微服務(wù)架構(gòu)里面統(tǒng)一管理服務(wù)。

環(huán)境之間的隔離，Docker做的目錄級(jí)別的隔離已經(jīng)完全可以滿足需求了，原來(lái)為什么做不到這點(diǎn)？是因?yàn)槭止さ牟僮魈貏e多，用別的方法隔離也是沒(méi)有問(wèn)題的。但是我們覺(jué)得，原來(lái)的架構(gòu)里面，CICD的架構(gòu)已經(jīng)很成熟了，能不能把它自動(dòng)化？因?yàn)橥耆梢杂肈ocker來(lái)交付整個(gè)環(huán)境，手工部署沒(méi)有問(wèn)題。我們?cè)偻白咭徊?，怎么走？Jenkins可以調(diào)一個(gè)集群系統(tǒng)，然后分發(fā)集群，剛才說(shuō)的微服務(wù)發(fā)到這里面，然后快速的部署。這是一個(gè)自動(dòng)化的過(guò)程。這里面涉及到一個(gè)問(wèn)題，原來(lái)咱們經(jīng)常會(huì)聽(tīng)到的是持續(xù)構(gòu)建，也就是把原碼先構(gòu)建成鏡像，然后鏡像再發(fā)到集群里面，這個(gè)操作覺(jué)得很順，但實(shí)際上這里面真正的挑戰(zhàn)在于，因?yàn)槊總€(gè)業(yè)務(wù)組件的依賴，還有他們之間的配置怎么抽離出來(lái)，這都是需要比以前更復(fù)雜的。所以，用容器確實(shí)解決了持續(xù)集成的一部分問(wèn)題，但它對(duì)你的技術(shù)要求會(huì)越來(lái)越高。原來(lái)是手工做，而現(xiàn)在需要自動(dòng)化。對(duì)于基礎(chǔ)人員的架構(gòu)改造，其實(shí)是抽象層更高一點(diǎn)，對(duì)大家的要求也會(huì)更高一點(diǎn)。

大版本升級(jí)不可回滾。大版本的升級(jí)困難點(diǎn)在哪兒？原來(lái)都是單體服務(wù)根本沒(méi)法拆，動(dòng)又不能動(dòng)，剛才說(shuō)了微服務(wù)基本上能夠解決它。第二個(gè)情況是每個(gè)版本的版本控制怎么解決？基本上配置中心可以把配置做出來(lái)，然后建倉(cāng)庫(kù)，做版本控制。要做這個(gè)最好是滾動(dòng)更新，也就是在不停機(jī)的情況下，一點(diǎn)點(diǎn)把業(yè)務(wù)遷到新的應(yīng)用上面，然后將老的流量在處理完業(yè)務(wù)之后慢慢的退掉，這是一種辦法。服務(wù)的時(shí)候，原來(lái)指向老的服務(wù)進(jìn)程，自動(dòng)地切到新的服務(wù)進(jìn)程里面，這樣產(chǎn)生流量盡快切到新的服務(wù)里面，所以這是需要服務(wù)發(fā)現(xiàn)的。

我們這邊會(huì)構(gòu)建一個(gè)集群，我們用的ZooKeeper去保證調(diào)度器，在正常運(yùn)行的情況下，我們給Marathon發(fā)指令，讓它把應(yīng)用一個(gè)一個(gè)更新。起一個(gè)服務(wù)，保證老服務(wù)不停機(jī)，這時(shí)再把域名切換，進(jìn)來(lái)的新流量就到新的應(yīng)用里面了，老的應(yīng)用在沒(méi)有流量的時(shí)候自動(dòng)退出，保證用戶訪問(wèn)的時(shí)候沒(méi)有宕機(jī)的感覺(jué)。這是集群環(huán)境里面做升級(jí)的常見(jiàn)案例。

還有各種異構(gòu)設(shè)備，硬件資源利用率比較低，解法是數(shù)人云的應(yīng)用集群。它是容器的集群，我們的系統(tǒng)會(huì)運(yùn)行在獨(dú)立的環(huán)境里遠(yuǎn)程控制集群系統(tǒng)，保證系統(tǒng)里面運(yùn)行的只有容器，然后有相應(yīng)的Agent來(lái)管理應(yīng)用的服務(wù)。

這張圖比較清晰一點(diǎn)，數(shù)人云本身就是微服務(wù)的架構(gòu)，這里面針對(duì)的情況，大家都知道Nginx性能是最好的，我們可能在這上面寫(xiě)一個(gè)新的API網(wǎng)關(guān)對(duì)接整個(gè)系統(tǒng)，這套系統(tǒng)是數(shù)人云系統(tǒng)架構(gòu)里面的一部分。我們業(yè)務(wù)管理用Marathon調(diào)度器會(huì)進(jìn)行升級(jí)，因?yàn)镸esos本身是集群管理的調(diào)度。對(duì)于這些組件，比如鏡像，我們采用的方式是跟VMware合作的一個(gè)開(kāi)源項(xiàng)目叫Harbor鏡像管理倉(cāng)庫(kù)，這是我們和他們一起合作開(kāi)發(fā)的軟件。持續(xù)集成我們和Jenkins做集成，通過(guò)自動(dòng)配置能夠把我們這個(gè)小本下發(fā)給Jenkins，然后和它構(gòu)建鏡像。監(jiān)控報(bào)警，大家會(huì)覺(jué)得容器的監(jiān)控報(bào)警不好做，容器目前為止基本上都是接口，現(xiàn)在新的容器把日志和報(bào)警，所謂的報(bào)警的實(shí)現(xiàn)都要按照流程的方式提供API接口，只要接上就收走日志，在本地不落盤。日志也是一樣，它現(xiàn)在提供plugin方式和日志系統(tǒng)對(duì)接，不用擔(dān)心落到盤里面收上來(lái)是不是把硬盤撐爆，現(xiàn)在都可以配的。這里對(duì)于我們現(xiàn)在新加的網(wǎng)絡(luò)模塊，就容器發(fā)展到現(xiàn)在其實(shí)對(duì)于網(wǎng)絡(luò)都是成熟的，大家都在用host模式去管，雖然容器很輕，但并不比VM先進(jìn)到哪里去，只是說(shuō)它更輕量一些?？蛻粝Ｍ鸙M有的東西它也有，這塊最后也提供了這種對(duì)于IP的管理。所以也是剛剛在上的一種新的成熟架構(gòu)，也就是說(shuō)一容器一IP，現(xiàn)在是剛剛才開(kāi)始支持，這是我們最新配套的。

講完這些方案之后，今天會(huì)有些容器圈的新東西給大家講講。

首先是Docker1.12，昨天它正式發(fā)布了，這是一個(gè)新版本的發(fā)布，最重要的發(fā)布。這個(gè)發(fā)布先是內(nèi)置了自己的工具，再就是對(duì)網(wǎng)絡(luò)的增強(qiáng)，達(dá)到了更容易商用的階段。第二個(gè)是我們現(xiàn)在用的Mesos，也發(fā)布了1.0，可以給大家介紹一下特性。

Docker1.12它有一個(gè)重要的特點(diǎn)，一般在集群系統(tǒng)里面，因?yàn)槿萜魇呛芩榈?，用戶希望知道這個(gè)服務(wù)到底是run還是不run，原來(lái)的方式是Docker run的時(shí)候把端口打開(kāi)，然后通過(guò)一個(gè)腳本去查。這等于是第三方去做，現(xiàn)在提供的功能是可以在構(gòu)建鏡像的時(shí)候就把Healthcheck打開(kāi)，通過(guò)Docker Daemon的內(nèi)容給這臺(tái)主機(jī)上運(yùn)行的容器定期的檢查，通過(guò)Docker知道這個(gè)容器是不是健康的。當(dāng)然這個(gè)功能并不是為咱們準(zhǔn)備的，是為自己內(nèi)置的Swarm編排工具做準(zhǔn)備的，因?yàn)镈ocker公司做集群管理的工具也在想這個(gè)事情。還有一個(gè)情況是咱們最常用的CentOS系列，原來(lái)對(duì)于安全Docker公司一直在回避，它現(xiàn)在默認(rèn)把這個(gè)組件打開(kāi)了，打開(kāi)以后跑出來(lái)更安全。Linux可以打標(biāo)簽、做監(jiān)控，但是這個(gè)東西因?yàn)閯偝鰜?lái)，所以只是一個(gè)信號(hào)，也就是Docker越來(lái)越安全了，原來(lái)是做不到，現(xiàn)在是越來(lái)越方便了，可以做到這樣。Docker內(nèi)置了一個(gè)IPVS，干什么用？就是想替代HaProxy提供IP給網(wǎng)絡(luò)里面。這是比較新的技術(shù)，目前我們認(rèn)為處于實(shí)驗(yàn)階段，它利用IPVS的模塊來(lái)提供網(wǎng)絡(luò)的接口，只是一個(gè)信號(hào)，目前是沒(méi)有采用這種方案的，因?yàn)樘铝?，還要測(cè)試。最后是內(nèi)置Swarm的組件，這是很輕量的編排工具，也就是說(shuō)裝幾臺(tái)機(jī)器，必須要組成一個(gè)網(wǎng)，怎么去做？可以用Swarm做這個(gè)事。這個(gè)網(wǎng)IP怎么做，用IPVS，這就是最新的Docker的發(fā)展，非?？?。

目前為止，一容器一IP技術(shù)理論已經(jīng)落地。每臺(tái)機(jī)器要裝一個(gè)小的路由器，然后小路由器給你的容器。這個(gè)路由器可以想象成家里的無(wú)線路由器，因?yàn)槭莻€(gè)屋子，一臺(tái)主機(jī)里面都有屋子，任何終端設(shè)備都可以向路由器調(diào)IP，這個(gè)IP是假的都可以。當(dāng)然Docker里面現(xiàn)在有了網(wǎng)絡(luò)的插件，就相當(dāng)于類似有了一個(gè)驅(qū)動(dòng)，就可以找路由器要一個(gè)IP，實(shí)現(xiàn)了路由器有IP。大家注意到這個(gè)IP和底下的IP不一樣，他們之間通過(guò)IPtable 做包頭的轉(zhuǎn)換，通過(guò)轉(zhuǎn)換就可以雙向通信了。但是這里面192.168的網(wǎng)段和10網(wǎng)段的管控，如果只做一次轉(zhuǎn)發(fā)，那就控制不了這些IP之間的東西，我們用的方案把這些規(guī)則都記錄在一個(gè)鍵值庫(kù)里面，這樣的好處在于，可以控制這個(gè)IP和這個(gè)IP的通信，把它記錄下來(lái)就可以了，如果刪掉，默認(rèn)不讓它通信也是可以的。雖然一臺(tái)主機(jī)有三臺(tái)服務(wù)器，但是他們之間是否能通信是你可以控制的，這樣更安全。也就是說(shuō)，用戶有一個(gè)應(yīng)用，這個(gè)應(yīng)用是1.1和0.9，放在這兩個(gè)容器上，然后1.10是另外一個(gè)APP，不希望他們之間互相通信就可以通過(guò)IPtable寫(xiě)進(jìn)去，然后把他們隔開(kāi)，他們通信的時(shí)候，一看規(guī)則沒(méi)有就把他們刪掉了，路由器就不會(huì)給它分。

還有一個(gè)情況，都是容器里面的IP，那外網(wǎng)的IP之間能不能通信？因?yàn)閮?nèi)網(wǎng)有一個(gè)路由器，路由器給它分了一個(gè)IP，也想給容器分一個(gè)同樣網(wǎng)段的IP，需要一個(gè)網(wǎng)關(guān)來(lái)轉(zhuǎn)換為可用的IP，轉(zhuǎn)換給它，就是改包頭改完包頭轉(zhuǎn)進(jìn)去。它請(qǐng)求的時(shí)候再轉(zhuǎn)出去，兩個(gè)路由器之間再轉(zhuǎn)一下，是這樣的過(guò)程。它有一個(gè)缺點(diǎn)，就是主機(jī)的數(shù)量不能太大，畢竟是虛擬的IP網(wǎng)絡(luò)，主機(jī)的數(shù)量不是容器的數(shù)量，基本上在200臺(tái)左右是一個(gè)推薦的方式。

性能對(duì)比，跟主機(jī)、物理機(jī)再和calico的解決方案對(duì)比，基本上會(huì)在1024、2048、4096這塊，如果用普通的overlay方案性能就很低，目前Docker overlay自己的原生方案性能就很低，但是它在提升，因?yàn)樗鼊倓偝鰜?lái)。上面這套方案，因?yàn)閏alico的方案只是在包的包頭上做了篡改，欺騙主機(jī)轉(zhuǎn)發(fā)數(shù)據(jù)包，所以它的性能和host主機(jī)之間，有時(shí)候從數(shù)據(jù)表里面看到它傳輸?shù)男?，吞吐量比host還快，但是這個(gè)數(shù)有假像，因?yàn)楦牧税^，但是基本上可以肯定，和原生的host的網(wǎng)卡里面性能是差不多的，是這樣的情況。

最后說(shuō)Mesos現(xiàn)在新產(chǎn)品，就是1.0技術(shù)開(kāi)源的組件，1.0以后，我們基本上就會(huì)有新的HTTP API，原來(lái)的API都是Google的協(xié)議，現(xiàn)在有新的HTTP API更方便數(shù)人云和它做深度整合，我們也希望不斷的前進(jìn)，給客戶提供更好的產(chǎn)品。第二個(gè)情況，大家現(xiàn)在遇到的情況，那就是Docker有各種各樣的bug，這個(gè)問(wèn)題沒(méi)有很好的解決辦法，因?yàn)镈ocker公司的產(chǎn)品是開(kāi)源的，它的商業(yè)產(chǎn)品也到不了中國(guó)。Mesos解決了這個(gè)問(wèn)題，Mesos擁有給Twitter、蘋果等都部署過(guò)幾萬(wàn)臺(tái)的節(jié)點(diǎn)的經(jīng)驗(yàn)。他發(fā)現(xiàn)安裝Docker Daemon以后，Docker是很不穩(wěn)定的，尤其在大規(guī)模集群方面很不穩(wěn)定，所以他們推薦另外一個(gè)方式，就是用原生的容器框架解包鏡像?？蛻粼诒镜赜肈ocker，但是把鏡像發(fā)給我，我用另外的方式把這種鏡像給起起來(lái)，用戶是透明的，就認(rèn)為它是Docker room，但它不用了Docker Daemon，因?yàn)榘袲ocker Daemon關(guān)掉以后容器就死掉了，但是把Docker Daemon去掉以后，容器還要通過(guò)原生的方式運(yùn)行起來(lái)，這就滿足了企業(yè)的各種需求，這是新的技術(shù)點(diǎn)。還有云原生APP架構(gòu)里面，對(duì)于網(wǎng)絡(luò)需要一個(gè)標(biāo)準(zhǔn)，現(xiàn)在提供了一個(gè)類似的架構(gòu)，Mesos提供了這個(gè)標(biāo)準(zhǔn)。另外就是支持GPU。還有Mesos在和微軟合作，開(kāi)始接管Windows的一些信息，這也是比較大的亮點(diǎn)。這個(gè)生態(tài)圈還是比較活躍的，這也是數(shù)人云關(guān)注和考慮的。