您的位置: 首页 > 技术杂谈 > 正文

实践 | 百信银行基础设施容器化改造之路

2021-09-24 12:01 https://my.oschina.net/u/4657223/blog/5267650 百度云原生计算次阅读条评论

【百度云原生导读】作为国内首家国有控股的互联网银行，百信银行致力于用AI加速金融数字化、普惠化。在面临传统架构存在的弹性伸缩不够、资源浪费严重等问题时，百信银行借助百度天合Stack容器云平台，完成了技术架构云原生转型与容器化落地，大大提升了资源使用效率和研发效率。

本文整理自百信银行智能云部云基础设施团队负责人王超在百度技术沙龙上进行的名为《银行级客户基础设施容器化改造实践》的演讲，全文5300字，预计阅读时间14分钟。

1. 为什么要做容器化改造？

1.1 百信银行基础设施现状

首先，百信银行（以下简称『百信』）的基础设施架构是基于百度智能云和 OpenStack 开源项目按照金融行业标准和需求进行的加固订制，可以部署和管理私有云基础架构，对数据中心基础设施的计算、网络等硬件资源进行虚拟化。

其次，百信当前的微服务治理架构中金融网关主要实现了 Mesh 的功能，包括服务的发现、治理、熔断等。在此基础上的服务治理平台，会从金融网关加载相关配置和数据，包括监控平台，交易监控、链路监控、APM、TPM等等，通过这些数据再做一些数字化运营、数字化分析、调用链分析等。

再者，百信的 DevOps 体系采用的是百度的效率云产品，值得一提的是，银行对测试环境比较严格，不同业务场景在不同环境的测试，跑通之后会推到准生产，然后再发起申请，通过审批后发到生产，最后是生产部署。会通过 ECC 传统值班，7×24小时值班，电话通知告警等设置保证运维质量。

1.2 为什么要做容器化改造？

问题1：当前 IaaS 弹性伸缩不够敏捷。

百信从2017年发展至今，王超提到有几个事件让他印象深刻，存在的共同问题就是扩容周期较长：

问题2：计算资源长期使用不合理。2017-2018年百信处于野蛮发展推动业务的阶段，业务要多少虚拟机，就给多少。但是到2019-2020年，团队发现基础设施成本增长量和业务不再持平，全网的虚拟资源分配使用率不合理竟有50%以上。为什么产生这个问题？

申请资源不合理
虚机扩容效率低
虚机内应用混合部署问题
跑批场景

何为跑批？指非业务高峰期批量完成一些比如报表的生成 , 定期储蓄到期的自动转存 , 行内行外业务清分清算等操作。

问题3：测试环境不稳定。百信的测试环境是多人共享的，有很多中后台业务，比如银行核心业务、用户中心的业务，每个业务发版都可能会对上游造成影响。

如下图所示给了一个例子，一个测试环境中包括ABC三个模块，如果C进行了改动，A、B就会有影响。换句话说，一个模块的变更可能会影响到其他业务的测试结果。

1.3 容器化改造方向

满足监管要求的前提下落地容器平台
对接行内已有的平台系统。由于大量业务已经运行了4年，怎么更平滑的迁移到新的平台是一个挑战
推动业务容器化改造。

因此，除了业务改造要求，在容器化平台选型上主要考虑：

容器化平台的稳定性与运维成本
容器化平台能否与百信当前系统的平滑对接
容器化平台未来是否可扩展，是否存在绑定

结合这些因素经过多轮比较，百信最终选择了百度天合Stack容器云平台。百度天合容器云平台是企业级私有化部署的云原生解决方案产品，既提供了 IaaS 资源管理、访问控制等平台管理能力。又支持应用托管、CI/CD变更管理、监控告警、应用市场，同时整合了AI任务调度、在离线混部、微服务治理等差异化产品力。可以提供先进的技术与平台，帮助客户降低容器化基础设施搭建、应用部署与运维、DevOps 流水线构建等过程中的技术门槛和人力成本，平滑、低风险地实现云原生应用开发和架构转型。

同时天合Stack对硬件设备、操作系统、机房网络、存储、流量接入的适配都有比较成熟的解决方案。

下面我们详细介绍一下百信使用天合Stack产品在基础设施适配、业务容器改造最佳实践

2. 容器化改造最佳实践

2.1 基础设施改造部分

