数据强依赖系统基础架构转型的探索与实践.docx

数据强依赖系统基础架构转型的探索与实践.docx

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多

PAGE20

数据强依赖系统基础架构转型的探索与实践

近年来,金融行业数字化革命快速迭代,为全力保障金融科技安全,推进产业改革创新,赋能数字化转型实现“整固拓展、深度应用”,农业银行聚焦基础架构转型,全面布局技术栈革新。由于硬件环境、操作系统、中间件、数据库等方面改变较大,为保障生产运行平稳,降低业务风险,应用系统在转型过程中势必采取相对平滑的方式逐步实现流量迁移。特别是数据强依赖的平台应用,普遍存在消费方系统众多的情况,部分业务数据为跨消费方共享使用,且存在更新后立即读取的使用场景,其上云等技术栈转型难度更大、风险更高。平台除需完成自身功能适配外,还要高效、平稳推动全量消费方一并完成调用关系迁移,并保障跨库数据一致性,从而实现两套应用并行期间服务运行平稳、用户体验良好。

农业银行企业级安全认证平台面向集团数十万员工提供认证、单点登录和认证凭据管理服务,超过1000个消费方应用接入,覆盖运营、财会、内部管理等十余个业务条线,其基础架构转型工程错综复杂,影响广泛。平台以平稳高效为原则,以可进可退为目标,设计并实现了观测性强、容错度高的切换机制,平滑完成了应用上云迁移。

一、鞭辟入里,剖析迁移之艰

1.消费方众多且调用方式多样,平滑无感迁移难度大

平台消费方系统众多,访问协议、报文格式、控制逻辑多样,且平台由于数据库、中间件等基础环境变化会产生一系列难以预知的功能差异,完全平滑无感迁移难度较高,面临着保障服务平稳运行成本和消费方改造成本之间的折中考量困境。

2.关键数据多方共用且高敏感,数据一致时效性要求高

不同交易或不同消费方系统依赖的关键业务数据具有实时共享需求,一方修改,多处生效,因此使用不同数据库的新旧两套服务并行期间,面临着异构数据库实时同步和事务一致性挑战。

3.交易调用链路复杂,常规运维手段难以快速解决问题

数据强依赖系统上云迁移涉及流量迁移及数据同步两大难题,迁移工作步骤多、持续时间长,新旧服务并行期保障服务稳定运行是关键,在此期间的每一个变更操作、版本迭代均可能面临更综合、更复杂、更隐蔽的运行故障,常规运维手段不能覆盖并行期所有场景,部分异常无法做到快处快恢。

二、直面挑战,寻求破题之法

1.基于Saga分布式事务的数据实时同步

Saga模式分布式事务是解决多个服务之间数据一致性问题的常用方案,该模式采用事务补偿的方式保证事务一致性,其核心思想是将整体的分布式全局事务拆分为多个具备原子性的分支事务,如果所有分支事务均正常结束则全局事务可正常完成,若某个步骤失败,则根据相反顺序依次调用补偿操作。Saga分布式事务补偿原理如图1所示。

图1?Saga分布式事务补偿原理

在跨库场景下使用Saga分布式事务,当数据库操作异常时,可启动事务异常处理机制,恢复原有数据,有效保障异构数据库的数据一致性。Saga分布式事务双库双写流程如图2所示。

图2Saga分布式事务双库双写流程

2.基于负载均衡分组策略的流量分发

常用的负载均衡技术主要分为四层和七层两种类型。四层负载均衡基于“IP地址+端口号”的组合进行流量分发,通过轮询、最小连接数等算法实现请求的均衡分配。七层负载均衡基于URL等应用层信息、调度策略进行流量分发。在请求分发过程中,允许基于源IP或目的IP、URL、HTTPHeader、HTTPBody等常见因素进行负载均衡,以及自定义负载均衡算法,并可对请求或响应的内容进行重写。此外,七层负载均衡可以根据请求路径对流量进行分组,并对各组设置不同的转发策略,在应用上云场景下实现对消费方系统的无感迁移。负载均衡流量分组及策略转发架构如图3所示。

图3负载均衡流量分组及策略转发架构

3.基于全链路追踪的关联交易运行洞察

多套服务并行运行期间,一次请求或一次完整的业务交易往往经过多个调用链路及服务模块处理,为全面掌控完整链路运行情况,需要监控不同实例、不同服务器间的关联动作。

完整的业务交易过程为一个全链路,每发起一个调用请求会产生一个跨度Span,一系列Span组成一个链路Trace,全局标识TraceID用来唯一标识全链路请求,以TraceID将多个调用关联起来,并提前进行埋点(埋点即系统在当前节点的上下文信息,埋点日志通常包含TraceID、SpanID、调用耗时、调用结果等)。通过埋点将链路数据收集并基于此进行关联交易的统计分析,以实现多层级监控。全链路追踪的应用实现了对同时访问云上云下不同服务的完整业务交易的运行监控。全链路洞察流程如图4所示。?

图4全链路洞察流程

三、勠力攻坚,开辟实践之路

为实现交易流量的平滑迁移,统筹安全与效率,保障用户体验一致,农业银行企业级安全认证平台结合自身“读多写少”的交易特征,基于数据分离、交易分离、消费方分离理念,规划了基础架构转型“三步走”战略(如图5所示)。首先,

文档评论(0)

Tony530191 + 关注
实名认证
内容提供者

版权、知识产权律师

1亿VIP精品文档

相关文档