引言
G行以全栈云平台为基础，逐步推进云原生技术的应用，探索数字化转型路径，为银行业务快速发展提供有力技术支撑。同时，云原生也带来了在微服务管理、云安全、健康监测、依赖路径、韧性要求等多方面的挑战，具体表现为：
微服务管理：多个微服务有机组合才能构建一个健康的应用程序，本质上许多活动部件需要协同工作才能使系统正常运行。如果一项微服务失败，则系统需要对其进行检测并自动修复。随着自动化部署引入，系统迭代频繁，应用系统微服务的管理越来越复杂，管理要求越来越高。
云安全：由于云原生环境的易变性，传统边界安全模型无法覆盖所有风险场景。在云原生技术架构下，容器间隔离、微服务全生命周期变化、微服务间网格化依赖、集群资源自动调度等新领域都可能带来不同层面的安全风险，影响应用系统稳定性。因此，针对云原生的复杂性引入安全管理策略和技术手段进行有效防护和保障，是非常有必要的。
健康监测：Kubernetes是非常复杂的平台，为了保障基于Kubernetes的业务系统平稳运行，了解Kubernetes的健康状况至关重要。一些现有技术可以用来收集Kubernetes集群日志、各种指标数据、事件和安全威胁，以帮助监视集群的健康状况，但单一指标很难系统性的衡量基于Kubernetes的应用系统健康程度。需要一套更加智能、直观的方式，对各种指标数据进行采集、整合、综合分析，从而生成可视化的高阶视图。
依赖路径：在一个由多集群、微服务化的云原生分布式环境中包含大量交互、依赖点，可能出错的地方数不胜数。硬盘故障、网络不通、流量激增压垮某些组件，任何一次故障处理不好就有可能导致业务停滞、性能骤降，或者其他各种无法预料的现象；同时云原生环境中，也难以全面掌握何种故障会导致系统局部崩溃，甚至全面崩溃。需要尽可能地在这些情况发生之前找出系统中的脆弱点。
韧性要求：云原生带来的业务分散、集群繁多、集群边界受限等问题对云平台也提出了新挑战，需要平台提供可靠的韧性能力以保障业务稳定运行。业务分散体现在应用在各集群的差异化配置、业务跨云访问、集群间应用同步等；集群繁多体现在繁琐重复的集群配置、云厂商集群管理差异、碎片化API访问入口，如何让集群对上层用户透明等问题；集群边界限制体现在资源调度受限于集群、应用可用性受限于集群、弹性伸缩受限于集群。如何让应用可以面向多集群进行部署分发，如何提供整体跨集群自动伸缩能力也是未来面临的挑战。
针对上述挑战，我们进行了一些探索和实践，以提高平台韧性，提升业务运行稳定性。
云原生业务韧性的探索与实践
1.实践内容
为了提升云上业务感知、保护和主动优化能力，进一步应对上文描述的一系列挑战，G行全栈云初步完成了云原生业务韧性能力建设，实现了部分应用系统跨集群调度、故障演练、多中心互备等功能，探索提升业务韧性，实现业务连续性与灾备管理。下图是云原生业务韧性平台架构，基于云原生技术实现应用的跨集群配置备份和数据备份。
云原生业务韧性平台功能涵盖多集群管理、云原生应用系统数据备份与恢复、跨集群资源及演练调度等核心模块，具体内容如下：
- 多集群管理：集群管理包括应用管理、备份管理、策略管理、沙盘管理、活动监控、监控告警、容量管理等子功能模块。同时保障纳管集群标签、资源、节点、服务、状态等数据的有效管理。
- 云原生应用系统数据备份与恢复：根据不同业务应用条线的重要程度制定不同备份策略。核心业务、关键业务提供分钟级甚至秒级备份，普通业务、非关键业务可按周或按月备份并能够按照备份时间点进行快速恢复。
- 跨集群资源及演练调度：实现Kubernetes集群之间的资源调度，满足业务高峰时的资源需求，其中包括调度策略的制定、调度组、历史记录及报告等；支持云上虚拟机与容器应用的切换演练调度，应对突发事件的切换调度，其中包括演练计划、演练方案、演练报告、场景管理、流程库、步骤库、阶段库等。
2.应用成效
目前全栈云韧性平台已完成多个Kubernetes集群以及集群内部分应用系统纳管，实现应用灾备无缝切换，并基于平台能力实现如下能力探索：
- 灵活备份策略：有效的缩短备份时间，灵活的备份频度，提高RTO；避免备份冗余数据，提高资源利用率。
- 稳敏双态灾备：基于不同语言的回调，实现统一纳管及调度；优化切换效率，显著提升RTO。
- 多云迁移：支持不同云厂商切换过渡，实现平台级灾备能力；顺应国产化信创要求，双栈并举，防范系统性风险。
后续改进
云原生技术带来了更高层次的基础设施抽象，让应用开发人员的关注点从基础设施进一步分离，聚焦上层业务逻辑实现。全栈云在实践韧性能力建设过程中，也面对与应用系统结合的一系列问题，包括：
- 应用定制多：每个应用系统都有自己的架构特性，在技术上无法实现应用的一键灾备纳管，只能针对每个应用剥茧抽丝，一一定制。
- 配置梳理繁：不管是纯云原生应用，还是稳敏双态应用，都有平台级、系统级、服务级等各种复杂配置，灾备端纳管起来容易错一漏万，严重时甚至影响到主端应用的正常运行。
- 业务验证难：针对应用系统完成的容灾备份，与主端应用的业务对等性无法得到完全、充分的验证。
- 主备同步弱：云原生应用系统迭代快，业务更新频繁，备端应用无法满足一次纳管，同步迭代。备端需要针对主端应用系统的每次迭代进行主动同步，以确保主备服务的一致性。
- 为解决上述问题，在以“API+云服务”的形式构建服务生态链的潮流下，我们也在探索技术手段和管理机制互相融合可行方案，具体包括：
- 灾备前移：管理上将应用系统上云改造与云上灾备管理融合，技术上针对不同应用系统制定不同容灾规范，确保完成上云即完成容灾建设。
- 平战结合：平时完善BCP和DRP，确保其准确性、有效性，演练验证；战时快速响应、快速决策、快速处置；平战结合，打造来之能战、战之能胜的业务连续性体系。
- 稳敏双态共存：业务线条贯穿敏态和稳态，信息系统本地应急和异地灾备能力需稳敏同时构建；稳敏技术架构遵从BCM体系构建支撑能力；风险联动业务和IT部门，构建稳敏兼顾的双态组织和应急体系。
- 高低频事件联动：依托低频事件，构建BCM体系业务和IT的最后一道防线；面对高频事件，实现日常运维和组件切换的联动；高低频事件联动，切实实现资源共享，提升灾备投资ROI。
下图是全栈云韧性平台可行的优化流程，从指标制定、策略制定、能力建设、应急演练、应急切换、优化改进以及影响分析报告等形成的一套业务系统的优化闭环，每一个步骤均通过相关的技术手段以达到预期目标。在后续工作中我们将深入探索技术与管理的融合方案，服务于应用系统业务连续性。
未来，G行将从IaaS、PaaS、SaaS、DevOps等方向进一步完善云原生系统的管理、调度、观测和容灾演练能力，全方位构建完整生态云体系，为云上业务韧性保驾护航。同时基于云原生架构规划推进业务系统建设，继续深耕金融科技领域，提高服务成本的透明度与可信度，期望通过自己的云原生架构落地实践为业界提供数字化转型经验。
