案例丨拥抱云原生韧性，提升金融业务安全——光大银行云原生韧性思考与实践

文 /  中国光大银行  解培  陈智

云原生韧性建设背景

当前，数字经济正在成为我国经济发展的重要支撑及推动力量，结合国家科技创新发展的战略，银行业面临着新一轮转型升级的机遇与挑战。银行通过云计算技术改变资源的部署和使用方式，将传统应用迁移到云服务器上实现“上云”。然而云计算技术的意义不仅于此，越来越多的开发者意识到基于云计算架构开发的“云上”应用能够更充分发挥云计算的弹性伸缩能力，提供更好的运行服务。在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务的开发理念带动下，云原生日益成为金融企业数字化转型的新标杆。云原生应用相较于传统应用的优势也逐渐显现，多方面对比总结如下表。

表  云原生应用与传统应用的优势对比

（资料来源：CSDN，华泰研究）

Gartner预测，到2025年，云原生平台将成为95%以上新数字倡议的基础，而在2021年这一比例只有不到40%。云原生已经成为提升云计算使用效能，推动企业深度上云、用云的关键支撑，成为打造数字经济发展新动能的重要保障。

光大银行自2018年起展开云原生相关建设，以全栈云平台为核心技术，深化云原生技术在金融行业的应用，不断赋能金融业务数字化转型。目前，全栈云已实现分布式微服务框架、云中间件、容器平台、DevOps等技术的PaaS化集成，支持横向扩展、秒级伸缩、智能运维，适配应用系统的快速开发与持续交付，为金融服务快速发展提供有效技术支撑。

光大银行实践云原生技术的同时，也发现了各种新型安全风险和潜在漏洞源，如编排风险、镜像风险、微服务风险、运行时风险、网络安全风险等。因此，云原生业务韧性应运而生。云原生业务韧性是将“云原生”技术融入传统的业务连续性和容灾领域，实现针对云原生业务的业务感知、业务保护和主动优化。云原生业务韧性系统致力于帮助部署在云原生环境中的业务适应各种不确定风险所带来的挑战，是一整套专门为云原生业务打造的持续运行与优化的业务韧性闭环。

云原生韧性建设的必要性

1.云原生业务安全性

传统的边界安全模型在动态变化的云原生环境已很难适用，无法全面涵盖所有风险场景。在云原生技术架构下，容器隔离的环境、全生命周期的变化、大量微服务的应用、集群资源的自动调度，这些新领域均可能带来不同层面的安全风险，对系统稳定运行造成较大的安全隐患。因此有必要基于云原生的安全管理策略及技术手段，进行针对性的防护和保障。

2.云原生业务健康度

为了保障业务系统在Kubernetes容器集群上快速部署和稳定运行，了解Kubernetes集群的健康状况至关重要。目前一些技术可用来收集Kubernetes集群的运行日志、各种指标数据、事件和安全威胁，以帮助监视集群的健康状况，但由于Kubernetes平台本身的复杂性，单一指标往往很难系统性地衡量Kubernetes集群及集群上业务系统的健康程度。因此，需要一套更加智能、直观的方式，对各种指标数据进行采集、整合、综合分析，从而生成可视化的高阶视图。

3.云原生业务脆弱度

（1）故障的不可预知性。在一个由多容器集群构成的分布式云原生环境中，存在大量的业务交互和服务依赖点，容易出现各种各样的风险，如硬盘故障、网络不通、流量激增、组件异常等。如果不及时处理就会导致业务停滞、性能低下，或者其他无法预料的异常行为。

（2）故障难以定位。云原生环境中需要尽可能地在故障发生之前找出系统中的脆弱点。在一个复杂的分布式云原生系统中，单靠人力无法实现完全阻止所有故障的发生。因此，我们需要在异常行为被触发之前，尽可能多地识别出会导致异常的、脆弱的、易出故障的风险点，有针对性地对系统进行加固防范，从而避免故障发生时带来的严重后果。

4.云原生业务柔韧度

云原生平台实现多集群管理同时也带来了巨大的复杂性，只有解决以下挑战，才能给应用带来真正的“柔性”。

（1）突破单集群边界：资源调度、应用可用性和弹性伸缩都受限于集群，需要让应用可以面向多集群进行部署分发，提供业务跨集群自动伸缩的能力。

（2）实现业务分散：屏蔽各集群的差异化配置，实现集群间的应用同步，支持业务跨集群访问。

（3）简化多集群管理：解决繁琐重复的集群配置、云厂商的集群管理差异、碎片化的API访问入口等问题，让集群对上层用户更加透明。

（4）解耦厂商绑定：解决云厂商的个性化集群配置和黑盒化的管理，消除业务部署的“黏性”，具备跨集群的故障自动迁移能力。

光大银行建设思路及实践

1.建设云原生可观测性平台

随着云原生技术的不断深入应用，云上监控观测面临很多问题，包括微服务架构下多语言、多网络协议带来的调用链路复杂和埋点成本高的问题，基础设施能力持续下沉过程中开发与运维分离导致故障无法快速定位的问题，以及复杂系统的监控工具不统一、数据链路不关联、监测界面体验不一致的问题。

