乔融：今天四个方面开始讲，第一个是金融业对容器云的需求和目前的痛点，第二个是解决方案，第三个是容器PaaS平台，第四个是案例分享。

金融业转向云的话有一些需求，首先是政策的需求，金融云的监管机构要求在十三五规模末期所有的互联网相关业务必须上云，传统业务至少50%上云，这是一些政策要求，还有外部因素，首先就是互联网，比如阿里、京东这些对传统金融挑战是很大的，他们的特点是快速扩容、快速上线、快速迭代，目前有一个说法叫去IOE，就相当于把以前的IDM这些慢慢的去掉，逐渐用开源的产品，这就是一波新的私有云建设的浪潮，目前不管是从单体或者面向服务的应用都有一个趋势，要转向微服务的应用。

传统金融IT行业的痛点，首先是现在目前很多金融行业他们的应用都还是一个单体应用，刚才我也听有些嘉宾说了，一个应用可能达3G或者4G的样子，这样一个大的应用部署效率是非常慢的，与其说你要对这个应用进行升级，或者部署，以及要维稳效率是非常差的。还有传统开发模式，一般单体的传统开发模式都是有瀑布式模式，特点首先是做设计，设计完以后开发，研发人员开发按照以后交给测试人员测试，这样有一个问题，研发的时候测试人员没有什么事儿干，交给测试人员以后研发的人员没有什么事儿，最后有问题大家一起，变成一团乱的感觉。传统开发模式还有风险，很多都是你开发一个功能，等你这个要功能都好了，在一起集成到一个主分支上，周期性有点长，而且会把其他已有的功能破坏掉，传统的模式可能你测试是再一个环境，真正的生产环境部署又是性外一个环境，不可避免有些环境会有问题，还有你搭建也比较费事。还有一个问题，是业务的需求动态变化，比如说我们春节抢红包，平时抢红包没有春节大，但是突然一个时候需求访问量猛增，如果你以前部署到一个传统的架构上，它以前的物理设备以及算法可能不能满足同时的需求，为了解决这些问题，就提出了这个解决方法，去解决刚才的痛点，三种方法去解决问题，一个是微服务化，还有一个是DevOps，还有一个容器云平台，那我们倒过来看一下怎么解决问题的，单体部署效率，升级与回滚，我们划分成微服务，这个后面会详细讲。传统的开发模式有一些问题，完全可以通过DevOps解决，DevOps其实就是一个持续集成持续部署的过程，业务需求动态变化如果现在采用微服务以及容器变化工具，我们一般容器变化工具都有一个动态伸缩的功能，也很好解决这个问题。我们来详细的看一下DevOps到底是什么东西，怎么解决这些问题。

DevOps最早的概念就是持续集成，持续发布，其实是早于微服务的概念，其实现在目前这个流程相当于是结合了容器的流程，就说当一个研发人员把代码提交以后，然后再后台就会自动的运行静态检查，比如检查它的代码有没有什么语法格式以及他的格式是不是正确，这是最基本的检查，还有测试，之后会编译进行打包镜像，生成镜像以后会放到测试的镜像仓库里，会触发一轮新的测试环境的部署，部署好以后会自动化的测试，测试好环境以后如果没有什么问题，通过率达到我们试点的要求，它会到生产环境的仓库里去，在生产环境的仓库里会在生产环境上进行部署，刚才我们说了即使测试环境部署以后，生态环境还是有必要测试一下，因为这个生产环境不管是不是容器，其实还是有可能有微笑的差别，负责的说生态环境还是需要进行一些测试的，如果生态环境没有问题我们可以采用发布的形式来升级某一个微服务，这样可以在很快的频率做一个小程度的升级，达到不停业务的作用。

刚才说了一个传统的CICD的步骤，其实要实现CICD有一个重要的问题，就是智能化，很多公司想做CICD，就是持续升级和发布但是他们在这块就被卡住了，因为持续集成是要求频度很快的集成，如果没有强大的制动化系统做是不可以的，自动化有一个原则，你是尽量把所有的操作都进行自动化，包括静态检查还有所有的测试都需要自动化，以及自动化的管理系统，因为我们在实践中发现你的测试已经很完善了，但是工程师还是不愿意去跑，就是你的测试管理系统不够自动化，有可能是说你这个测试管理系统没有做到够智能化，手动测试就不负责的提交了。交付的时候我们也可以自动化部署也可以自动化，最后是升级维稳也可以实现自动化。

工具很多了，这是我自己比较熟悉的，里面有很多持续集成的工具，也是开源的，还有Pytohon自带了很多的库，开源的自动化也是基于它做的，还有Selenium，Ansible，还有容器编排工具。

强调自动化以后你就可以做持续集成，持续集成一般的步骤就是提交以前自己要测一测，提交以后可以做静态检查，没有问题以后可以构建，比如生成一个应用程序这些都是可以的，构建好以后可以部署到测试环境，然后对你的新功能进行测试，测试以后还要回归测试，最后保证你这个新提交的代码不会把已有的功能破坏掉。说到持续集成，跑这么多的测试，有一个主要的目的就是不管谁的代码提交不要把你已有的主分支破坏掉，持续集成是你的主分支在任何情况都可以发布，如果有一边把你的主分支搞坏了，你就不是解决新开发的功能，而是解决已有的问题。

