基于OpenShift实现银行核心业务系统容器化

  在银行 4.0 的蓝图中，金融服务无处不在，这意味着银行的服务模式必须能够跟得上变化。我们可以看到中国的货币电子化速度远超想象，现在生活中的每一笔现金交易几乎都转变成了电子交易，反映到银行的核心系统里，交易量和交易频度在发生数量级递增。
  另一方面现代银行关注客户体验，以数据驱动，注重风险控制，这些新的发展方向，都要依托在更大规模数据处理的基础上。原本通过科技进步所节省下的软硬件成本，已经难以抵消这种增长速度，在这种情况下银行需要继续提升 IT 进步的速度，降低业务支持成本。
  在业务创新能力方面，很多的新技术新方法，像微服务、 DevOps 、人工智能经过大量的项目验证，能够帮助金融行业实现更好的业务敏捷性。已经有越来越多的银行开始考虑进行核心业务系统的现代化再造。

  银行的核心业务系统经过从分散到集中，主机到小机，小机到开放的发展。核心系统在不断进行瘦身和剥离，这既是一个过程，也是现存的一个状态，很多银行目前都处于多种结构并存的状况，是因为这一演进过程不仅是设备和软件的替换，是从开发、运维到制度保障和知识积累的全体系更换，而且有些问题依然需要依靠未来的技术进步去解决。

  我们就拿当下的分布式和云时代来说，新技术让应用开发更敏捷，跨企业的应用对接变得更容易，但是技术复杂度也在提升。基于微服务体系的应用需要用到消息队列、缓存、事务管理器、服务管理、监控架构，需要部署大量的组件来支持服务的运行。然后来自于不同软件公司的的微服务开发体系使用的基础模块，甚至是开发方式又都不尽相同。如果不能简化或者解决这一问题，那么在享受微服务带来的业务敏捷性的同时，银行的运维难度将大幅度提升，系统规模越大，这一问题就越明显。

  现在也有一种趋势，就是微服务的架构开始从应用内的微观架构，逐步被提升为全企业层面的架构，在企业层面统一解决微服务的发现、访问和监控，又不会限制你用哪种技术或者语言来实现微服务。对于核心系统来说保持技术架构的开放性，是保证核心系统能持续进步的基础。

  我们可以看到构建一个现代的核心系统，依然是需要多厂商参与，红帽已经和全球很多专业的核心系统厂商合作，一同实现银行核心系统的现代化转型。这里 Temenos, 塔塔 ,Infosys,IBM, 等众多公司，围绕着核心银行、支付系统、财富管理等一系列银行关键业务系统展开新技术合作。红帽在这里提供一个底层平台，在整个基础设施层面解决运行态的问题。

  我们以 Temenos 的开放式核心银行系统为例，在 T24 推出的容器化架构中，有多个 Openshift 集群，分别为核心系统模块、 API 接口、微服务化的服务实现提供弹性的运行环境。在 T24 的架构中，既可以使用传统的中间件技术，更可以使用基于容器化的中间件实现核心系统不同模块之间的集成。完全基于容器化中间件的好处是，随着核心系统处理能力的动态扩缩容，模块间的连接能力也可以同步的动态调整，真正做到全弹性的业务处理能力。

  核心系统升级改造是高风险项目，银行都要倾其全力。以往的建设方式，都是需要先确定一个技术体系，然后以 5 到 10 年的周期，在这个体系下进行项目建设。是一个波浪式的建设过程。在新技术运用的初期， IT 能力得到极大运用，但是随新需求的不断涌现，终有一天业务的需求会超出当前技术架构的承载能力，当前 IT 架构开始制约业务的发展，这个时候就需要开启下一个架构迭代的轮回。

  但是我们看到随着微服务开发方式的普及，系统的边界越来越模糊，技术变化的周期也变得越来越短，一方面很难再去筹备一个边界清晰的大型迭代式项目，另一方面快速的技术替换也产生了持续而且不可忽略的成本。这个时候就需要重新审视这种断代式的 IT 建设模式。

  容器技术的出现，带来了一个颠覆性的变化。我们知道，在传统模式下构建应用系统，我们想要得到一个应用环境，需要经历安装操作系统，安装系统软件，部署应用，配置环境等一些列步骤。虽然通过虚拟机能够简化构建过程，但是依然无法实现快速更换操作系统，更换中间件，或者成套部署 UAT 环境等工作。

  但是随着容器技术的出现，这一点就发生了很大变化。容器技术彻底改变了应用的运行形态，将重复的系统安装过程转换为一次性的镜像构建，操作系统、中间件的替换过程几乎达到了测试通过即可随时服务程度。解决了应用系统和中间件、操作系统这一类基础设施之间解偶的问题。

  再通过将 Kafka 、 Redis 等一系列中间件在 PaaS 平台上服务化，使得应用逻辑的独立性更强，基础设施架构的影响和变化变得越来越小。在这个基础之上架构连续性发展就变成有可能的事情，再配合上应用更新的蓝绿发布、灰度发布之后，运维和投产也会变得更为便捷和平滑。银行可以有更大的自主权和可能性做到在产品和技术选择上的自主可控地更换，不会长期被落后或者封闭的技术体系锁定。

  红帽在 PaaS 平台建设方面积累了非常丰富的经验，不论是从应用上云还是数据中心上云，我们已经在金融、电信、制造业针对客户的实际情况，成功帮助很多客户实现了容器平台为基础的 PaaS 环境，并逐步扩大实施的范围。从技术论证、平台搭建、应用迁移辅导，到云原生的能力构建，帮助客户有针对性的制定实施路线图，在项目中红帽协助客户解决了很多问题，有因为 IaaS 经过深度定制后出现的网络问题，有存储对接的问题，有因为应用开发不规范出现的偶发问题，红帽能够做到这一点是因为在后台有全球直接参与 K8s 开发的团队在支持产品的问题解决。

  红帽从 2011 年开始进行 OCP 产品的开发，现在已经发展到了 4.6 的版本，严格按照开源社区的节奏，每 3 个月迭代一个小版本， OCP 产品其实也不是第一天就现在的样子，这期间经理了 2 次重大的结构性调整。我们知道开源软件发展的规律是用事实标准说话，哪个技术受用户认可，使用者多，就会有更多的开发者参与这个技术的发展，也就会发展地越成熟。所以第一次调整是 OCP3 拥抱谷歌所创建的 K8s ，第二次是 OCP4 在 K8s 的基础上实现更强的扩展性，解决更复杂的应用部署问题，比如使用 operator 一键部署 Redis 集群， UAT 环境，这一部分扩展已经被提交到 CNCF ，并成为社区接受的发展方向。

  红帽作为一家以开源模式运作的企业软件公司，并不是从开源社区找一些热门软件，进行企业化包装后对外发售。红帽所提供的软件，绝大多数对应的社区软件都是由红帽工程师直接参与和主导，因为如果不这样，就无法掌握产品的核心逻辑，快速解决客户的故障。像 JBoss ， CEPH ， Ansible 等很多软件虽然最开始不是由红帽开发，但是最终红帽通过收购整合，将这些半开源或者闭源的软件转为了开源软件。以 K8s 为例，虽然发起人是谷歌，但是红帽在 K8s 下的很多功能小组，都担负着实际负责人，除了完成功能开发之外，还在积极推动 K8s 的各种接口标准化，让 K8s 能够和更多的容器运行时，云环境，网络协议能够无缝对接。

  我们这里看到的 Openshift 是红帽的 PaaS 平台产品，他不只是一个 K8s+ 容器运行时，而是在不断超越 K8s 和完善 K8s 。中间的蓝色部分是一个基于 K8s 为基础的核心，除这些 K8s 所需的基础运行组件之外，我们看到的其他部分，都是红帽的 OCP 为了面对复杂的企业应用环境提供的扩展能力。

  容器下应用的部署不只是拉起一个镜像，有着复杂的相互关系，我们看到在 PaaS 平台运行时之上，红帽一直力推 Operator 框架，可以让所有厂商简化复杂应用的部署过程，小到 Kafka ， MySQL 等部署过程，大到一个业务系统，都可以采用 Operator 框架实现和 K8s 的良好交互，最终完成各种复杂的部署要求。

  在此之上，红帽还在不断加强对于混合云上的异构 K8s 的管理，使得用户面向不同来源的 K8s 时，能够获得一致的管理体验。

  除此之外 OCP 产品中直接内置了与开发者息息相关的各种工具，以及大量中间件的支持，多种微服务所需的基础平台， Open JDK ， Quarkus ， ServiceMesh ， Serverless ，以及包括更多的传统中间件，分布式集成、流程、规则。这些中间件也不只是简单部署到 K8s 环境中，都针对容器环境进行了相应的集成和扩展，更轻量级的启动过程、日志、监控的集成，服务的自动化发布。

  对于银行的核心系统来说，因为由来已久，所以有从主机、小机、 400 、到 X86 等众多架构，以及未来的 ARM ， RISC 甚至完全自主研发的新指令集架构。但是随着技术进步，也许是技术轮回，每一次的建设过程都要推到重来，既不经济也不现实。如果能够将这些架构环境平滑整合起来，实现不同架构共存情况下，自主性替换，或者能够减少用户在不同基础设施上的搬迁成本，这对于实现架构的连续性发展将会起到非常重要的作用。

  容器的目标就是要像集装箱货轮那样，实现标准化的承载能力。但是这一目标要比 Java 语言当年提出的一次编译随处运行更为困难。这需要非常强的适配能力，红帽的 OpenShift 是目前能够横跨基础设施种类最多的容器平台，从主机、小机、 X86 、 ARM 到多种公有云，还且提供 AWS 、 Azure 等公有云上由红帽进行的容器代运维的服务。这对于确保银行核心系统的技术独立性和决策独立性至关重要。 OpenShift 的一个核心价值就是帮助企业实现跨各种技术设施的部署。

