标签：
复杂的基础IT架构是传统金融的现状，如何快速响应用户需求，加快新业务上线速度，缩短产品的迭代周期？ 数人云在容器落地金融云的2年实践中，实现金融核心业务技术WebLogic、J2EE、Oracle中间件的容器生产标准，已在证券交易所、股份制银行落地生根发芽。服务编排、服务发现、持续集成、大数据容器化、高性能容器环境等多方面为业界提供参考实施标准，真正构建动态灵活的金融IT。以下是 数人云 创始人兼CEO王璞在2016@Container容器技术大会·上海站发表主题演讲的实录分享：
困扰金融行业的三个难题
首先我们一起看三个问题，这三个问题不仅困扰着金融行业，很多传统行业的企业也同样面临着这些挑战。
首先，新应用上线速度已经从月缩短到天，如何快速响应用户需求？新的应用上线对速度要求很高，在国内，互联网行业发展非常迅速，互联网给传统行业带来了很大的冲击和影响。传统行业的很多业务也需要快速上线，这对他们已有的IT架构提出了很大的要求。第二，新技术层出不穷，如何以标准化的方式进行应用交付及运维？这个问题也非常典型，是很多传统行业的企业都会碰到的问题。新技术该如何选择、如何落地、如何交付？最后，秒杀、红包等高并发应用增长，如何应对弹性应用突发增长？秒杀、红包这样的高并发业务非常具有互联网的特征，金融机构这样的传统企业要如何应对？
这三个问题共同反应出的一个现象是，传统行业的企业业务形态已经发生了变化。众所周知，金融行业具有大量面向个人用户提供的服务，2C的场景和互联网的结合是一个不可逆转的趋势，而正是2C服务的互联网化、在线化，导致了金融行业业务形态的变化。在今天，金融行业的很多业务本身具有了互联网业务、互联网场景的特征，这就要求金融行业结合互联网场景去解决新的业务问题。同时，安全可控信息技术的需求，也给金融机构的IT架构带来新的挑战。
金融行业 IT 现状
第一条跟其它行业非常不一样，即合规是红线，零事故是要求。银监会、保监会、证监会对金融行业有很多要求，很多规则都是不能触碰的红线。金融行业对稳定性的要求非常高。
第二，互联网场景业务面临高并发压力。这也是金融机构在传统的业务中不曾面对的挑战。传统业务的特点是具有稳定的峰值，白天的工作时间有一定的峰值，会达到一定的高峰，而到了晚上又回落下来，第二天的高峰和前一天的高峰非常接近，而互联网场景业务则是突发的、不可预测的。
第三，已有应用快速部署难以实现，缓慢的升级流程。这也是金融行业已有业务特点决定的，由于稳定压倒一切，这就需要经过全面的测试，全方位的集成等等，而这延缓了上线的速度。金融业通过降低业务上线的速度保证稳定性，与互联网公司的做法刚好相反。
第四，多套环境相互隔离，测试环境搭建极其耗时。金融行业的IT环境是互相隔离的，举例来说，银行的开发、测试、生产至少有三个环境，三者之间基本上都是物理隔绝的。而环境的物理隔绝，则导致了测试环境搭建的难度，很难复现生产环节。我之前在谷歌，谷歌只有一套生产环境，开发、测试以及生产都在一个大的数据中心混合聚集。以谷歌为代表的互联网公司的开发、测试、生产环境不是物理隔绝的，三个环境混合搭建，这样的话，测试、复现整个生产环境就变得非常方便。但是，出于合规的要求，金融行业是做不到的。
第五，大版本升级不可回滚。这和上一条各环境互相隔离是有关联的。因为环境很复杂，金融机构很难回滚，因为每次上线都会对已有环境做修改，回滚就需要撤销此前的修改，所以回滚在金融行业是也很难实现的。
第六，各种异构设备，硬件资源利用率极低。最后一点可谓金融行业的一个历史包袱，在金融机构中各种各样的异构设备非常的多。十年前很多金融机构都大量采用大型机、小型机，这些设备一直沿用至今。另外，这些设备的资源利用率并不是很高。因为，传统业务并不具有突发性的特点，非常有规律，比如白天是高峰，到了晚上就是低谷，利用晚上的时间还可以跑各种批量的业务。此外，金融行业很多的业务都是跟硬件绑定的，很多业务应用都是静态部署的，每个业务都是由特定的硬件去支撑的。在谷歌不是这样，谷歌不会把特定的应用装在某台服务器上，业务应用和服务器的强绑定对于谷歌这种量级的数据中心的维护难度太高了。谷歌有两百多万台服务器，如果业务应用都要和服务器进行强绑定，那运维人员在上线的时候，就要记住每台服务器上跑了什么应用，这显然是不可能的。但是金融机构的数据中心规模不像谷歌这么大，所以能做到业务应用和硬件的强绑定。但是强绑定就意味着资源利用率不高，因为业务不可能7*24小时都处于繁忙状态，在闲的时候，计算资源就无法得到充分的利用。
以上是金融行业IT现状的一些介绍，不能说很全面，这是数人云接触到的金融客户的表现，尤其是它们和互联网公司差异性非常大的地方。
金融行业 IT 发展新需求
这里列了三个方面——新容量、新速度、新效率，总结了金融行业IT发展的一些新的需求。 首先是新的容量，容量指的是业务的容量。金融行业的业务规模发生了很大的变化，红包、秒杀这样的业务需要瞬间横向扩容的能力，金融行业需要秒级横向扩容能力扛住抢红包等突发性流量。同时金融行业还需要屏蔽底层的异构，实现混合云无缝部署。
另外一点新的速度，互联网快速的业务迭代给传统行业带来了很大的影响，传统行业也在不停地提升自己的业务迭代速度。在保证稳定性的前提下，像互联网公司那样做到每个月或每周都能有新的版本的迭代，这对于金融行业是非常困难的。因此，金融行业需要实现无手工操作，从代码到线上环境持续集成，将上线时间缩短到小时级别。金融机构需要灵活提供全真的测试和开发环境，并通过灰度发布、A/B测试降低快速发布带来的风险。
再一个就是新的效率，金融行业需要将传统物理机的资源利用率提高2-3倍，底层实现小规模错误自动容错，同时还要有效管理不同基础设施上的多个集群，使他们不受业务规模扩张影响。
金融行业 IT 的期望
这三点既是金融行业IT发展的挑战，也是需求，这是我们简单总结的金融行业IT的期望。前面说到，金融行业的业务发生了很大的变化，2C的业务越来越具有互联网的特征。因此，支撑2C相关互联网场景的业务需要尽量做到一体化，也就是说，从需求的提出、到开发、测试、发布上线，再到后续的运维、监控等等，所有的流程都要尽量使用一个流程。
统一的流程可以使整个应用的生命周期变得平滑，而这也是Docker技术带来的巨大便利。Docker屏蔽了环境的异构，使开发写好的程序到测试也同样能够跑起来，测试跑通的程序再到生产环境也同样适用，这样一体化、平滑的流程就贯穿了应用的整个生命周期。
下面举了一两个特定需求，比如在测试环境里如何基于容器技术快速搭建各种各样的测试环境；在测试的时候如何基于容器技术快速生成组件，测完了还可以快速回收。这些都还是期望，的确是一个很大的蓝图，现阶段金融行业还无法实现这么平滑的流程，但是整个金融业都在朝着这个方向努力，开发、测试和运维部门都在积极的拥抱Docker技术，拥抱容器技术来对他们的IT架构进行换代升级。
容器技术可以为金融行业打造平滑、一体化的IT系统，同时，它也会给已有IT架构带来很多的变化。我们一起看容器是如何与金融机构已有架构来对应的。 用类比的角度来看，很多金融行业客户现有的企业级IT架构大多是基于Java的，是右面这套构架。最下面是资源层，以前右边都是基于IBM、惠普这些高端的硬件，像大型机、小型机。左边是采用云构架以后，更多的都是偏X86，PC机的服务器，基于X86做虚拟化或者是采用私有云、公有云服务，这是资源这一层。再上面对应到中间件这层，此前金融行业大量使用基于Java的中间件，像Weblogic、WebSphere。中间件要提供标准的Java运行的环境，用J2EE等等开发的Jar包都会跑到中间件上。尤其是像Java的中间件，包括Weblogic、WebSphere提供的就是标准的Java程序的运行环境。对应到云这边，基于容器技术的数据中心操作系统，也就是这个云计算的PaaS平台，就是云时代的中间件，因此，它要提供标准的应用运行环境。这些应用现在绝大部分都是容器化的应用。中间件这一层要提供标准的运行环境，以前的Weblogic、WebSphere等Java中间件提供标准的Java程序的运行环境，而左边的PaaS平台则要提供标准的容器应用的运行环境。再往上一层就到业务封装，业务应用开发这一层，传统企业级IT都是用Java、J2EE，现在大家则更多的用容器去封装。容器不是一个单纯的编程语言，更多是应用的封装方式，容器里面可以是各种各样的应用，Java的、C++或PHP的。对应用进行封装，J2EE是封装成Jar包的形式，而到了云时代大家则用Docker进行封装，使之变成容器的形式。业务封装再往上一层就是业务的架构了，传统企业级IT更多用SOA的构架，到了云计算时代，使用了容器技术，大家就开始过渡到微服务的构架。微服务和SOA的构架在本质上是一脉相承的。首先SOA构架是面向服务的，微服务也是面向服务的，只不过微服务对于服务的细粒度变得更细小了。微服务对每个服务都分别去进行开发、维护、上线。这和传统的SOA是不太一样的，SOA更多的是将开发层面不同的业务逻辑抽象成不同的服务，再将不同的服务分派给不同的团队进行开发，最后整体上线。而微服务连上线都是碎片化的，不同的微服务各做各的运维，这是业务构架层面。最上层是开发和运维组织构架的层面，传统企业的开发运维是分离的，云时代的开发运维要做到持续集成、DevOps。其实持续集成、DevOps或者是再通俗一点的敏捷开发，最根本的就是整个开发运维的一体化，这涉及很多组织构架层面的调整。这就涉及到人事、组织方面的调整，这与IT架构的调整是不同的，是很复杂的改变。
基于云计算重塑新一代企业级IT，不仅仅是技术层面的改变，也是组织架构方面的改变。这其中会包括开发和运维的协作方式，多部门间的融合，职能划分的变更等等。在谷歌，开发大概能达到两万名左右，而运维人员也就一两千名，数量非常少。但是谷歌的运维人员管理服务器的数量却是很大的，几百万台服务器全部由运维来管。谷歌的运维部门和金融行业运维人员做的事情是不一样的。谷歌的运维人员做的更多是资源的规划，以及开发流程的规约等。谷歌的运维把很多传统行业运维做的事情下放给开发，比如说业务的上线，谷歌的运维人员是不管开发的。
监控、管理、操控
敏捷开发绝对不是形式上的东西，它会有很深的组织架构和职能上的转变。这张PPT介绍，如何从传统的企业级IT角度理解基于云的IT构架。它包含三个部分，监控部分、管理部分和操控部分。中间通过CMDB配置管理数据库把几个模块连通起来，这张图对于传统企业级IT业内人士比较容易理解。 系统的集中监控有很多层面，包括机房设备的监控、拓扑的监控等等。自动化的操作平台，包括任务的上线，权限的管理等等，下面有机房、网络等系统不同的操作，这两个模块对于很多金融行业数据中心部门的同事不会觉得陌生，他们每天的日常工作就在这两部分里面。监控和自动化操作称之为操控，上面就是管理的部分。管理部分更多的是流程化的东西，比如数据中心运行管理调度出了问题如何去处理，变更如何去处理，发布如何去处理，配置如何去管理等等。管理是整个数据中心外延的部分。
那么，容器云要如何与已有的数据中心运维的工作结合呢？数人云更多是从自动化的操作切入的。因为在管理层面，金融企业介于合规的红线，管理流程不是在短期内能够改变的。数人云考虑的是落地，也就是说如何用容器这项新技术快速帮助到金融客户。因此，我们更多的是从操控的点落进去，因为从这个层面切入不会影响金融客户已有的管理流程。基于容器云的很多操作就会变得非常方便，像应用的快速部署、快速上线、任务的管理，以及权限资源方面配额的管理都会变的很方便，这些都属于自动化操控部分。但是只做到应用的快速上线、弹性部署这些还不够，因为生产环节还需要大量的监控，因此我们会把容器云与客户已有的监控平台进行对接，使监控、日志、报警等都沿用客户已有的流程去处理。数人云从这个点切入，帮助数据中心的运维操控变得更加的自动化，降低运维的复杂度。
最重要的一点就是不破坏，不改变上层的管理流程，这正是数人云切入的角度。但是就像上面讲的，未来如果真的要做到完全基于云、实现敏捷开发、DevOps的话，那企业的组织构架，以及管理上的调整肯定是避免不了的。我们作为容器技术厂商，更多是从技术落地的角度去考虑问题，所以我们主要落地是从自动化操控去切入。
三个场景
下来简单介绍一下容器云在金融行业落地的部分场景。 第一个场景是弹性扩容的场景，比如秒杀、红包这样的场景，它们都有弹性扩容的需求。让应用具有弹性能力，具有弹性扩张和收缩的能力会很好的提升数据中心的资源利用率。当某个业务计算量很大的时候，就可以弹性地把业务应用进行扩张，占用更多的计算资源。而当这个业务规模降下来的时候，后台的业务应用也能相应的收缩回来，把计算资源释放给其他应用用，让业务应用具有弹性、扩缩的能力，这也是应对业务容量的一种变化。
弹性扩缩用容器，用Docker来做是会非常方便的。比如通过监控网络的延迟或其他业务相关的指标对业务的接口速度进行监控。当这个业务指标发现网络延迟增加了，某个服务的网络延迟增加了，或者某个服务的请求数到了一定阈值，就开始进行自动扩展的关系性逻辑。自动扩展对于Docker来讲是非常方便的，其实就是增加很多Docker的应用实例。这里指的是web实例，每个web实例封装在Docker容器里面，需要扩张的时候用调度平台把这个容器的实例调度开，就可以迅速扩张应用的实例。同时，对于资源层面来讲，如果企业下面做了一层私有云的IaaS的管理，那么这个容器云就可以调度IaaS的接口，调度OpenStack或者VMware，生成更多的虚拟机请求更多的计算资源，然后计算资源上再把容器分配和调度过去。弹性扩容其实是很好理解的，就是调度更多的实例。
第二个场景，相对复杂一些，对应新的速度，业务应用从代码到生产，做持续集成、持续交付。复杂的地方在哪儿呢，首先不同的环境需要用Docker打通，这也是Docker非常擅长的地方。开发和测试环境相对比较容易打通，在网络上是可达的。但是测试和生产环境就比较难打通，网络上一般是不可达的，这就要求传递的东西要更加标准。因此，从测试到生产环境，传递过去最好都是Docker化的应用。 开发的流程是不变的，Docker并不能帮助到开发的效率。也就是说，以前怎么写代码，怎么做代码审查这些跟Docker的关系并不大。但是有了Docker以后，进到代码仓库之后，从代码仓库打包，就可以自动构建出新的程序。比如用Java程序构建出Jar包，然后构建镜像，这些镜像就可以从开发环境自动推到镜像仓库，再从镜像仓库到测试环境，这样两个环境就可以比较轻松地打通。然而，在镜像仓库里也会有一些镜像无法通过测试，这就需要返回通知开发人员继续进行业务迭代，做好Docker镜像，测试完全通过了以后，再保存到镜像仓库，标记这时最新的完全通过测试的业务应用镜像。在拿给运维人员做生产部署时会涉及很多的环节，中间的物理网络可能是不通的，运维人员从测试环节拿Docker镜像去生产和交付等都是待打通的环节。 还有一点，Docker是要打包应用所依赖的环境还有应用程序本身，假定Docker应用里面装的是Weblogic，运行Java写好War包程序，那么这个Weblogic也需要容器里面的基础环境，假定是个Ubuntu Linux，以及各种各样的配置文件，基于xml的配置文件。在Docker做交付的时候，如何处理War包还有配置文件有很多不同的方法。从开发测试最方便的方法，是把Docker里面所有的东西都打包进去，把这个程序和配置文件一起放进去，通过这种方法，Docker镜像就完完全全是自我依赖的，也会有麻烦的小插曲，比如程序改了一行就要重新做一个War包，重新打包一个Docker镜像；或者说配置文件更改一个地方，整个镜像也需要重新的打包。企业级IT的应用有很多各种各样的依赖，因此整个打包的流程不见得能在几秒钟内做完。在这个时候，相对恒定的部分是Ubuntu和Weblogic，这部分是偏依赖的，因此，可以把它们放在Docker容器里面作为一个基础的镜像。然后每当应用发布的时候，War包的变化最频繁，但可以将程序和镜像进行分离。这样每次上线的时候，基础镜像都保持不变，新的应用可以重用已有的Docker基础镜像，只替换War包。这样的话，仍然能够利用Docker带来的一些隔离，资源限制等轻量部署的特点。 另外是对于配置的管理，因为上面讲的配置还是放在Docker镜像里面的。配置文件一般都不大，虽然不像程序改的这么多，但是配置文件也会发生改变。那么是不是每次修改配置文件的时候，整个Docker镜像也要重新改呢？也不见得，我们可以单独对配置文件进行管理。配置文件的管理其实对于金融行业来讲是不容易的，因为环境之间是隔绝的。配置服务器把不同环境的配置都生成好，当程序运行起来以后，有两种方式，一种是拉的方式，容器启动时去配置中心拉取实时配置，无需修改代码。另外一种是推的模式，配置更新会实时推送到特定容器，需要使用SDK。拉的模式，在程序启动以后，每次更新程序都要发一次配置静态加载，配置修改程序也不会改，拉的模式相对容易实现。 再一个场景就是从新的效率方面，要提升整个数据中心运维的效率，把运维的复杂度降下去。使用容器云以后能把80%的重复性运维工作做到自动化。运维部署就不太需要人力参与了，只需要运维人员去触发，设定应用上线的时间，具体上线的逻辑都是基于容器去快速部署的。基本上只有上线新的物理服务器，或者组件虚拟机资源池的时候才需要人力，容器云底下的集群自动搭建都可以基于容器技术自动实现。CPU、内存都可以实现自动的分配和回收。还有应用的横向扩展，应用的容错自动恢复等也都可以自动实现。借此，80%的重复性的运维都会变成自动化的，这对数据中心的运维效率来说无疑是一个很大的提升。
数人云的案例
数人云基于容器搭的数据中心操作系统的简单构架，我们要做的是面向私有云或者混合云的轻量级PaaS平台。这个PaaS平台的理念非常简单，就是把各种各样的应用，基于互联网的应用也好，基于传统架构的应用也好，或者是分布式开源的一些组件、消息队列这些各种各样的组件，把它们统一抽象为容器化的应用。针对这些标准的容器化的应用，PaaS平台就可以提供标准的容器运行环境，包括应用的部署、持续集成、弹性扩容、服务发现、日志、权限，以及关于持久化、网络这方面对接。这就是标准的PaaS平台，这些都得益于容器技术将应用层进行了标准化的处理，在此基础上，所有的应用都是容器化的应用，不再区分是业务应用还是组件级应用，或是处理大数据的应用，它们都是容器的应用，PaaS平台只需把容器应用的运行时需求管理好就可以了。
PaaS平台向下对各种计算资源，包括公有云或私有云，或是物理机，进行统一管理，数人云目前更多的侧重点在私有云的场景下。通过轻量级PaaS平台，基于物理机和虚拟机就都有了可以统一管理的平台，从应用的快速发布、到整个资源利用率的提高，最后到大规模的部署，都是一体化的流程，数人云的PaaS平台全部都可以支持。
举一个秒杀的例子，这是我们的一个客户，活动晚上十点左右秒杀，因为担心白天人太多。这的确是客户的困境，因为他们的IT构架很难适应弹性扩张，因此被迫在晚上做秒杀业务。之前我们也做过百万并发的压测，每秒钟有一百万个请求过来。压力上来以后我们就开始做弹性扩张，对于这个来说，Docker容器是非常方便的，另外还有监控触发自动扩容。 第二个例子是同城灾备，金融行业出于合规性的要求，要做两地三中心，这并不是那么容易实现的。基于容器云就可以实现两地三中心，容器的管理节点是跨网络的，高可用的，它们几个互为备份，下面是不同的集群，可能是生产集群、备份集群、开发集群等等各种各样的集群，这些跨物理节点的集群都通过数人云节点去管理。当某一个集群宕了，上面的很多应用就可以自动且快速地迁移过来，比如说生产宕了马上备用就切进来了，基于容器这些都可以很容易的实现。
再一个简单的小例子，刚才提到的，大数据的系统如果容器化了以后，就不需要再区分是大数据的应用还是其他业务应用，一律都是容器化的应用。所以大数据的系统跑在容器里面，封装后全部都是容器化的，包括Kafka，Zookeeper、Redis。容器化了以后，PaaS平台并不区分这个应用是什么样的，全是基于容器的，只需把容器管理好，也就是说，容器需要CPU就给CPU，需要内存就分配内存，需要网络就分配网络，需要隔离PaaS平台就帮它做隔离，这样的话，整个大数据平台就能够很方便地维护。应用系统、数据系统都可以统一通过一个PaaS平台去运维。
标签：
原文地址：http://www.cnblogs.com/zhaowmm/p/5580470.html
