数人云：容器落地金融云，解决传统金融行业难题

aizixun8

基础IT架构复杂是传统金融的现状。如何快速响应用户需求，加快新业务上线，缩短产品迭代周期？在容器落地金融云的两年实践中，树人云已经落地核心金融业务技术，J2EE、中间件容器制作标准已经在证券交易所、股份制银行扎根。服务编排、服务发现、持续集成、大数据容器化、高性能容器环境等方面为行业真正构建动态灵活的金融IT提供了参考实施标准。以下为树人云创始人兼CEO王璞在2016@容器技术大会·上海站发表主题演讲实录：

困扰金融业的三大问题

首先，我们来看三个问题。这三个问题不仅困扰着金融行业，很多传统行业的企业也面临着这些挑战。

首先，新应用的上线速度从几个月缩短到几天。如何快速响应用户需求？新应用的推出需要高速。在中国，互联网行业发展非常迅速，互联网给传统行业带来了巨大的冲击和冲击。很多传统行业的业务也需要快速上线，这对他们现有的IT架构提出了很高的要求。二是新技术层出不穷。如何标准化实施应用交付和运维？这个问题也很典型，很多传统行业的企业都遇到过。新技术应该如何选择、实施和交付？最后，随着抢购、红包等高并发应用的增长，如何应对弹性应用的突然增长？闪购、红包等高并发业务是很有互联网特色的。金融机构等传统企业该如何应对？

这三个问题反映出的一个现象是传统行业企业的经营形态发生了变化。众所周知，金融行业为个人用户提供了大量的服务。 2C场景与互联网的结合是不可逆转的趋势。正是2C服务的互联网化、线上化导致了金融业业务形态的变化。如今，金融行业的很多业务都具有互联网业务和互联网场景的特征，这就需要金融行业结合互联网场景来解决新的业务问题。同时，信息技术安全可控的需求也给金融机构的IT架构带来了新的挑战。

金融行业IT现状

第一个和其他行业有很大不同，就是合规是红线，零事故是要求。银监会、保监会、证监会对于金融行业有很多要求，很多规定都是不能触碰的红线。金融行业对稳定性的要求非常高。

其次，互联网场景业务面临高并发压力。这也是金融机构在传统业务中从未面临过的挑战。传统业务的特点是峰值稳定。白天工作时间达到一定峰值，晚上又回落到一定峰值。第二天的高峰与前一天的高峰非常接近，而互联网场景业务是突发性的、不可预测的。

第三，现有应用的快速部署难以实现，升级过程缓慢。这也是由金融行业现有的业务特点决定的。由于稳定性至关重要，这就需要全面的测试、全方位的集成等，从而拖慢了上线的速度。金融行业通过降低业务上线速度来保证稳定，这与互联网公司的做法恰恰相反。

第四，多个环境相互隔离，测试环境搭建极其耗时。金融行业的IT环境相互隔离。例如，一家银行至少有开发、测试、生产三个环境，而且它们之间基本是物理隔离的。环境的物理隔离使得测试环境难以搭建，生产过程难以重现。我以前在谷歌工作过。 只有一个生产环境，开发、测试、生产全部混合在一个大型数据中心。以为代表的互联网公司的开发、测试、生产环境并不是物理隔离的。三种环境混合构建。这样的话，测试和重现整个生产环境就变得非常方便。但由于合规要求，金融行业无法做到这一点。

第五，大版本升级不可回滚。这与之前提到的环境相互隔离有关。因为环境非常复杂，金融机构很难回滚，因为每次上线都会修改现有的环境。回滚需要撤销之前的修改，因此回滚在金融行业也很难实现。

