小容器，大时代 ——金融行业如何迎接容器技术

文‖中国农业银行数据中心 张春 刘照乾

随着银行业中掌上银行、移动支付等基于移动互联网的金融服务迅速崛起，其业务量在银行各类服务渠道中的占比迅猛提高。但是相应的业务需求变化快和业务场景多，导致传统银行业采用的IT 基础架构及开发、运维模式逐渐暴露出不足：开发、测试和运维等环节被分割独立，导致项目投产上线周期相对较长，无法及时满足互联网时代的客户和业务需求；新产品投产和业务量不断增加，导致机房投入的服务器数量和运维成本大幅提高；生产测试环境的隔离增加了相应开发、测试和运维工作人员的工作量。特别是在应对“红包”、“秒杀”抢购等高并发特殊场景时，传统的基础架构和运维方式很难适应。
传统金融业IT 需要通过技术转型逐步建设成具有持续交付能力、高资源利用率、连续高可用、灵活伸缩的自动化体系架构。

利用容器，化解难题

在新涌现的大批先进技术中，以Docker 为代表的容器技术受到了极大关注。容器技术最显著的特点是容器中不仅包含了应用本身，还包括了应用运行所需的环境，从而能够在不同的环境中迁移并运行，做到一次构建，多次部署。另外，容器技术也是一种相对轻量级的虚拟化技术，能够做到秒级启动和停止。基于这两点主要特性，容器技术有着解决传统金融行业IT 所面临问题的先天性优势。

1. 大幅缩短交付周期。一方面，容器自身含有应用运行的环境，降低了与宿主机操作系统之间的耦合，具有可移植性，避免了构建复杂的测试环境，同时也规避了因生产和测试环境不一致导致的种种问题；另一方面，应用以容器，而非传统源代码的形式进行交付，一定程度提升了应用交付件的标准化，减少了重复工作量。因此，利用容器技术能够达到持续交付，缩短交付周期的目的。
2. 提高配置部署效率。相比虚拟机，容器能够根据需求量身定制，不必重复构建操作系统环境，提高基础环境配置部署效率并且最大化地利用服务器资源，保证安全的同时提高资源使用率，从而节约成本。
3. 运维自动化程度提高。随着容器技术及其生态圈的不断发展，容器的编排和调度技术使自动化运维和管理大规模容器集群成为可能。在应对红包、秒杀等特殊场景下能够自动进行横向的弹性伸缩，相比传统基础架构更加高效智能。同时，容器快速启动的特点能够保证当一个容器意外消亡后，通过相应的自动化技术能够快速启动另一个同样的容器，确保应用的连续性和高可用性。
   容器技术的出现为传统金融业IT 技术转型提供了一种近乎颠覆性的转型思路。而且，目前在大规模集群管理、混合云平台构建、微服务化应用以及云原生应用等场景中，容器技术也得到了广泛应用，很大程度上与金融业IT 的战略转型相契合。

应用容器，面临难点

1. 容器技术及其生态圈发展不够完善。暂时无法完全支持银行业IT 系统普遍使用的基础软件进行容器化，比如成熟的商业化数据库软件（Oracle）和中间件软件（WebSphere）等。因此，银行业将现有IT 系统大规模移植至容器架构中是不可行也不现实的。在银行业的IT 系统中要实现真正意义上的容器化还存在很大阻碍，应该充分调研和评估并结合实际情况逐步实施。
2. 容器技术本身不够成熟。目前容器技术更多是在开源技术领域进行探索，距离成为成熟的商业化产品还有一段距离，是否能够持续发展也存在不确定性。而作为把数据安全放在第一位的银行业系统，对于开源软件的安全性需要进行严格的把关和评估。
3. 为更好地适应容器技术的特性和发展，还要努力尝试和逐步推广微服务架构，实现应用架构的转型。如果在容器中继续运行传统的单体应用，只是利用了容器技术的可移植性，当对应用进行更新升级时，仍旧需要整体更换，效率相对低下。由于容器技术可以对不同的服务组件进行统一的、标准化的封装，再结合容器的编排和调度技术，可以针对性地进行应用组件的更新升级过程，减轻工作量的同时也可以逐步实现自动化运维。
4. 容器技术的应用会打破传统运维模式。在日常监控、问题排查和应急处置的过程中，应用运维人员与系统运维人员所承担的工作需要重新定义和分配，各项运维流程需要重新梳理。同时，也会对开发和运维人员的技能提出更高要求。开发人员除了需要考虑应用本身和应用运行的环境，还需要对容器进行瘦身，尽量剔除该特定应用/ 服务所不需要的运行环境以达到最大化利用资源的目的；对运维人员来说，运维模式将发生改变，特别是对系统层级的运维人员来说，容器化的过程会使原来基于虚拟机系统层面的运维向平台层级的运维转变，要求其具有更丰富的自动化管理经验。
   进行容器技术的转型必定是一个不断尝试不断变化的缓慢过程。特别是在金融行业中，由于追求安全第一的行业特殊性、缺乏专业厂商支持、自身实践经验匮乏以及适用业务场景相对稀缺等原因，目前仍处在经验积累阶段。在容器及相关技术的真正成熟完善之前，我们需要不断探索真正适合金融行业的技术方案和路线。