Openshift 在核心系统的建设中还可以起到如下的关键作用

● 提供多样性的开发技术，不只是基于 spring boot 的微服务， Python ， nodejs ， vertX ，提供秒级 Java 启动能力的 Quarkus ，都包含在 Openshift 内，并提供服务支持
● 核心系统生命周期长，需要不断地添砖加瓦，保证核心系统架构和技术的开放性，就变得非常重要。 OCP 本身全部采用开源技术，并且主导和参与 K8s 的核心工作组，紧紧跟随并推动技术标准。
● 一个 PaaS 平台本身集成了几十种开源组项目，如何确保这些组件之间的兼容性是一项艰巨的任务， OCP 持续建立了上千个测试案例用于平台稳定性的验证
● 红帽的 OCP 提供了企业级的应用中心，可以帮助企业构建基于容器生态的应用环境，同时在公有云上提供了公有云、私有云下一键部署的企业应用市场
● 为客户提供长周期支持，便利的升级和迁移工具支持
● 对技术平台未来发展的可预见性也非常重要，以便金融企业能够提前做出计划。在这一方面企业级的产品有提前规划的明确的产品生命周期。

  核心系统拆分时面临的一个最大困难就是业务逻辑复杂，功能间的交互次数多，如果微服务化拆分得非常细，会产生太多的调用开销，这种调用不是几次而是几十甚至上百次，从而导致交易处理的时间过长，并拉低了系统的整体处理能力。构建在 LinuxOne 的容器环境，可以通过内存虚拟网络的技术，极大减少核心系统服务交互的外部网络的延迟，并且因为拥有 240 万个容器的承载能力，可以承载几乎核心系统的所有处理模块，为容器化后的核心系统提供最低的处理延时。

  除此之外在 LinuxOne 上还可以提供更好的安全性隔离，避免在一个大型环境上因为部分容器的故障而出现雪崩效应。

  虽然 Openshift 在进入 4.x 之后，已经从网络、存储、可扩展性等很多方面发生了质的飞跃，但是还远远没有发展到终点，未来在云原生方面还会为大家带来更多的新特性，大家可以持续关注 https://www.redhat.com/en/technologies/cloud-computing/openshift 。