网络层面，当前百信的的虚机都跑在Overlay，采用VXLAN封装，数据库和集成网关跑在Underlay，百度的BVRouter作为三级网关打通Overlay和Underlay网络互访。考虑到Pod 要暴露真实IP地址、Pod可固定IP地址、网络全路径高可用等特定需求，可通过百度天合Stack提供的自研CNI插件与BVR无缝对接，同时支持 Pod 指定固定IP；
存储层面，无论文件存储、块存储还是对象存储，在天合Stack平台都默认提供了CSI插件支持，容器可以直接使用。块存储CDS，虚机通过CDS Agent KVM的Driver实现I/O的读写；容器实现文件存储，实现共享的目的；
负载均衡，使用BGW（百度的负载均衡设备），service controller可通过list/watch机制动态更新 BGW 的配置和实例实现动态配置。另外除了LB对接对接nodeport的模式以外，天合Stack 还实现了Pod直连模式，进一步提升了网络传输效率。

此外，操作审计和监控告警层面也结合百信银行的现有设施做了相应的改造。

2.2 CI/CD 及流水线

流水线建设的主要目标是对接百信现有CI/CD平台并且保持现有流程不变，降低流程复杂度。

目前，当一个开发人员在申请资源时，首先从会TaaS（Test as a Service）平台申请虚机/容器，有计算资源后可以做代码开发，之后通过效率云进行代码构建、产出、制品库、编译等。

在虚机部署层面，通过 Jenkins 调用 ansible，将产出包放在虚机里做一些脚本，把它运行起来，在容器化，在代码层不做任何改动，把产出包拉过来加上自己的 DockerFile 做一个 Docker build，再把这个镜像放在镜像仓库里。

在上A环境(准生产)时增加了审批流，通过审批后调用天合平台接口实现发版，A环境发完之后会推送 Docker 镜像至生产环境，先由测试区到隔离区，再到生产区。

A环境发版完成并通过测试回归后，该版本将会推送到生产环境，流程审批通过后实现了生产环境自动化发版。

如何把主机房测试区的镜像同步到生产机房？

在测试区，发完A环境之后给镜像打一个标签（ tag: product-*)，隔离区的 Docker Registry 配置一个策略：把带有标签的镜像推到隔离区，生产区的镜像仓库对应也配置了一条策略，把镜像从 Docker Registry 拉过来，这样就实现了从测试环境到生产环境整条链路的镜像同步。

2.3 自动化发版

百信当前已有一些平台支持自动化发版，如上图所示，在通过准生产环境测试后，该流程直接推送到生产发版平台，接着可以在页面上进行发版的编排，比如编排部分共有三台虚机，可以做1-1-1（第一批发版一台虚机，确认没问题后再第二批发版一台虚机，第三批发版一台虚机）的发布，或者1-2或者三台全发，发完一台虚机之后可以观察当前的流量是否正常，观测调用、APM等情况，包括回退和重试等功能，最后如果有问题还可以直接做回退操作。但是，以上发版过程是基于虚机的架构来做的。

百信联合百度天合Stack团队在应用变更功能上增加了容器分批发布能力。默认容器的原生策略只支持 Recreate 和 RollingUpdate，没有暂停的功能，所以需要开发一个分批发布的功能，Deployment 触发更新后就会 Hook 到分批发布模块，百信在自动化发版平台中做了一个分批发布接口的调用：比如一个业务，它的 deployment 多个 Pod可以在第一步配置分批发布策略，第一批发几台，第二批发几台，然后在自动化发版平台做展示，然后做逐批发布，支持分批回退也可以全量回退。

2.4 生命周期管理

容器的生命周期管理功能主要包括：

poststart：优雅上线，注册API GW
liveless：业务提供health探活接口
readless：业务提供ready探测接口
prestop：优雅下线，下线API GW

lifecycle:
            preStop:
              exec:
                command:
                  - '- /bin/bash'
                  - '- ''-c'''
                  - '- /opt/tools/bin/prestop.sh'
            postStart:
              exec:
                command:
                  - '- /bin/bash'
                  - '- ''-c'''
                  - '- /opt/tools/bin/poststart.sh'
          livenessProbe:
            periodSeconds: 30
            initialDelaySeconds: 60
            timeoutSeconds: 2
            httpGet:
              path: /app/health
              scheme: HTTP
          readinessProbe:
            periodSeconds: 30
            initialDelaySeconds: 60
            timeoutSeconds: 2
            httpGet:
              path: /app/ready
              scheme: HTTP

