第一届“金融现代化 IT 基础架构转型论坛（FinTech Infrastructure Wave 2022）”已于 9 月 21 日至 23 日成功举办。该论坛由中国信息通信研究院云计算与大数据研究所、《中国金融电脑》杂志社主办，北京志凌海纳科技有限公司（SmartX）与北京鲲鹏联合创新中心协办，分为三大专场，覆盖银行、保险、证券、基金、期货、信托六大金融细分行业；带来 15+ 实践干货分享，涵盖多云平台建设、核心业务系统信创转型、超融合关键场景落地、核心业务 K8s 改造、数据中心零信任安全、“基础设施即代码”等前沿话题。

我们将以文字及图片的形式，为大家回顾本次论坛期间的嘉宾精彩演讲。今天为大家带来华能贵诚信托基础架构负责人王昆的演讲内容：《核心业务系统 Kubernetes 落地实践》。

本内容作者为华能贵诚信托基础架构负责人王昆，由 FIW2022 组织方编辑整理发出，以下为部分演讲内容。

今天我来给大家分享一下华能贵诚信托核心业务系统 Kubernetes 改造落地的实践，我将从五个方面来介绍，分别是项目背景、核心业务系统、K8s 容器管理平台、DevOps 流水线以及可视化运维与监控。

一、项目背景

先从项目背景分析一下，我们公司为什么要做 Kubernetes 的改造。华能信托新一代信托综合业务系统是借助移动互联、大数据、人工智能等金融科技技术，实现信托项目全生命周期的智能化管理，借助信息技术增强客户体验，提升投前、投后管理水平，提升风险防控能力，提升工作效率，提升专业服务能力。

在业务层面，我们真正做到了释放业务人员重复性的工作，提升工作效率。比如对于系统里大量的录入操作，我们做了一些系统复制，从已有的历史项目当中复制过来，至少能提升 50% 左右的效率。

在数据标准化层面，因为系统开发较晚，是从 2018 年开始的，我们开发时按照监管要求进行表结构设计，所以我们的系统能够直接对接监管报送，这部分数据不需要单独处理。由此我们把各个监管机构要求的对应信息都从系统层面、从项目落地及新建开始就已经融入到整个系统中，对于监管报送这一块是无缝支持的。

在公司战略层面，提供了准确、全面的业务数据，为高层领导提供决策分析、公司战略发展提供数据支撑。

我们新一代业务系统采用了比较先进的基础架构，整合了信托日常工作中常用的业务，包括对三方的产品和服务进行整合，实现了以客户为中心，提供包含信托业务展业平台、TA 资金平台、销售管理平台、信托综合业务管理，以及与三方系统的交互，包括我们的信托财务的核算模块、监管报送、老系统的数据迁移等。

由于系统里面包含了公司最重要的一些业务，所以我们对系统的稳定性、安全性、可靠性和快速介入有较高的要求，要求业务 7×24 小时不间断运行。要建立长期稳定可靠高速接入的环境，现有的基础平台无法满足需求。

于是公司从 2019 年开始组织内部 K8s 的调研和学习，并组织通过 CKA 考试。2020 年 9 月，我们已经搭建了 K8s 的测试环境，并把部分业务迁到 K8s 的集群上进行验证。到 2021 年 3 月，我们已经完成了 K8s 开发环境的搭建和核心业务的整体迁移。2021 年 9 月，测试环境也全都迁移到 K8s 集群中，截止今年 9 月已稳定运行一年，我们也陆续将核心系统生产业务迁移至 K8s 生产集群，但并没有最终投产，计划 10 月以后投产。这里说明一下，这并不是因为我们遇到了什么问题，而是我们公司在做分布式存储的采购工作，原本传统的 NAS 存储这个对于 K8s 的支持不是很友好。当前分布式存储已经落地，计划 10 月左右上线，上线后正式把 K8s 迁移过去，避免迁移完成后再做切换。

二、核心业务系统介绍

下面我来简单介绍一下核心业务系统。核心业务系统主要是将公司的前后台、中台以及人员进行流程的打通，是一个全流程管理的平台。从前端业务部门的提交到领导的审批、财务，再到最终的核算及监管报送，实现流程化管理。核心业务系统与其他部门系统及三方系统进行了集成，目前打通了与银行的代销、互联网推荐、三方渠道、OA、门户网站、家族信托系统、资产证券化系统、自动生成凭证、恒生估值系统，以及企查查工商信息。此外也对接了短信平台、邮件平台和电子签章，实现了线上合同的电子签，还包括与各个银行的对接，实现线上划款，以及对接增值税开票系统，实现了发票的自动开票及电子票的推送。目前信托保障基金系统也已经集成到核心业务系统里了，所以不涉及到对接。