第六，设备异构，硬件资源利用率极低。最后一点可谓是金融业的历史包袱。金融机构中存在多种异构设备。十年前，许多金融机构使用了大量的大型机和小型机，这些设备至今仍在使用。另外，这些设备的资源利用率不是很高。这是因为传统业务不具有突发性特点，而且很有规律性。例如，白天有高峰，晚上有低谷。还可以利用晚上的时间来跑各批次的业务。另外，金融行业很多业务都与硬件绑定，很多业务应用是静态部署的，每个业务都有特定的硬件支撑。谷歌的情况并非如此。  不会在特定服务器上安装特定应用程序。对于谷歌这样规模的数据中心来说，业务应用程序和服务器的强绑定太难以维护。谷歌拥有超过两百万台服务器。如果业务应用必须与服务器强绑定，那么运维人员上线时就必须记住每台服务器上运行的是什么应用。这显然是不可能的。但金融机构的数据中心没有那么大，因此可以实现业务应用与硬件的强绑定。但强绑定意味着资源利用率不高，因为业务不可能24小时都忙，计算资源闲置时也无法充分利用。

以上是对金融行业IT现状的一些介绍。不能说是全面的。这是树人云接触过的金融客户的表现，尤其是与互联网公司有很大不同的地方。

金融行业IT发展的新需求

这里从新能力、新速度、新效率三个方面，总结了金融行业IT发展的一些新需求。

首先是新增产能，指的是业务的产能。金融业业务规模发生较大变化。红包、闪购等业务需要即时横向扩展能力。金融行业需要二级横向扩展能力，应对抢红包等突发流量。同时，金融行业还需要屏蔽底层异构性，实现混合云的无缝部署。

另一个新的速度点，互联网的快速业务迭代对传统行业产生了很大的影响，传统行业也在不断提高业务迭代速度。在保证稳定性的前提下，金融行业很难像互联网公司那样每个月、每周迭代新版本。因此，金融行业需要实现无人化操作，从代码到线上环境的持续集成，将上线时间缩短到小时级。金融机构需要灵活提供完整的测试和开发环境，通过灰度发布和A/B测试降低快速发布带来的风险。

另一个是新效率。金融行业需要将传统物理机的资源利用率提高2-3倍，底层实现小规模错误的自动容错，同时有效管理不同基础设施上的多个集群，使其不被影响。受业务规模扩张影响。

金融行业对IT的期望

这三点既是金融行业IT发展的挑战，也是需求。这是我们对金融行业IT期望的简要总结。前面提到，金融行业的业务发生了很大的变化，2C业务越来越互联网化。因此，支持2C相关互联网场景的业务需要尽可能的融合。也就是说，从需求的提出，到开发、测试、发布上线，再到后续的运维、监控等，所有流程都要尽可能一体化。使用一个过程。

统一的流程可以顺畅整个应用生命周期，这也是技术带来的巨大便利。它屏蔽了环境的异构性，使得开发编写的程序也可以在测试中运行，通过测试的程序也可以在生产环境中使用。这样，集成、流畅的流程贯穿于应用程序的整个生命周期。

这里提出一两个具体的需求，比如测试环境中如何快速搭建基于容器技术的各种测试环境；测试时如何快速生成基于容器技术的组件，以及测试后如何快速回收。这些仍然是期待，也确实是一个大蓝图。现阶段，金融行业还无法实现如此顺利的流程，但整个金融行业都在朝这个方向努力，开发、测试和运维部门都在积极拥抱技术。 ，拥抱容器技术升级其IT架构。

容器技术可以为金融行业打造流畅、集成的IT系统。同时，也会给现有的IT架构带来很多变化。我们来看看容器是如何对应金融机构现有的架构的。

类比一下，很多金融行业客户现有的企业级IT架构大多基于Java，就是右边的架构。最底层是资源层。过去，右侧都是以IBM、HP等高端硬件为主，比如大型机、小型机。左边，采用云架构之后，更多的服务器是面向X86、基于PC的服务器，基于X86进行虚拟化或者使用私有云或公有云服务。这是资源层。上面对应的是中间件层。此前，金融行业大量使用基于Java的中间件，例如.中间件必须提供标准的Java运行环境，使用J2EE等开发的Jar包将运行在中间件上。尤其是Java中间件，它包含并提供了标准的Java程序运行环境。对应于云，基于容器技术的数据中心操作系统，也就是云计算的PaaS平台，是云时代的中间件。因此，必须提供标准的应用程序运行环境。这些应用程序大多数现在都是容器化应用程序。中间件层应提供标准的运行环境。以前的Java、Java中间件等Java中间件应该为Java程序提供标准的运行环境，而左边的PaaS平台应该为容器应用程序提供标准的运行环境。下一个层次是业务封装和业务应用程序开发。传统的企业级IT使用Java和J2EE，但现在大家更多地使用容器进行封装​​。

