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

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

以下是演講實錄：

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

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

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

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

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

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

在2015年，當(dāng)時去跟客戶說我們上一個Docker，人家說你的Docker和VM比有什么好處？VM用的多好，為什么要上Docker？當(dāng)時我們是無言以對的，因為安全性，還有各種生態(tài)圈的工具鏈也不成熟。但是慢慢的，我們在做這件事的時候發(fā)現(xiàn)，其實這是需要和企業(yè)一起成長，我們也總結(jié)一些步驟。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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