光大银行不断深化云原生技术生态，基于eBPF技术支持无侵入采集应用黄金指标，构建全局拓扑，简化云原生集群和应用运维复杂度。构建云原生可观测性平台，为应用提供零侵扰的埋点能力，降低应用的监控部署成本；基于eBPF的通用能力形成统一监控部署，实现从云上业务与网络的动态映射；基于采集数据精准过滤和动态扩展，实现从应用到网络的全链路追踪。

2.优化CI/CD流程加速代码迭代

通过对底层资源的抽象化处理，云原生应用具备了良好运行环境兼容性。开发人员无需关心操作系统、存储、网络等资源的具体情况，专注于实现业务代码。将应用和运行环境统一打包，有效减少测试环境配置工作，测试人员专注于应用逻辑本身。从开发到测试再到生产实现一致性部署，大大提升了运维效率，应用上线过程更加顺畅、敏捷和稳定。

通过将复杂的单体应用解耦成微服务，云原生应用的业务功能被拆分，业务系统迭代和更新有了更大的灵活性。业务部门的需求不再需要跟随总体规划，一批次一批次的落地，而是通过解耦后的微服务不断更新实现落地。业务系统微服务化后出现松耦合，微服务之间的协作变得更容易，不再需要按照批次一起集中部署应用，而是根据各自的业务需求，自行决策更新或者回退。

充分利用云原生应用的微服务化、开发运维一体化等特点，加速应用从代码到生产的迭代流程，最大化释放组织创造力，更快地获取业务反馈，为业务决策提供敏捷的实现和反馈机制。

3.基于高可用备份满足业务RPO

云原生应用的业务代码和运行环境统一打包在容器内，可针对容器和容器运行环境进行按需备份。根据不同业务条线的重要程度制定不同的备份策略，核心业务、关键业务做到分钟级甚至秒级备份，普通业务、非关键业务按周或按月备份。通过灵活的备份策略，不仅保障了业务故障时的快速恢复，而且优化备份周期，避免冗余备份数据，在节省空间的同时极大地提高了资源利用率。

通过业务的备份，支持业务应用的快速迭代，同时支持备份回滚，业务服务能够快速恢复到上一个可用版本，进一步加强业务韧性。

4.实现多集群调度、容灾和高可用

云原生应用本身具备灵活的扩展能力，当容器集群的可伸缩性能力集中在集群内部时，应用自动伸缩受限于单集群的能力，通过多集群调度管理建设跨集群自动伸缩能力。

在云原生风险防控及预警方面实现多集群容灾能力，根据上层应用的编排情况，自动重新分配资源，做到单集群故障出现时，应用自动切换服务集群，全面提升业务连续性保障能力。

通过对历史数据进行算法分析，并对相关预测算法进行训练、调优，参照容量数据基线进行判断，反映当前容量的发展趋势、业务量，预测未来一定时间段内资源对象的容量及容量趋势，可根据集群资源使用情况进行跨集群的弹性伸缩，提升应用架构高可用和全局弹性。

5.基于混沌工程实现业务的主动优化

（1）验证业务系统的稳定性。通过模拟物理机宕机、重启、节点网络异常等场景来验证基础设施的主从切换和主从同步是否正常。通过模拟业务的单个服务不可用、服务间网络通讯异常等场景来验证业务服务的高可用。

（2）验证微服务的容错能力。通过模拟调用延迟、服务不可用、机器资源满载等场景，查看发生故障的节点或实例是否被自动隔离、下线，流量调度是否正确，预案是否有效，微服务的强弱依赖是否正常，同时观察系统整体的QPS或RT的受影响程度。

（3）验证业务编排的合理性。通过模拟关闭服务Pod、增大服务Pod负载、关闭集群节点等场景，观察系统服务可用性，验证副本配置、资源限制配置以及Pod下部署的容器是否合理。

（4）验证监控告警的准确度和有效性。通过对业务系统注入故障，验证监控指标是否准确，监控覆盖是否全面，告警阈值是否合理，告警发送是否及时，接收人员信息是否准确，通知渠道是否可用等，提高监控告警的准确程度和有效性。

（5）验证灾备方案与应急预案的可用性。通过模拟基础设施故障演练整个可用区不可用的场景，观察跨可用区灾备切换是否正常执行，核心系统和组件是否进行自动容灾切换，应急预案是否覆盖全面、是否有缺失、是否可用、是否适用，从而对不可用、不适用、不全面的地方进行优化升级。

未来趋势及演进方向

云原生技术实现更高层次的基础设施抽象，使得研发人员的关注点从基础设施进一步抽离，更加聚焦上层业务逻辑实现。在开放共享的数字化时代，企业以“API+云服务”的形式互相传输业务价值，打破行业壁垒，共同建立起上下游的产业价值链，利用各自优势，共同建造一个高效的服务生态圈。

未来，光大银行将围绕全栈云的IaaS、PaaS、SaaS及DevOps，全方位构建完整的云技术生态体系，并基于云原生架构规划推进业务系统建设，继续深耕金融科技领域，提升服务成本的透明度与可信度。光大银行通过不断实践云原生架构和技术，为金融同业提供数字化转型的相关经验。

（栏目编辑：张丽霞）

往期精选：

（点击查看精彩内容）

新媒体中心：主任 / 邝源  编辑 / 傅甜甜  张珺  邰思琪