容器并不是一种简单的编程语言，而更多的是一种应用程序的封装方式。容器中可以有各种应用程序，例如Java、C++或PHP。为了封装应用程序，J2EE将其封装成Jar包。云时代，大家都用封装，把它变成容器。业务封装的下一个层次是业务架构。传统的企业级IT大多采用SOA架构。云计算时代，使用了容器技术，大家开始向微服务架构过渡。微服务和SOA的架构本质上是相同的。首先，SOA架构是面向服务的，微服务也是面向服务的，只不过微服务在服务方面变得更加颗粒化。微服务对每个服务分别进行开发、维护和上线。这与传统的SOA不同。 SOA将开发层面的不同业务逻辑抽象成不同的服务，然后将不同的服务分配给不同的团队进行开发，最后整体上线。微服务即使在启动时也是碎片化的。不同的微服务执行自己的运维。这是业务架构层面。最上层是开发和运维层面的组织结构。传统企业的开发和运维是分离的。云时代的开发和运维必须实现持续集成。事实上，持续集成，或者更俗称敏捷开发，是开发和运维最根本的融合，其中涉及到组织架构的诸多调整。这涉及到人员和组织的调整，与IT架构的调整不同，是非常复杂的变化。

基于云计算重塑新一代企业级IT，不仅是技术的变革，更是组织架构的变革。这会包括开发和运维的协作、多个部门之间的整合、职能划分的变化等等。在谷歌，大概有两万左右的开发人员，而运维人员只有一两千人，这是一个非常大的问题。少数。然而谷歌的运维人员管理着大量的服务器，数百万台服务器全部由运维管理。 的运维部门做的事情和金融行业的运维人员不一样。 的运维人员更多的是做资源规划和开发流程规范。 的运维将很多传统行业的运维任务委托给了开发。比如业务上线的时候，的运维人员就不关心开发了。

监视、管理、控制

敏捷开发绝对不是一个正式的东西，它会产生深刻的组织结构和职能变化。本PPT介绍了如何从传统企业级IT角度理解云化IT架构。它包含三个部分：监控部分、管理部分和控制部分。多个模块通过CMDB配置管理数据库连接。这个图对于传统企业级IT行业的人来说还是比较容易理解的。

系统的集中监控有多个层面，包括机房设备的监控、拓扑监控等。自动化操作平台包括任务上线、权限管理等。下面是对机房、网络和网络的不同操作。其他系统。这两个模块对于很多金融行业数据中心部门的同事来说都不会陌生。他们日常的工作就在这两部分里面。监控和自动化操作称为控制，上面是管理部分。管理部分更多的是流程，比如如何处理数据中心运营管理和调度的问题，如何处理变更，如何处理发布，如何管理配置等。管理是整个流程的延伸部分。数据中心。

那么，容器云如何与现有数据中心运维工作融合呢？树人云更注重自动化运营。因为在管理层面，金融公司处于合规红线，管理流程短期内无法改变。树人云正在思考实施，即如何利用容器新技术快速帮助金融客户。所以我们更关注控制点，因为从这个层面开始不会影响金融客户现有的管理流程。基于容器云的很多操作都会变得非常便捷，比如应用的快速部署、快速上线、任务管理、权限资源的配额管理等。这些都是自动化控制。然而，仅仅快速上线、灵活部署应用还不够，因为生产过程还需要大量的监控。因此，我们将容器云与客户现有的监控平台打通，这样监控、日志、报警等都可以被客户使用。处理现有流程。树人云从这一点出发，帮助数据中心的运维控制变得更加自动化，降低运维的复杂度。