面对难点，主动出击

首先，面对技术难点一方面可以寻求成熟的商业解决方案，更重要的是增强团队专业素质和能力，在积极研究和探索适合金融企业开源技术的基础上，提高自主研发能力，弥补相关开源软件的安全漏洞。同时，也需要组建相关专业技术团队，根据具体需求和行内具体情况对容器及其相关的核心技术进行充分调研。
另外，在实际应用容器技术的过程中一定要脚踏实地循序渐进，更多的是要以业务应用场景为驱动，关注业务与现有容器技术的结合。在初期选择进行容器化的业务应用场景时，要充分考虑存在的风险点，可以选择全新的非核心业务场景。随着对容器技术的验证、熟悉、优化和掌握，逐渐过渡到更加适合容器化的业务场景，比如需要具有高效弹性伸缩的纪念币预售系统、需要频繁更新升级的掌上银行系统等。
容器技术的应用将大幅提高金融业IT 标准化和自动化运维水平，相应的管理和流程制度也需要逐步配合进行相应的跟进与完善。值得注意的是，容器技术的应用将会颠覆性地改变金融行业中传统的体系架构，该技术的实施和推广不能由开发、测试和运维中某个技术部门单独来推动和展开，而是需要各个部门互相配合，协同共进。

阶段推进，稳步转型

基于以上思考和准备，再结合银行业IT 自身实际，如图所示，容器技术在金融行业的应用可以分阶段式的进行。
基于数据安全和技术实现难度和复杂度的考虑，可以先尽量采用成熟的商业解决方案，将传统架构中数据库前端的应用进行容器化。所以在第一阶段中，以容器技术的典型代表Docker 为例，应用容器技术可以从以下几点着手。
★由于行业内成熟的商业中间件软件暂时不支持Docker 容器化，应用开发需要从基于成熟的商业软件开发转变为基于开源软件开发，需要选择合适的开源软件及开源工具。

★将基于开源软件的试点应用及其需要的运行环境进行整体封装至容器中，暂时不进行微服务架构应用的改造；
★ Docker 容器运行环境采用支持Docker 技术的OpenSuse Linux操作系统；
★对于大型商业数据库和专用的负载均衡设备保持传统架构，暂时不进行容器化。在第一阶段中，不仅要注重记录平时运维中遇到的问题以及经验的积累，更重要的是要同时着手进行容器自动化编排和调度管理平台的搭建。该平台尽可能多地包括其他功能，比如服务的发现和注册，容器的监控，报警通知，数据管理，以及容器和配置文件的自动化管理等。在逐步成熟和熟悉以后，进入到下一阶段的研究和探索。第二阶段的主要任务是更完整地利用容器技术并发挥相应优势，需要将第一阶段的遗留点进行相应的容器化改造。
★微服务化应用架构的转型，将单体应用逐渐进行微服务化拆分，同时探索和制定应用的模块化标准，提高相应的标准化程度。
★采用更加轻量、定制化的Kernel 级引擎作为Docker 容器的运行环境。
★结合分布式数据库的发展，将开源数据库软件容器化。
★尝试采用软件定义的负载均衡技术替换行内现有的专用负载均衡设备，进而进行相应的容器化。
★与云平台融合，构建基于容器的云平台。在该阶段中，更为重要的是检验、完善和继续丰富容器自动化编排和调度管理平台的相关功能，主要包括大规模的集群管理，网络、存储等资源的自动化管理，自动化管理过程中错误排查方法和效率等。从中可以看出，容器技术的应用和推广路线是将行内传统架构中的不同应用层逐步容器化的过程，从中间件到数据库再到负载均衡等。最终的发展结果是将不同层面的应用进行容器化后，最终封装在一个大的容器中，再由容器编排和调度管理平台进行多维度的调度、管理和监控等。
值得一提的是，容器与虚拟机最大的区别在于容器技术的出现降低了应用与操作系统之间的耦合，使得容器天生具有更好的可移植性，这也是容器重要的价值和优势之一。相信未来在保证金融行业数据安全和一致性的前提下，容器能够轻松移植到云端或者构建基于容器的云平台，这也为银行业两地三中心建设、云平台构建和自动化运维等战略性发展提供了更多的思路。

在“互联网+”的时代背景下，传统金融机构已经感受到来自内外部的新需求，自身IT 体系架构的不足也逐渐显现。在充分测试和考量新兴互联网技术的基础上，我们也应该尝试去拥抱它们，一方面克服自身体系架构的不足，降低成本，另一方面努力适应外部快速变化的需求。不过需要注意的是变革和创新是在保证安全和稳定的前提下，而且要以业务场景为驱动，在追求新兴技术和稳定安全之间进行权衡。

《金融电子化》