当前的核心业务系统包括 5 个部分，第一个是业务流程处理平台，包括信托项目的全生命周期管理、资金运用管理和季度结息等功能，可以完成数据录入、系统自动结息，实现全面的自动化管理。第二个是 TA 销售管理平台，实现了资金端的生命周期管理和银行代销数据的管理。第三部分是财务会计平台，我们对信托财务模块进行了重构，集成到了业务系统中，包括核算管理、核算场景设置和年终收益结转等功能。第四个是一体化监管报送平台，内置了银监会、人行、中信登等 10 余个报送模块，都在核心业务系统进行统一管理。第五个我们开发了三方交互平台，包括外联接口监控和监控报警功能，以上是我们核心业务系统的整体架构。

核心业务系统主要包括项目立项、审议、实施、中后期和项目清算，同时包含了代销及委托端的管理，我们也开发了小程序，包括企业微信的审批流程。信托管理的子业务系统中包含了信财管理，即刚提到的财务模块，其中有风控决策子系统，以及其他的总部业务管理。核心业务系统与旧系统进行了打通，旧系统的数据通过 ETL 工具迁移到新系统。底层的技术支撑是流程引擎和规则引擎、基于 ClickHouse 开发的大数据平台、基于方案报表开发的内部报表平台、SpringBoot 和 Kettle 工具，然后搭建了内部的大数据平台及报表展示平台。同时我们跟报送的关联，都通过我们基于 Kettle 和 SpringBoot 这类开源工具开发的监管报送平台，这个是我们整个的技术架构。

下面介绍一下微服务架构，前端使用 Keepalived 实现集群边境室的管理，并能够实现动态负载，然后从 Nginx 到前端的 Spring Cloud Zuul 的网关，网关对接的是后端各个资金项目、资产、结息、财务、TA、家族、ABS 等微应用。底层包括基础服务、流程服务、引擎组件，以及对外提供的 OPEN API 的应用。平台用到了 Redis、RabbitMQ Cluster、MinIO、MySQL 数据库，同时这些微应用也通过 ELK 进行日志收集，包括 Zipkin 的链路追踪，实现了统一微服务治理工作。

三、K8s 容器管理平台

下面给大家介绍一下容器管理平台，我们搭建了三套 K8s 集群，包括开发环境、测试环境和生产环境，目前搭建这些集群没有耗费太多资源，因为 K8s 上跑的是一些无状态的应用。所以我们生产淘汰下来的机器，3 年、5 年之后淘汰机器会放到测试环境，当做 K8s 的节点来跑，即使坏了也没有影响，我们能够快速在另一台机器上启动，而且不需要人为管理。那么我们测试的一些机器，比如说 5 年到 8 年，机器本身没有问题，我们就把这个物理节点放到开发环境的 K8s 集群上，极大提升了资源利用率。

 

这是我们核心业务系统基于 K8s 的架构。前端通过 AD 进行负载到达 Nginx Keepalived，虽然我们已经迁到 K8s 集群，我们前端还是通过这样的模式进来，后续我们可能会改造，全部采纳 F5 的硬件负载，那么后期可能通过 F5 进行负载到 K8s 的 API Server 上，然后进行内部整个链路的打通。

目前我们还是基于 Nginx Keepalived 的这种模式，然后流量引导到 K8s 里面 Zuul 的网关，调到我们 Eureka 注册中心，拉起后端微应用的接口，实现业务流程。我们通过应用集群、微服务架构，然后通过 Spring Security Oauth2 的健全服务，包括统一的日志收集，以及对接的第三方对象存储，Redis、ES 这类检索工具，包括我们用到的插件 xxl-job 的分布式任务调度，整个的底层和业务系统适用的 MySQL 数据库（目前是三个节点“主主从”模式，从库是实现报表展示的工作），目前完整的流程基本上都是跑到 K8s 上，我后续会介绍完整的开发业务流程。

我们生产环境的一个集群目前有 22 个节点、三个 Master 节点和 19 个物理节点。三个 Master 节点放到了 SmartX 的虚拟化平台上面。因为我们认为 Master 节点是比较重要的，如果放在物理节点上损坏的话，虽然有三台，但是我们还是希望能够更高可用。其他的 19 个节点是用物理机构建的。我们测试环境的其中一套目前有 27 个微服务，默认所有都是两副本，所以跑了 54 个容器，可以监控整个测试环境的资源利用情况。

四、DevOps 流水线

我们整个开发的 DevOps 流水线是这样的：从 GitLab 上面拉代码执行单元测试、代码扫描，然后构建推送进入 Harbor 镜像仓库里面，发布到开发的 K8s 集群，开发验证通过后会提交到代码到跟 GitLab 上面，合并到测试分支后再提交到测试环境。下一步是测试人员测试，测试通过后把代码合并到生产分支，再进行发布。