最重要的一点是不要破坏或改变上层管理流程。这正是树人云的用武之地。但正如前面提到的，如果我们未来真的想要完全云化、实现敏捷开发，公司组织架构和管理的调整肯定是不可避免的。作为容器技术厂商，我们更多的是从技术实现的角度来考虑问题，所以我们的实现主要是从自动化控制的角度出发。

三个场景

我们简单介绍一下容器云在金融行业落地的一些场景。

第一个场景是弹性扩容场景，比如秒杀、红包等，都需要弹性扩容。让应用具有弹性，能够弹性伸缩，将大大提高数据中心的资源利用率。当某项业务需要大量计算时，可以灵活扩展业务应用，占用更多的计算资源。当业务规模缩小时，后端业务应用也可以相应收缩，为其他应用释放计算资源，使业务应用具有弹性和可扩展性。这也是应对业务能力变化的一种方式。 。

使用容器进行弹性伸缩非常方便。例如，通过监控网络延迟或其他业务相关指标来监控服务接口速度。当这个业务指标发现网络延迟增加、某个服务的网络延迟增加、或者某个服务的请求数量达到某个阈值时，就会开始自动扩容的关系逻辑。自动扩容对于用户来说非常方便。事实上，这意味着添加许多应用程序实例。这是指 Web 实例。每个 Web 实例都封装在一个容器中。当需要扩容时，通过调度平台调度容器的实例，快速扩容应用实例。同时，在资源层面，如果企业管理一层私有云IaaS，那么容器云就可以调度IaaS接口，调度或者生成更多的虚拟机来请求更多的计算资源，进而在计算资源方面，然后分配和调度容器。弹性扩容其实很容易理解，就是调度更多的实例。

第二种场景相对复杂，对应新的速度。业务应用程序经历从代码到生产的持续集成和持续交付。复杂性在哪里？首先需要打通不同的环境，这也是它非常擅长的。开发和测试环境比较容易打通，并且可以通过网络访问。但测试和生产环境连接起来比较困难，网络普遍不通，这就要求交付的东西必须更加标准化。因此，最好将应用程序从测试环境转移到生产环境。

开发流程不变，无助于开发效率。也就是说，过去如何写代码，如何做代码审查，关系不大。但有了它，进入代码仓库，从代码仓库打包出来后，就可以自动构建一个新的程序了。例如，使用Java程序构建Jar包，然后构建镜像。这些镜像可以自动从开发环境推送到镜像仓库，再从镜像仓库推送到测试环境，这样两个环境就可以比较方便地连接起来。不过镜像仓库中也会有一些镜像没有通过测试。这就需要返回通知开发人员继续业务迭代，制作镜像。测试完全通过后，会被保存到镜像仓库中，并标记为最新的完全通过的。已测试的业务应用程序图像。带到运维人员进行生产部署时涉及到的环节很多。中间的物理网络可能被阻塞。运维人员把镜像从测试阶段到生产交付。这些都是需要清理的环节。

还有一点就是将应用程序所依赖的环境和应用程序本身进行封装。假设安装了应用程序，并且通过运行Java编写了War包程序，那么这也需要容器内的基础环境，假设是Linux，以及各种配置文件，基于xml的配置文件。交付时处理 War 包和配置文件的方式有很多种。开发和测试最方便的方式就是把里面的东西都打包起来，把程序和配置文件放在一起。这样一来，形象就会完全自立，就会出现麻烦的插曲。例如，程序中的一行代码被更改，则必须创建新的War包并重新打包镜像；或者如果配置文件发生更改，则必须重新打包整个映像。企业级IT应用程序有很多各种依赖项，因此整个打包过程可能不会在几秒钟内完成。此时，相对恒定的部分是且部分相关的。因此，它们可以作为基础镜像放置在容器中。那么每当应用发布的时候，War包变化最频繁，但是程序和镜像是可以分离的。这样每次上线时基础镜像都保持不变，新的应用可以复用现有的基础镜像，只需要替换War包即可。在这种情况下，您仍然可以利用它带来的一些隔离、资源限制和其他轻量级部署特性。