这样可以基本解决弹性伸缩、成本控制问题，在业务刚上线的时候就可以给对方尽量小的计算资源，让其实现弹性的扩容动作，并且基本无损。

2.5 存储方案

银行的业务主要分为联机业务和跑批业务两种，联机业务主要是放贷、信贷、转帐实时支付等，百信的底层架构基本以Tomcat、Java为主，都是无状态应用，所以这一块改造起来相对简单。

跑批业务如上文所述更多的是做报表生成，清分清算等操作，需要用到上下游传输，持久化文件，上图展示了简单的业务调用逻辑，相当于三个业务模块，A是最上游，它跑批完生成A的文件，B需要A的文件进行自己的跑批，C需要AB的文件同时到达才进行跑批，这一块，每个银行都有文件传输的工具、组件，百信通过一个FTS文件传输平台来完成这个任务，这个平台在容器化改造中有一定的难度，主要存在两个问题：

1.存储空间严重浪费，一份完全相同的数据存N份

2.管理混乱，不同应用配置方式没有标准，配置需要人为干预

为此百信提供了两个方案：

1. 接CFS，把它的配置上配置中心，业务通过 deployment 正常部署，专门部署一个文件传输的 Client Agent，挂载的PVC是同样的存储路径，实现数据的共享等。

2. 考虑到文件存储处理大量小文件存在的性能问题，我们提供了CDS块设备挂载到物理机，使用 daemonset hostpath 方式。

除了文件传输，容器化改造的难点在于如何实现『一包到底』，百信银行的测试环境分多个环境，每个环境的配置都不一样，因为之前虚机的部署方式，所以配置没有集中式的管理，总体来说，把配置打到代码库里，拉下的代码带着配置一块打包，在容器里做一包到底改造，我们不可能在测试环境打一个包，到生产环境再打一次dockerbuild，这显然不现实。

针对一包到底的问题，百度银行采用了阿波罗架构，应用统一配置文件及配置项名称，把各个环境配置不同的环境变量，包括不同的A \C \D\核心生产环境，把所有的配置信息上收，Tomcat、Java、JVM、MySQL、REDIS等等，在容器启动的时候，提供了两种方式，阿波罗本身提供自己的API方式，可以在代码里直接调用，但是这一块相当于对业务有改造。另外也提供了Shell脚本的方式，把Shell脚本的配置进行替换，如果它不在代码里写，在应用启动之前，相当于把这个脚本跑一遍，把最新配置拉下来，实现整个配置的替换。包括不同的环境，只是参数的不同，不同的环境在自己的环境变量都有配置。

以上整套架构的管理主要放在运维团队，承担各个应用不同部署单元的管理工作，开发如果需要提一些配置的改变，基本由应用运维团队来完成。

2.6 测试环境快速复制

上文提到测试环境的痛点，通过容器化改造之后解决了此问题。之前的测试环境，任何一个节点有变动会影响它的上下游节点，如果每个人都有一套完整的测试环境，就没有这个问题了。

要实现上述方案，百信需要解决几个关键问题：

1. 梳理不同应用模块调用关系，给出环境最小化范围

2. 应用、MySQL、REDIS、xmq资源全部容器化

3. 铺底全量数据快速拉起，无需了解业务库表结构

4. helm包管理实现容器资源快速部署

上图是整体测试环境复制的自动化流程：包装shell脚本，把测试环境前一天的备份数据拉起来打包，在容器中启动处理数据，再启动应用，包括持久化的数据等等，针对不同环境的配置，在每一个环境里都会搭建独有的金融网关和配置中心，这样避免不同的业务场景互相影响的问题，完全给所有的项目提供一套完整的测试开发环境。

3. 总结

简单总结一下本文内容。首先介绍了百信银行基础设施现状以及进行容器化改造的背景，然后详细描述了落地过程中的一些实践，通过整体改造，原先 IaaS 弹性伸缩不够敏捷以及测试环境不稳定等问题都有了优化方案，希望能对读者有所帮助。

今年，百信银行双活信贷业务将全面使用容器化部署，完成测试环境容器化改造。未来，会继续推进关键业务双活容器化部署，优化基础设施的精细化管理。

关于百度天合Stack容器云产品

帮助企业无论是在裸金属还是虚拟化的环境中快速搭建企业容器云平台、微服务治理平台以及函数计算平台，同时集成百度智能云特色的AI框架、在离线混部和函数计算能力，助力企业构建先进的技术中台以加速企业数字化转型。