一般生产环境还有一些条件，比如你的持续几次的百分之百自动化通过率，还有系统集成测试，可能需要几个部门的领导批准才能自动化的部署，我们现在有些客户就觉得他的功能不是目前很重要的功能，而是可以先尝试自动化部署，自动化持续集成发布这几块做到以后，传统的DevOps可以说是实现，可以快速的进行一个产品的迭代发布，但是这样其实可以解决一些效率的问题，但是没有完全解决，因为我们说了还有单体自己的问题，那么单体的问题解决最好的办法就是微服务化，大家可能听的比较多了，我概括的起来说一下它的特点，什么叫微服务化?就是一个服务只做一件事，每个微服务化是一个松耦和紧耦的东西，微服务可以部署在任何节点上，任何机器上，是没有要求的，当然他们之间通过API进行通信，一般一个微服务只要定义好API以后就可以被分到一个小的器物上进行开发，开发的过程每个team可以开发多个微服务，但是不能说一个微服务可以流动的开发，如果你的库文件和你的微服务没有什么关系，你尽量的要把库文件去掉，要保持微服务的警惕性，我们看，一个微服务有一些特点，一个特点是它可以被部署到不同的机器上，这是一个跨平台的，以及它包含尽量少的文件，这是第二个，微服务其实和目前的Docker容器结合是一个很好的结合点，看看什么是Docker。

Docker是一种容器技术，这个概念已经早就有了，只是最近两年把它开源出来以后才变得这么火，容器技术我们可以看这边传统的容器虚拟化技术，第一代虚拟化技术其实就是我们以前用的Hypervisor，这种虚拟化技术有它的好处，这种虚拟化技术有点冲，它占的资源比较多，所以说我们看看 是容器虚拟化技术，它没有自己的操作系统，你宏观的看其实你的容器技术可以看作是一个轻量级的虚拟机。由于说它的这些特性，那么它占的资源非常少，它其实也是跨平台的，你可以说你在一个机器上做的镜像，也可以跑到一个跨平台的，刚才我们说你在生产和测试环节中平台不一样的问题，还是可以和它的配置文件一起打包，容易实现高可用。

我现在介绍一下我们公司的产品叫EcOS，我们自己开发了一个调度工具，市面上比较知名的开源编排工具有Dockers这些东西，我们考虑有一些用户定制化比较强，我们整个是一个容器调度引擎的平台，除了支持我们自己的开发引擎我们还支持K8S，是一个开源的容器引擎，在我们容器云平台上我们实现哪些功能?我们有持续集成，持续发布，我们自己开发的一个完全自己的持续集成发布，还有存储管理，存储管理我们集成了EBS等这些存储插件，可以直接以块巡视的方式访问网络存储，我们还有自己的监控系统，日志系统以及服务编排，还有一些网络管理，网络管理我们也是基于开源的网络，做了一点点二次开发，我们做了以后我们性能测试中，如果你的裸机的网速155兆每秒，我们的测试结果135兆每秒。

我们这个环境可以跑在虚拟机上，或者说你跑裸机也可以，都是没有关系的，这是我们内部平台的一些镜面，第一页是主机上的容器状态等。今天我们的主题是说Docker容器在金融行业的应用，目前有很多的银行要求做深度POC，其实我们也有一些客户是完全落地的客户，我给大家分享一下落地的客户到底是什么需求，它的需求其实就是比较通用的，需要把它所有的环境全部适应化，把单体服务放到容器里，有可能有的时候它的访问需求是变化的，有的时候可能它的访问量很少，但是有的时候达到百万级的访问量，对于它的需求我们地区一些解决方案，我们把环境分为生产环境和测试环境，而且生产环境可以部署在两个地方的生产环境，部署两个地方以后用一个智能的方式实现负载均衡，生产环境就是你下面存储是Ceph存储，你可以在同城或者同实验室对它的ceph进行备份，远端还需要一个备份，保证双重备份，即使有一个实验室完全挂掉对业务也没有影响。

这是解决方案的逻辑架构图，最下面的是EcOS容器云平台，这一层是MySQL数据库集群，通过我们的存储插件直接访问ceph，这里面一套都是开源的，这一层是他们继续跑的应用，这一层是以微服务的方式跑起来，跑起来以后就用我们的容器编排工具来对它的容器的使用进行实施的操控，每个容器，当你容器达到一定的使用率的时候，比如我们设了限制，你CPU达到80%，内存到80%，某一个资源达到这个消耗以后就会自动的扩容一个微服务的容器数量，这样就达到刚才说的可以满足动态的需求变化的一个问题，我们使用etcdCantid，上面采用了双重负载均衡的方式，右面是客户自己使用的其他开源工具，有一些自动化恢复的管理。这是我们产品的API来支持他们的持续集成持续发布，这就是那幅图的具体实现，当有代码提交以后，我们的环境监测到提交了这个就会自动的跑一些静态检查，去编译部署，最后生产环境会升级，现在关心这个事情的很多，但是真正落地以后他们目前还没有把太核心的跑上来，更多跑的是一些做试水的环节。谢谢大家。