我们对 Java 版本进行了一些改造，能够在开发人员无感知的情况下，自动改造发布到 K8s 集群上。只需在 GitLab 上改下参数，就可以从原来的发布到虚拟机上，自动发布到 K8s 集群上。

我们的 K8s 集群既支持直接从源码构建，也支持从外部拉取已编译好的二进制镜像进行发布。我们还缺少单元测试，目前处于初级阶段，后续我们会借助自动化工具集成到这个流程中来，实现自动化测试的功能，提升程序的健壮性。

 

这是我们整个的开发平台，从开发人员提交到 GitLab，然后 Jenkins 从 git 上拉取代码，编译成 Docker 镜像，提交到 Docker 仓库，再通过 Jenkins 执行命令，在 K8s 集群上拉取镜像进行发布。目前不同的业务系统是通过 Namespace 做应用的隔离。我们目前是三套集群：开发、测试、生产，所有的业务系统都在这三套集群里，开发和测试人员基本上都可以通过系统直接访问。

我们 Jenkins 的流水线目前包含了几套环境。原来是直接发布到虚拟机上，现在进行了改造，开发人员不需要写 Dockerfile 文件，可以自动修改发布到 K8s 集群里面。

我们的 SonarQube 代码扫描平台，负责在所有的代码提交后进行扫描，问题处理好之后才会进行编译，最终会提交进行打包镜像，上传到 Harbor 镜像。比如我们内部的一个 Harbor 仓库，一些微服务的镜像就会提交到这个平台上面。

五、可视化运维与监控

 

下面给大家介绍一下整体的运维与监控。我们的开发人员通过 Jenkins 构建然后发布 K8s，和传统运维有一些区别，现在的方式相当于把整个流程都自动化，中间出了问题时很难定位，所以监控就比较重要。目前 Jenkins 自带的，包括所有的编译，每一步都有完整的日志记录，所以对于 Jenkins 这一块没有做相关的处理，直接使用 Jenkins 默认的内部记录编译成功失败的日志，非常便于查询。

除了 Jenkins 编译这一块，K8s 也有对应的监控。我们采用 ELK 进行收集，同时用 Zipkin 对整个应用之间的链路进行追踪，应用到底是在哪个环节出了问题，很容易能够查询到。

除了这些之外，我们还有 Zabbix 进行监控，以及 Grafana 进行报警。我们 Prometheus 是用了 KubeSphere 的这套集群里面最大的一个监控，也为大家介绍一下。

我们在 K8s 集群上部署了一个 KubeSphere，是一个国产开源的 K8s 管理工具，功能非常丰富，但是我们并没有完整地用到它，目前能用到的就是监控功能。因为它的监控页面比较美观，而且监控指标比较全面，所以我们并没有单独再给 K8s 做另外的监控工作，只借助了这个平台。除此之外还用到线上人员权限的管理功能，不同应用的运维人员不同，我们可以在 KubeSphere 里面进行设置。

因为我们公司会 K8s 的也只有两三个人，不可能要求所有人去学习，但这么多系统也不可能让三个人来运维。所以我们就构建了 KubeSphere，让开发人员和运维人员也能分析和定位问题，目前用的还是比较好的。

以上是我们的整个 K8s 集群的监控，可以对整个集群的 CPU、内存、存储和容器进行整体监控，包括 ETCD。整个集群健康的状态能够通过这个界面看出来，资源、API 的调度情况都能在集群监控里面看到。

除了集群状态监控，我们还能对 Node 节点的状态进行监控，可以在界面完整查看所有节点的状态，包括 CPU、内存、磁盘 Node 数、负载数量等，出现问题能够及时告警。

此外我们还能够实现对容器的监控，看到容器的运行状况、资源利用，包括历史情况。那这块监控有什么用处？我们刚才提到默认是两副本，那么假设内存占用率达到 75% 以上，那么它就会自动扩容一个节点，把两副本增加到三副本。同样，三副本如果资源利用率内存还是超过 70% ，会再去拿第四个副本，直到整体资源利用率降低到 70% 以下，这样能够实现资源的合理利用和调度。

KubeSphere 对整个集群的监控确实很好，但存在一个问题，它本身是依赖于 K8s 的，如果 K8s 整体本身挂掉的话怎么办？所以我们在 K8s 的外面一层，相当于以第三方的视角，引入了 Zabbix 对节点以及 K8s 整个集群状态再进行了一层监控，如果 K8s 的整体集群是没有问题的，我们可以通过 K8s 里面的监控来掌握集群的状态、Node 节点的状态、容器的状态。如果 K8s 集群出了问题，我们也可以通过外部的 Zabbix 进行监控，能够达到相当于灾备的效果。