容器技术在金融业落地的困难及经验

Posted 2021-05-02 twt企业IT社区

来源：《金融电子化》

2016 年1~2 月Docker hub 的下载量达到4 亿，意味着容器技术在互联网领域逐步被接纳。国外有些金融机构比较激进，如高盛计划在未来1 年把90% 的计算全部放到容器平台，国内金融机构也开始了调研试点工作。

容器技术在金融业的应用场景

容器是一种轻量级的虚拟化技术，也是一种IT 应用打包技术，它为金融业应用的开发部署带来了新的想象空间。容器具有可以提高计算密度，进行更精细的资源控制与隔离，部署时间更短，简化持续集成、测试与发布，易于环境标准化与版本控制等优点。其在金融业的应用场景有两个方面。

1. 基于容器技术，实现轻量级的PaaS 方案。现在很多金融企业都构建了自己的IaaS 平台，而随着云计算技术本身的发展和业务部门对云计算平台的要求越来越深入，对PaaS 的要求和呼声日渐提高，容器技术是构建高效和简单易用的PaaS 平台的很好选择。

2. 在开发测试环境实现一键部署。金融行业与互联网的结合产生的创新业务的特点要求能实现敏捷开发、快速迭代、频繁换版推送新功能、交易量不定期出现浪涌现象，这与容器技术的特性相吻合，引入容器技术也就水到渠成。

容器落地面临的困难和经验

1. 技术使用将面临困难。容器技术横跨了应用架构和基础架构两个方面，为了发挥其优点，一般将它与微服务相结合。如果把传统的单一应用整体通过容器打包，则其敏捷开发、快速迭代和灰度发布等功能就无法享受，而微服务是一种“去中心化”的架构，与传统的ESB 企业服务总线这种应用架构是不同的。同时容器技术是一种虚拟化技术，比原有的传统虚拟化技术颗粒度更细，因此它对应用架构和基础架构层面都会产生或多或少的侵入性改变。故此，容器技术落地会面临来自开发部门和基础架构部门的双重质疑。而且，容器技术一般与敏捷开发、持续集成、一键部署、灰度发布等联系在一起，与之对应有新的开发、测试、上线流程，这些都需要从IT 领导层面来推动，自底向上很难行得通。

2. 技术选型将面临困难。在明确采用容器技术后，如何选型也很复杂。我行从2015 年开始调研测试，就这个问题花费了近半年时间。

在构建PaaS 平台时，目前有两种主流架构可选择，即商用架构（如Cloud Foundry，简称CF）与开源架构（其代表是Docker 容器及其生态圈）。CF 是市面上较为成熟的PaaS 平台，利用的容器是Garden，对高可用、动态扩展、性能、负载均衡、日志、监控等底层环节均已经实现，是一套完整的解决方案，用户可以直接使用，但它是一个较重量级产品。而开源Docker 架构，结合其生态圈，整个解决方案需要用户自己去搭建，是一种轻量级PaaS 方案。

这两种架构各有优缺点，需要根据金融机构自身的要求和特点来选取。上海银行从自身的战略、组织架构、技术、风险等多个方面考虑，选择了基于Docker 的生态圈技术。

对于Docker 生态圈技术的选择同样面临很多种选择，其中最主要是Docker 容器集群管理系统的选择，主流的包括Swarm、Mesos 与Kubernetes三种。Swarm 是最简单的调度器，它拥有易于理解的策略和过滤器，但它不能处理节点的失败问题；Mesos 是一个分布式系统内核，它专注于资源的管理和任务调度，并不是针对容器管理的，Mesos上所有的应用部署都需要专门的框架支撑，支持Docker 必须安装Marathon，如果Mesos 要实现生产应用二次开发，其成本较高；Kubernetes 专注于容器的集群管理，以服务的角度定义容器的应用，产生微服务，为调度器和编排工具提供了更加丰富的功能，更适合功能扩展，同时可以解决有状态应用的容器化处理，二次开发成本高。结合我行自身情况，最终选择了基于Kubernetes 的Docker 生态圈技术。

