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

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

以下是演講實錄：

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

最新的資料顯示，現在是應用Docker技術的比較好的時機。全球雇員超過500人的公司中73%已使用Docker技術。國內的很多公司也都在關注這項技術，尤其是金融行業，因為金融業的IT發展的比較成熟，他們對新技術比較關注，Docker已經有很多生產應用在里面產生。

用Docker能干什么是大家比較關心的問題。第一個比較常見的場景是DevOps，DevOps實際上就是提高生產力。原來，開發能做運維的事，運維能做開發的事。但實際上從真實的場景里，術業有專攻，在創業公司可以這么干，但傳統公司做不了。Docker可以幫助企業進行業務的轉型，提供標準的接口，這樣開發提供標準運維能知道，運維提供標準開發也能知道。傳統企業的開發流程不像創業公司，一個人要干很多事，傳統企業強調的是標準化，是業務的轉型，而在原有的老的制度下很難實現這種標準，用Docker技術可以加快轉型。

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

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

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

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

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

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

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

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

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

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

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

還有各種異構設備，硬件資源利用率比較低，解法是數人云的應用集群。它是容器的集群，我們的系統會運行在獨立的環境里遠程控制集群系統，保證系統里面運行的只有容器，然后有相應的Agent來管理應用的服務。

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

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

首先是Docker1.12，昨天它正式發布了，這是一個新版本的發布，最重要的發布。這個發布先是內置了自己的工具，再就是對網絡的增強，達到了更容易商用的階段。第二個是我們現在用的Mesos，也發布了1.0，可以給大家介紹一下特性。

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

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

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

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

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