jjzjj

G行云原生业务韧性探索与实践

帅金荣 2023-04-17 原文

引言

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等方向进一步完善云原生系统的管理、调度、观测和容灾演练能力,全方位构建完整生态云体系,为云上业务韧性保驾护航。同时基于云原生架构规划推进业务系统建设,继续深耕金融科技领域,提高服务成本的透明度与可信度,期望通过自己的云原生架构落地实践为业界提供数字化转型经验。

有关G行云原生业务韧性探索与实践的更多相关文章

  1. ruby-on-rails - 使用 Ruby on Rails 进行自动化测试 - 最佳实践 - 2

    很好奇,就使用ruby​​onrails自动化单元测试而言,你们正在做什么?您是否创建了一个脚本来在cron中运行rake作业并将结果邮寄给您?git中的预提交Hook?只是手动调用?我完全理解测试,但想知道在错误发生之前捕获错误的最佳实践是什么。让我们理所当然地认为测试本身是完美无缺的,并且可以正常工作。下一步是什么以确保他们在正确的时间将可能有害的结果传达给您? 最佳答案 不确定您到底想听什么,但是有几个级别的自动代码库控制:在处理某项功能时,您可以使用类似autotest的内容获得关于哪些有效,哪些无效的即时反馈。要确保您的提

  2. 叮咚买菜基于 Apache Doris 统一 OLAP 引擎的应用实践 - 2

    导读:随着叮咚买菜业务的发展,不同的业务场景对数据分析提出了不同的需求,他们希望引入一款实时OLAP数据库,构建一个灵活的多维实时查询和分析的平台,统一数据的接入和查询方案,解决各业务线对数据高效实时查询和精细化运营的需求。经过调研选型,最终引入ApacheDoris作为最终的OLAP分析引擎,Doris作为核心的OLAP引擎支持复杂地分析操作、提供多维的数据视图,在叮咚买菜数十个业务场景中广泛应用。作者|叮咚买菜资深数据工程师韩青叮咚买菜创立于2017年5月,是一家专注美好食物的创业公司。叮咚买菜专注吃的事业,为满足更多人“想吃什么”而努力,通过美好食材的供应、美好滋味的开发以及美食品牌的孵

  3. ruby-on-rails - Rails 中同一个类的多个关联的最佳实践? - 2

    我认为我的问题最好用一个例子来描述。假设我有一个名为“Thing”的简单模型,它有一些简单数据类型的属性。像...Thing-foo:string-goo:string-bar:int这并不难。数据库表将包含具有这三个属性的三列,我可以使用@thing.foo或@thing.bar之类的东西访问它们。但我要解决的问题是当“foo”或“goo”不再包含在简单数据类型中时会发生什么?假设foo和goo代表相同类型的对象。也就是说,它们都是“Whazit”的实例,只是数据不同。所以现在事情可能看起来像这样......Thing-bar:int但是现在有一个新的模型叫做“Whazit”,看起来

  4. ruby-on-rails - 向 Rails 3 添加 Ruby 扩展方法的最佳实践? - 2

    我有一个要在我的Rails3项目中使用的数组扩展方法。它应该住在哪里?我有一个应用程序/类,我最初把它放在(array_extensions.rb)中,在我的config/application.rb中我加载路径:config.autoload_paths+=%W(#{Rails.root}/应用程序/类)。但是,当我转到railsconsole时,未加载扩展。是否有一个预定义的位置可以放置我的Rails3扩展方法?或者,一种预先定义的方式来添加它们?我知道Rails有自己的数组扩展方法。我应该将我的添加到active_support/core_ext/array/conversion

  5. Ruby 最佳实践 : working with classes - 2

    参见下面的示例,我想最好使用第二种方法,但第一种也可以。哪种方法最好,使用另一种的后果是什么?classTestdefstartp"started"endtest=Test.newtest.startendclassTest2defstartp"started"endendtest2=Test2.newtest2.start 最佳答案 我肯定会说第二种变体更有意义。第一个不会导致错误,但对象实例化完全过时且毫无意义。外部变量在类的范围内不可见:var="string"classAvar=A.newendputsvar#=>strin

  6. ruby - 存储外部 API 的密码 - 最佳实践 - 2

    如果我构建了一个应用程序来访问来自Gmail、Twitter和Facebook的一些数据,并且我希望用户只需输入一次他们的身份验证信息,并且在几天或几周后重置,那会怎样是在Ruby中动态执行此操作的最佳方法吗?我看到很多人只是拥有他们客户/用户凭证的配置文件,如下所示:gmail_account:username:myClientpassword:myClientsPassword这看起来a)非常不安全,b)如果我想为成千上万的用户存储此类信息,它就无法工作。推荐的方法是什么?我希望能够在这些服务之上构建一个界面,因此每次用户进行交易时都必须输入凭据是不可行的。

  7. 【云原生】SpringCloud-Spring Boot Starter使用测试 - 2

    目录SpringBootStarter是什么?以前传统的做法使用SpringBootStarter之后starter的理念:starter的实现: 创建SpringBootStarter步骤在idea新建一个starter项目、直接执行下一步即可生成项目。 在xml中加入如下配置文件:创建proterties类来保存配置信息创建业务类:创建AutoConfiguration测试如下:SpringBootStarter是什么? SpringBootStarter是在SpringBoot组件中被提出来的一种概念、简化了很多烦琐的配置、通过引入各种SpringBootStarter包可以快速搭建出一

  8. ruby-on-rails - Ruby 和 SQL 中的重复业务逻辑 - 2

    我有一个PORO(普通旧Ruby对象)来处理一些业务逻辑。它接收一个ActiveRecord对象并对其进行分类。为了简单起见,以下面为例:classClassificatorSTATES={1=>"Positive",2=>"Neutral",3=>"Negative"}definitializer(item)@item=itemenddefnameSTATES.fetch(state_id)endprivatedefstate_idreturn1if@item.value>0return2if@item.value==0return3if@item.value但是,我还想根据这些st

  9. ruby-on-rails - 使用设计身份验证的 API 访问 - 最佳实践? - 2

    我正在使用Devise在Rails应用程序中,并希望通过API公开一些模型数据,但应该像应用程序一样限制对API的访问。$curlhttp://myapp.com/api/v1/sales/7.json{"error":"Youneedtosigninorsignupbeforecontinuing."}很明显。在这种情况下是否有访问API的最佳实践?我更喜欢一步验证+获取数据,但这只是为了让客户的工作更轻松。他们将使用JQuery在客户端提取数据。感谢您提供任何信息!凡妮莎 最佳答案 我建议您按照以下帖子中的选项2:使用APIke

  10. ruby-on-rails - 在多个页面上使用相同表单的 Rails 最佳实践 - 2

    我正在开发一个Rails2.3.1网站。在整个网站中,我需要一个用于在各种页面(主页、创建帖子页面、帖子列表页面、评论列表页面等)上创建帖子的表单——只要说这个表单需要在由各种Controller)。这些页面中的每一个都显示在相应的Controller/操作中检索到的各种其他信息。例如,主页列出了最新的10篇文章、从数据库中提取的内容等。因此,我已将帖子创建表单移动到它自己的部分中,并将该部分包含在所有必要的页面中。请注意,部分POST中的表单到/questions(路由到PostsController::create——这是默认的Rails行为)。我遇到的问题是当Posts表单没有正

随机推荐