今天我题目叫做Docker容器在传统行业的落地实践。我们2015年开始做，我把这个坑给大家分享一下，包括我们一些思考跟大家分享一下。
整个的容器在传统行业落地的时候，第一个问题为谁服务的问题？因为我们很多客户，我问这个应用你用它上容器的目的，他说我想试试，我回答是这种应用上容器没有什么作用。容器在传统行业应用要解决的问题，敏捷模式、互联网模式应用问题的解决。从客户期望来说想解决问题是这几个。一是双十一的时候，淘宝那边流量一进来我就可以跑了，能不能解决弹性的问题。我们现在应用发布很慢，两个月一个迭代，是不是把发布周期很长的问题解决掉。AO客户说我们整个平台变化能力比较差，能不能把我这个问题解决掉，这几个是比较典型的需求，我肯定回答说是可以的。但是仅仅落地容器是不够的，因为容器平台部署好之后可以能帮助解决这些问题，但是并不是说做了容器一定能解决这个问题。为什么？首先弹性问题，弹性问题说起来比较简单的，容器化之后可以很大程度解决这个问题。但是发布周期长的问题，你迭代很慢的问题，整体来说容器化能帮一些忙，其实它要整个解决，实际上是应用架构的解决和Docker平台落地才能把这个事情解决掉。
举个例子，我们有一个客户有一个应用，这个应用部署起来需要上传20个包，20个包整个存储空间需要七八百兆的空间，因为它没有配置管理，所以这个包上传必须开发人员从自己电脑上手工集成，集成完之后打包上传，打包完之后这个应用有时候配置项一百多个，你从界面或者多种手段要配置好，上传和改配置的工作这样去做需要三个小时，你升级容器没有解决问题，其实更复杂了，不是我们平台有问题，你应用架构是有问题的。
第三个就是说并发内容多，这个更多是架构问题，或者整个并发能力解决的问题，可能跟容器平台没有什么关系。这些是客户比较传统的需求，需要容器、Docker和架构一体化解决的。做容器比较长的不论是我们厂商还是客户应该有这样的认识。
刚才讲到容器的基础就是软件架构，我们看容器化其实对软件架构是什么样的，我希望应用是分布式的，如果它不是分布式的没有意义，你不是分布式，我连弹性都没有做，容器应用比较小了。我希望它是无状态的，希望它可以快速定位，我们启动容器化应用，这样一个东西上容器，希望发挥容器的更好作用。DeoOps我们希望体量不要太大，单个应用不要太大，太大应用其实你很难做这种垂直层，也很难把这个流水线跑起来，希望是比较小的，服务是松偶合的，这样持续交互流水线互相之间没有关联，这样很好打通，到最后做集成。看起来就是做微服务的要求，所以这三个合在一起。
容器平台建设关键问题，我们说传统行业建设的关键问题，我们总结八条。第一条弹性伸缩问题，怎么快速有效的伸缩。第二个配置管理的问题。因为传统行业的应用跟互联网公司应用有区别的，毕竟管理是一个难题。网络问题，网络问题我今天稍微讲一讲，我看前面老师已经讲了一些内容。还有传统行业我们流程跟互联网公司不一样的，你从互联网公司去传统公司你会觉得流程很烦比较复杂。还有平台对接，你平台过来以后可靠性怎么样，安全性怎么样，你怎么给我保证的这些问题。
弹性伸缩，基于镜像启动一个新的容器，然后把负载均衡器改一下，这个弹性伸缩就做完了。实际上首先你弹性伸缩，你基于什么指标做弹性伸缩，什么时候弹，什么时候缩，我怎么调配新的应用，缩容问题，用户不够用怎么办，用户扩了怎么办，底层资源不足我怎么办？具体来讲第一个弹性伸缩的指标，所有的容器平台默认支持两个指标，第一个CPU，第二个内存，可能还有人支持网络流量，这三个指标做弹性伸缩。这几个指标有没有意义，有意义，你基于你性能测试结果，知道什么时候CPU内存到什么程度，把指标配置好，肯定有用的，尤其对CPU内存比较敏感应用是有用的。从一个比较合理的角度来说，最好方式跟应用监控平台做指标，基于应用监控指标做这个弹性伸缩最合理。如果这些做不到，我们手动弹性伸缩也可以做这些工作的。
还有一个负载均衡的问题，传统负载均衡用F5比较多，有一个对F5自动配置的问题，需要整个平台支持这个能力。另外还有一个问题容器启动了，是不是里面应用就一定启动了，这个不一定的，到底什么时候应用调动，你做一个应用可用性的监测，确定可用以后把客户调过来就是可以的。我可以多等一些时间，把用户调动过来。
另外缩容，你怎么保证用户在上面，如果用户在上面缩容了，用户掉了怎么办，我们用Session解决这个问题。另外IAAS对接和资源自动获取的问题，资源不够怎么办？需要你容器平台跟IaaS平台做最接，VCENTER对接，open Stack，公有云对接。
刚刚讲容器化应用的配置管理一定是一个问题，互联网公司里我们理想状态下希望有一个配置中心的，这样配置统一先发的，跟容器镜像无关，是格式化管理的，你把配置改了甚至都不需要重写东西，尽量通过一个服务中心做，这样配置变得非常简单了。很多传统行业没有这么好的条件，也有几个方案做。第一个环境变量的方式，或者用Kubernetes也可以，我们早期也有直接改配置的文件。它的是开发、测试、生产三个环境都是独立容器，这个你做好之后也是可以解决问题的。
另外容器网络，前面讲很多，容器网络的性能一直有问题的，下面图是我们测容器网络的性能。前面第一个容器访问它本身的主机。Docker原生的方式，还有OAS的模式，容器访问自己的主机，只能达到实际网络的一半。还有一个问题容器跑在虚拟网络上，性能会下降非常厉害，甚至下降80%以上都有可能的。这个问题有很多解决方案，京东前一段是开源社区做得事情。DPDK在Docker上有一些难点上，虚拟化上可以做的都实现了，所以我们找到中科院软件所一起做这个事情，实验室已经把它解决掉了，还要有一段时间正式应用到我们产品上去。
流程适配问题，传统公司讲我们这边有很多流程，你这个一定适配我们流程才能用起来。这不是Docker的问题，而是DevOps的问题DevOps怎么做？我们希望落地一个新平台，落地一个新的软件开发模式，不要成为一个包袱，我们希望有一个新的应用，有一个新的DevOps试点团队做这个事情，开发设计阶段是偏互联网方式的流程，到了生产阶段，有不同机构的要求，我们走一下传统流程，保证生产经过流程验证没有问题的，这是我们一个想法。
还有一个传统行业跟互联网公司区别比较大的地方，开发环境、测试环境、生产环境，开发和测试环境是物理隔离不通的，这种情况下怎么做？实际上来讲把开发测试和生产环境隔开，他们之间交互有一个镜像交互就可以了。运维人员用熟了很多系统，他要求你平台适配这个系统，而不是说你容器平台自带的管理我就用，比如说监控管理、日志管理，IAAS平台都需要跟他们平台对接的，你提供Docker管理的一套系统，实际上你很多能力要在传统行业里面原有的程序支持。
还有容灾的问题，你上了容器之后，两地三中心这个要怎么办？我觉得这个好像没有什么关系，我后来想想可能客户觉得你把我整个应用部署方式，管理方式都改了，我两地三中心不知道 怎么管了。简单强调几点，第一点整个容灾，两地三中心核心有两个部分。第一个是上面负载均衡调度的问题。第二个下面数据库这一层，存储这一层数据一致性保障的问题，这两层其实都是跟容器关系不是很大，当然有一些关系但是关系不是很大。实际上来说容器改变更多是整个应用的发布，应用部署的过程，这个过程需要我们专门解决的，其实方案有跨数据中心统一应用管理的节点统一管理整个数据中心的发布，当然还有不同的策略，属地中心、异地中心，切换更多是应用方面，负载方面就可以了，其实跟容器本身关系不是很大的。还有安全性的问题，我这边正好讲的有一些算是不是特别重复的内容。刚刚讲那几个点，容器安全性还有一个大家比较安全的点就是镜像安全性，镜像安全性是一个什么问题？首先如果我们镜像都是安全的，实际上对传统行业安全的增强。因为传统行业里面有很多时候，我们的客户也是在不同地方获取到不同的应用包、软件包，而且有很多不同的版本来部署，其实是比较乱的。容器化之后，经过镜像之后标准化把它底层资源，包括中间件都是标准化的，这个镜像本身是安全的，是对传统行业的增强。
我们现在做得事情就是为我们客户提供标准化的镜像，另外我们去年开始社区推一个社情，就是关于镜像安全扫描，我们也推到我们这里来了，做安全镜像扫描这个事情。
容器部分最后关于运维的可以用性，我们把容器定义为运维管理平台，从运维发布部署到运维管理，都是容器平台的能力。其中有一点运维，这是我们给一个证券公司做得服务治理，我们现在比较主流的Docker开源的框架，基本上来说支持Java为主的，传统行业有C，各种别的语言，我们上面用了几个不同的架构搭了整个分布式架构的架子，帮它做整个应用恢复架构的服务治理，解决校验分析、黑白名单、负载均衡、熔断的问题。整个来讲这是从开始创建到最后整个部署，从代码开始到最后整个平台。
我们帮客户落地容器的过程当中我们发现，客户很多诉求，仅仅落地容器不够的，还需要做一些别的事情，我个人对这个DevOps非常感兴趣，花很长时间研究它，包括参与DevOps的培训，我觉得确实有启发，跟大家分享一下。
落地有这几个难点：第一个架构耦合的问题，我架构耦合之后不管你做什么事，发布速度，包括弹性包括部署非常难做。这个事改掉很难。第二个关于质量控制测试，测试这个事情传统公司基本上很少有公司说我把自动化做得很好，这是一个难点。第三个交付和发布是我们在做的事情，因为应用部署和容器平台是解决这个问题的。第四个传统行业也是求新求变。我们有很多企业说我们要敏捷，我们要上容器平台，这是它一直做的事情，这个事情只是做了局部优化而不是整体的优化，这样导致做任何一个事情你感觉起不到效果。
整个来说DevOps全局有什么东西？这是百度张老师的图我结过来用的，红色部分是容器部分可以解决的。可以看到这个东西是比较大的框架内容。从数据交付来讲也会有提交与编译，测试与应用，最后交付与运维这三个步骤，没有一个好的技术架构支持，没有一个团队支持，这个事情很难去做。所以说这个事情应该说有一定复杂性的。
具体来讲我认为DevOps实施落地的步骤建议是这样的，第一个需求驱动。什么意思？首先我们大家都比较痛，一定要解决这个问题，刚才我讲了它推起来非常难。第二个试点先行。你找一个东西试点，你在原来框架里面改改把这个事情做了不可能呢，这是我们去年帮客户做咨询的时候提的，你找一个应用，这个是互联网应用，跟兼容关系没有那么紧密，你来做一个事情可能比较容易一些。第三个独立团队，你找一个独立团队干这个事，你先有一个新流程把这事办了，最后看效果怎么样，有了效果之后，大家再来去做这种更新，想办法把它推广出来，这是比较合理的方案。最后一个先架构再平台最后流程。先把架构这个事做了，一定要把基础打好，然后你再做一个平台把这个事固化下来取得效果，最后我们适配所需要的流程事情，这样比较容易落地，是这样的。
最后一点我们是2012年成立的创业公司，我们要解决我们公司的事情。我们以容器和运维为主的创业公司，2012年成立。目前来说我们主要客户都是金融客户，而且以做容器为主的，还有自动化运维这样一些产品的公司。今天我分享的就是这些内容，谢谢大家。