另外就是配置的管理，因为上面提到的配置还是放在镜像里的。配置文件一般不会很大。虽然它们没有像程序那样改变那么多，但是配置文件也会改变。那么每次修改配置文件，是不是都要重新修改整个镜像呢？不一定，我们可以单独管理配置文件。对于金融行业来说，配置文件的管理其实并不容易，因为环境是隔离的。配置服务器为不同的环境生成配置。程序运行后有两种方式。一种是拉法。容器启动时，就去配置中心拉取实时配置，无需修改代码。另一种是推送模式，配置更新实时推送到特定容器，需要使用SDK。在pull模式下，程序启动后，每次更新程序时都必须静态加载配置，配置修改程序不会发生变化。拉动模式比较容易实现。

另一种场景是从新的效率角度提升整个数据中心运维的效率，降低运维的复杂度。使用容器云后，80%的重复性运维工作可以自动化。运维部署无需人工参与。只需要运维人员触发并设置应用上线时间即可。具体的线上逻辑是基于容器来进行快速部署的。基本上只有当新的物理服务器或组件虚拟机资源池上线时才需要人力。基于容器技术可以自动实现容器云下的自动化集群构建。 CPU和内存都可以自动分配和回收。还可以自动实现应用的横向扩展和应用的自动容错恢复。通过此，80%的重复性运维将变得自动化，这对于数据中心的运维效率来说无疑是一个很大的提升。

树人云案

树人云是基于容器化数据中心操作系统的简单架构。我们要做的是一个轻量级的私有云或者混合云的PaaS平台。这个PaaS平台的概念非常简单。就是集成各种应用，无论是基于互联网的应用、基于传统架构的应用，还是分布式开源组件、消息队列等各种组件。 ，将它们抽象为容器化应用程序。对于这些标准的容器化应用，PaaS平台可以提供标准的容器运行环境，包括应用部署、持续集成、弹性扩展、服务发现、日志、权限以及持久化和网络连接等。这是标准的PaaS平台，受益于标准化应用层的容器技术。在此基础上，所有应用程序都是容器化应用程序，不再区分业务应用程序或组件级应用程序，或者它们是处理大数据的应用程序。它们都是容器应用程序。 PaaS平台只需要管理容器应用程序的运行时需求。

PaaS平台统一管理各种计算资源，包括公有云或私有云，或物理机。树人云目前更关注私有云场景。通过轻量级的PaaS平台，有基于物理机和虚拟机的统一管理平台。从应用的快速发布，到整体资源利用率的提升，最后到大规模部署，是一个集成的过程。 ，树人云所有PaaS平台均可支持。

举一个闪购的例子，这是我们的一位客户，他在晚上 10 点左右出售了他的活动，因为他担心白天人太多。这确实是客户的困境，因为他们的IT架构很难适应弹性扩展，所以他们被迫在晚上进行闪购。我们之前也做过百万并发压力测试，每秒有一百万个请求。压力升高后，我们开始弹性扩展。为此，容器非常方便。另外，监视触发器自动扩展。

第二个例子是城市内灾难恢复。由于合规要求，金融行业需要在两个地方进行三个中心。这并不容易实现。根据容器云，可以实现两个位置和三个中心。容器的管理节点遍布整个网络，并且高度可用。他们互相备份。以下是不同的集群，可能是生产簇，备份簇，开发簇等。各种簇，这些跨物理节点的这些簇通过几个云节点进行管理。当某个集群下降时，它上的许多应用程序都可以自动并迅速迁移。例如，如果生产下降，则可以立即切换备用。这些备用可以根据容器轻松实现。

如前所述，另一个简单的示例，如果大数据系统已化为容器，则无需区分大数据应用程序和其他业务应用程序，它们都是容器化的应用程序。因此，大数据系统在容器中运行，封装后，它们都被化为容器，包括kafka和redis。容器化后，PAAS平台无法区分它是什么样的应用程序。这全都基于容器。它只需要很好地管理容器即可。换句话说，如果容器需要CPU，则将给出CPU，如果需要内存，则将分配内存，如果需要网络，则将分配。分发网络，如果需要隔离PAAS平台，则可以为其隔离。这样，可以轻松维护整个大数据平台。应用系统和数据系统可以通过PAAS平台统一操作和维护。