选型确定后，在规划容器技术生态环境时，也需要注意网络架构、监控、有状态应用的容器化等方面的问题。

3. 在网络方案面临的问题。容器网络的主要问题是如何进行跨主机间的网络通信与互联。另外，选择不同的网络方案，会给后续漏洞扫描带来困难。

从网络模型而言，容器的跨主机网络解决方案包括：Docker 公司主推的网络模型CNM（Container NetworkModel）， 和Google 主推的网络模型CNI（ ContainerNetwork Interface）。目前支持CNI 模型的网络实现多于支持CNM 的网络实现，有的同时兼容CNI 和CNM。

4. 在监控方面面临的问题。传统的监控平台通常是以主机、操作系统为单元进行监控，比较典型的方式是将一个agent 部署在被监控对象之上。而应用容器化后，这种传统方式不再适用。对于微服务和容器化场景而言，监控工具应当具备提供应用程序级别的可见性以及每个容器的资源指标。容器高频率变化的特性对监控会造成很大挑战，监控界面上的对象变化会非常快，同时，微服务带来的应用生态关联着

更多的容器，这些都对监控提出新要求。

由于容器可以动态地创建和消亡，单个容器的监控和日志较难追溯。较好的解决方法是实时采集容器性能数据，将监控数据和日志送到日志存储服务器，进行统一保存。通过大数据技术，对历史数据进行分析，提供汇总、报表以及预测等功能，从而实现对容器的监控。

5. 容器化有状态应用面临的问题。在Docker 流行的最初阶段，通常业内认为其只适合运行无状态应用。但是随着技术发展，越来越多的有状态应用也被迁移到容器中运行。通常有状态应用的容器化可以考虑以下一些措施。进行无状态化改造，例如对于一些Web 应用，可以通过简单改造，诸如将Session 信息由内存迁移到外部存储中实现应用的无状态化。

利用容器技术对于有状态应用的支持，例如Docker中提供了数据卷volume 的概念，通过各种不同的volumeplugin，可以将容器内部的一些有状态的数据存储到容器外部的本地存储、共享存储或者分布式存储之上，从而实现对于数据的持久化存储，kubernetes 1.3 中也引入了pet set 的概念，用于支持有状态应用的容器化。

6. 组织架构和管理将面临问题。一般金融机构的信息技术部会分为一部多中心。利用容器技术搭建PaaS 平台后，将给开发、测试、运维带来一系列变化，而传统的开发、运维还是存在的，这就要求信息技术部具备双模式IT 的能力。

容器技术与微服务结合后，这种新的开发运维模式对应了企业创新发展需要具备的敏捷和快速响应的能力，同时要求IT 部门为此模式建立一套独立于传统模式的新流程。这套新流程在开始运行时，管理部门会因为频繁变更，对其稳定性、安全性等产生疑虑，而这套新流程也会在实践中不断优化。

开发中心面临的主要问题是容器技术出现的历史较短，且技术本身在发展变化中，故此对整个容器技术具有全面了解并且具有技术前瞻性和敏感度的高级技术人员数量有限。另外，如何把传统的单一应用拆分为微服务也需要慢慢实践。因此，在试点时，可能需要引入一些专业厂商，边实践边学习。

测试中心需要学习自动化测试及镜像构建，测试与交付方式会有一定改变，应该能很快适应。

数据中心和运维支持部门需要负责管理各种基础镜像，由从前的大量物理机管理转换成少量物理机与大量容器镜像管理；同时，需要掌握容器集群的运维管理、高可用性管理、性能管理、弹性伸缩、监控告警、资源调度等，这些都是很大的挑战。

容器技术在落地过程中，还会碰到一些其他问题或挑战，如容器的动态资源伸缩，并需要让服务的消费端感知并访问到新扩容容器，即涉及服务注册、服务发现问题；容器化后的应用可能给周边关联应用带来交易量的冲击问题等。总的来说，创新项目有一定的失败比率，可能选择的产品和将来技术的发展也有所偏差，但实践所带来的经验和跟上新技术的步伐将在未来体现其价值。

长按下图二维码关注