云原生时代,蚂蚁金服公开了新的金融混合云架构

  • 时间:
  • 浏览:0
  • 来源:大发5分快3-极速5分排列3-急速5分快乐8

引言

蚂蚁金服过去十五年,重塑支付改变生活,为全球超过十二亿人提供服务,那些手中离不开技术的支撑。在2019杭州云栖大会上,蚂蚁金服将十五年来的技术沉淀,以及面向未来的金融技术创新和参会者分享。让让.我将其中的优秀演讲架构设计 成文并将陆续发布在“蚂蚁金服科技”公众号上,本文为其中一篇。

互联网技术发展日新月异,让让.我正在进入云原生时代,你许多过程中金融行业要咋样拥抱云原生?在近两年蚂蚁金服将云原生在金融领域落地,沉淀下许多实践经验,接下来帮我分享在蚂蚁的演进过程当中,让让.我心中的云原生是那些样的,在金融领域落地的刚刚 遇到那些疑问图片,以及让.我全是为什么我么我会么会处理的。

经太满年云计算的蓬勃发展,上云刚刚 全是太疑问图片图片,接下来的疑问图片是为什么我么我会么会把云用好,用得更高效。RightScale 2019年最新数据显示,现在公有云规模占22%,只使用私有云的客户占3%,更多客户通过混合的模式去使用云,通过混合云取得数据隐私、安全与带宽、弹性的平衡。

再看全球整个IT行业,公有云的比例只占整个基础IT市场的10%,市场空间仍然很大,IT市场中剩下就说 全是传统企业客户。为那些传统行业无法很好地利用公有云,另另三个小 重要的原因分析分析是刚刚 让让.我的 IT 系统经过很长时间建设,就说 全是此人 的机房。另外许多则业务比较稳定,对上公有云这样很强的需求。它们通常会发展混合云策略,把许多核心业务留在私有云,而把许多边缘业务或创新业务倒进公有云上。

那些特点在金融行业也非常明显,除此之外金融行业还另另三个小 形态:

■业务形态走向开放和互联网化:随着互联网和数字化经济的发展,金融机构都要进行数字化转型,以及业务敏捷化、服务场景化,以应对新的商业模式带来的冲击;

■ 监管合规的诉求:金融行业的业务特点决定了都就说 强隔离,强监管的,就说 公有云上的资源共享模式在监管方面会有比较大的挑战。

刚刚 ,混合云战略对金融机构更为适用。你许多结论也得到研究支持,根据调研机构Nutanix的报告,全球金融业在混合云应用方面的发展带宽超过其它行业,目前部署普及率达到21%,而全球平均水平为18.5%。

这样,那些样的混合云是适合金融机构的呢?以蚂蚁的演进历程为例。

蚂蚁在第四代架构的刚刚 演变成为云平台架构,刚刚 为了应对互联网业务形态下突发性业务对资源的弹性需求,蚂蚁也在同一阶段将架构直接进化成弹性混合云架构。现在蚂蚁刚刚 演进到第五代云原生架构。蚂蚁又是咋样在云原生的架构下,把混合云变成金融级的混合云,帮我会对各位许多启发。在你许多发展过程中,有二根主线,是不同阶段蚂蚁对研发的标准和要求,包括:自主、成本、安全、稳定、海量、敏捷,这也是在在线金融的时代,让让.我对云原生架构的要求。

从分布式到云原生 建立金融级交易支付系统

建立金融级的在线交易系统,第一步是要实现金融级分布式的架构,蚂蚁在这方面的代表技术是SOFAStack和OceanBase,目前都已对外商业化,并有丰厚的案例。SOFAStack代表的是,在整个应用层刚刚 无具体情况服务你许多层面上,咋样去做可伸缩、可扩展的一套架构。OceanBase代表的是以数据库为代表的存储刚刚 是有具体情况服务层面,咋样在架构后边去进行分布式。它们拥有六个形态:

■高可用,99.99%+的可用性保证,确保系统始终连续运行不中断;

■一致性,在任何异常具体情况下数据最终一致,确保资金安全;

■可扩展,支持应用级、数据库级、机房级、地域级的快速扩展;

■高性能,存储采用读写分离架构,计算引擎全链路性能优化,准内存数据库性能。

而这六个关键的形态全是金融业务最为看重的,刚刚 都要在应用和存储后边到端实现。

以一致性为例,在单个数据库内是能这样确保数据一致性的,但在大规模应用的具体情况下,单个数据库老会 会老会 出先瓶颈,数据往往会像服务刚刚 应用一样,按照同类交易、支付、账目等粒度垂直拆开,当那些数据分别存储在不同的数据库集群后,就都要在应用层来处理一致性疑问图片了,同時 为了支持海量数据,数据库集群内部也会做分别和多副本,OceanBase就说 原本一套分布式数据库,在其内部也要实现分布式事务。这样原本上下配合要能解掉所有分布式架构下的一致性疑问图片,缺一不可。

再比咋样扩展性方面,许多系统号称做了分布式架构,实际刚刚 就说 用了微服务框架,做了应用层的服务化改造,但数据库层既这样用水平扩展的技术,也没用分布式数据库,整个系统的可扩展性就卡在数据层的短板上。

就说 ,真正的分布式系统,都要实现端到端的分布式,要能实现无限可扩展和高性能,而真正的金融级分布式系统则要实现端到端的高可用和一致性。

蚂蚁金服三地五中心异地多活架构

让让.我认为,高可用架构最关键的目标是数据不丢,业务不停。在你许多目标的基础上,让让.我设计并实施了三地五中心的异地多活架构。它的核心优势包括城市级容灾,低成本交易,无限可扩展,以及RPO=0,PTO<200s. 让让.我知道让.我全是去年云栖大会上做了一次剪网线的demo,它演示了整个架构层面上为什么我么我会么会样做到跨城市多活和灾难具体情况下的恢复快速恢复能力。同時 在高可用达标的具体情况下,让让.我也做了就说 风险相关的事情,总结起来就说 在高可用的基础上都要做到资金的安全、变更的免疫和故障的快速恢复。

处理了高可用的疑问图片,我我觉得金融级最被高频提到搞笑的话题就说 安全,在云原生时代,让.我全是处理的是全链路、端到端的安全风险。具体分为另另三个小 层面:

■云原生网络安全,包括策略化高效流量控制,全链路加密,流量劫持与分析;

■云原生基础设施安全,包括安全容器,不共享内核,以及安全沙箱;

■云原生业务安全,包括SOFAEnclave机密计算后边件,以及内存安全的、多任务Enclave LibOS Occlum。

你许多要素我的同事在《金融服务的云原生安全架构》演讲中会完整性介绍。小结一下,所谓金融级的能力,最主就说 要实现端到端的金融级的高可用,同時 实现端到端的安全。接下来帮我分享的是,在云原生你许多阶段往前走遇到了那些疑问图片。

从单元化到弹性架构 应对互联网爆炸式的流量脉冲

从单元化到云原生下的弹性架构

首先解释下那些是单元化,让让.我刚刚 比较容易理解数据库层的分库分表刚刚 说 Sharding,要能通过分片的辦法 处理集中存储计算性能疑问图片,单元化的核心思想是把数据的分片提前到了入口请求的分片,在机房的网络接入层将用户请求根据某个纬度(比如用户ID)进行 Sharding,这就好比把每个机房就当做了另另三个小 巨大无比的有具体情况的数据库分片,当你是另另三个小  ID 尾号为007刚刚 008用户的刚刚 ,当请求通过手机端刚刚 网页域名发送到机房,接入层就刚刚 识别出应该将你路由到华东地区还是在华南地区。当你进入到某个地区的机房时,大要素请求处理工作能这样在机房内部完成。偶尔会有许多业务刚刚 会位于跨机房的服务调用,比如说数据在 A 机房的用户给数据在 B 机房的用户转账。你许多刚刚 就都要在你许多机房上去做有具体情况的设计。

让让.我走向云原生时代的刚刚 ,在大的架构后边用Kubernetes为基础来设计,在单元化架构下,让让.我选择 在每个单元里部署另另三个小 Kubernetes集群,将支持多 K8s集群管理和管控指令架构设计 的 Federated APIServer做逻辑上的全局部署,其中管控元数据是存储在另另三个小  ETCD 集群的,以保持全局数据一致,但让让.我知道ETCD也这样处理同城双机房的容灾,无法再应对多城市多数据中心的一致性,刚刚 让让.我正在把ETCD搬到让让.我的OB的 KV引擎上,原本在引擎层还是保持 ETCD 的存储格式和语义,存储层就具备了三地五中心高可用能力。

金融机构异构的基础设施

我我觉得你许多架构是适合蚂蚁的技术架构的,但在让让.我的技术开放给内部客户时又会遇到就说 新的疑问图片,比方说在客户的机房会有就说 异构的基础设施,让让.我就都要以 Cloud Provider的标准来实现多云适配。

刚刚 包括让.我全是内的就说 金融机构,刚刚 就说 老系统并这样按照「云原生」的辦法 去设计,就说 会对基础设施有具体情况依赖,比如依赖IP ,就说 这样完整性采用不可变基础设施的模式来支撑。许多刚刚 ,刚刚 对业务连续性的极高要求,也这样接受原生 K8sworkload的运维模式,比如原生 deployment做灰度刚刚 金丝雀发布时,对应用和流量的处理全是非常简单粗暴的,原本会原因分析分析运维变更时的业务的异常和不连续。那些让让.我都通过扩展原生的 Deployment成更适合金融业务要求的 CAFEDeployment,使得大规模集群发布、灰度、回滚时更加优雅,符合让让.我的「技术风险三板斧原则」。

就说 ,金融级的「混合云」首要处理的疑问图片是弹性和异构的疑问图片,且要符合大规模金融级运维的稳定性。处理了那些疑问图片,再往前去演进新业务的刚刚 ,金融行业会非常看重咋样做稳妥的创新,咋样在开发和运维保持传统模式继续支持业务的同時 ,引入新的运维和开发模式,双模齐头并进。

从核心系统到创新业务 构建可演进的多模基础架构

双模PaaS

云原生我我觉得源自于PaaS,就说 在应用云原生架构的刚刚 ,也先在 PaaS层遇到了平滑演讲的疑问图片。咋样让客户既能保留刚刚 的习惯,同時 又刚刚 会去尝试新的交付模式?传统的模式让让.我习惯于交付代码包,习惯于基于虚拟机的运维;而云原生时代以容器镜像为交付载体,而运行实例则是镜像的实例化容器。让让.我采用容器来模拟 VM 的运行模式,通过扩展 Deployment来模拟 VM 的运维模式,同時 也支持容器的模式。

再往上,无论是基于传统架构的PaaS,还是基于K8s的一套PaaS,实现的主要操作全是一样的,全是建站、发布、重启、扩容/缩容、下线等等。实现两套无疑非常浪费资源,也增加了维护成本。对于用户来说干的事情是一样的,就说 让让.我用 K8s实现了所有的公大约素,统一元数据、统一运维操作、统一资源抽象,在产品层和运维辦法 上,提供本身界面。同時 在交付的辦法 上,要能支持传统的应用模式、技术栈模式,要能这样基于镜像,当然在应用之外让让.我还能这样去支持函数。

SOFA双模微服务平台

再往上走就说 双模的微服务,同样面临老系统和新系统的疑问图片,让让.我刚刚 分享过,是通过Mesh辦法 来统一处理的。云原生架构下,Mesh是 Pod里的 Sidecar,但老系统往往这样跑在 K8s上,就自然不支持 Pod和 Sidcar的运维模式,就说 让让.我就得用 Agent的模式来管理 Meshtcp连接池池,以支持 Mesh要能帮助老架构下的应用完成服务化改造,并支持新架构和老架构下服务的统一管理。

数据面要双模,控制面也支持双模,传统基于 SDK 的微服务会找老的服务注册服务,但 Mesh会基于控制面,让让.我会将控制面和老的服务注册服务打通,并由后者来做真正的服务注册发现服务,以实现全局服务的可见和路由,同時 了解过蚂蚁服务注册体系的同学知道,让让.我咋样在超大规模和多机房环境下实现高可用的设计,而那些能力这样短期在社区的控制面实现,让让.我正在逐步将你许多能力沉淀到新架构上,就说 你许多控制面的双模也非常适合服务化架构在你许多混合模式下,平稳过渡到云原生架构。

最后就说 Serverless,最近Serverless非常火热,它的场景我我觉得非常丰厚,刚刚 手中对性能有很高要求,每个应用的启动带宽都要非常快,刚刚 刚刚 无法在生产环境使用。

让让.我内部的 Node系统小量采用 Serverless架构,并对启动带宽进行了优化,目前平均在4s左右,正在往进入1秒内优化。刚刚 Java应用就很痛苦,普通 Java应用的启动时间大约在 200s到 1min之内。我我觉得Serverless很美好,刚刚 Java应用却刚刚 启动带宽疑问图片,这样用到你许多架构红利。让让.我采用了 JVM 的 SVM 技术将应用进行静态编译,实现了另另三个小 正常启动时间在200秒钟左右的应用优化到 4 秒左右,当然你许多是在牺牲掉反射等许多动态性换回来的,同時 为了要能尽量不会应用改,还改了就说 后边件的SDK ,以减少这方面适配对应用带来的影响。当你许多黑科技能完美支持1秒以内,整个Java技术生态就能这样平滑的迁移过来,应用场景会更加的扩大。但你许多都要挺长另另三个小 周期,刚刚 也都要社区更多人参与进来,同時 做开源类库的反动态性的改造。就说 ,让让.我利用让让.我应用容器的类隔离性来支持多个模块刚刚 同另另三个小 模块的不同版本在另另三个小  Java运行时里跑,互不干扰,刚刚 能这样模拟 Serverless下的快速冷启动和快速扩缩容。

让让.我将你许多具备隔离能力,支持模块快速装载和卸载的 Java运行时称之为 SOFA Serverless Container,将最小的运行时模块称之为 SOFA Function,那些小的代码片段通过一套 Serverless API 进行编程。在过渡阶段,让让.我将 SOFA Serverless Container部署成另另三个小 集群,并在此之上混合调度多个 SOFA Function,此时 SOFA Serverless Container 和 SOFA Function是 N:1。到后期,刚刚 黑科技能处理 Java应用的启动带宽疑问图片,而那些SOFA Function就能这样平滑的过渡到 Pod部署模式,此时另另三个小  SOFA Function只会跑在另另三个小  SOFA Serverless Container。

再总结下,金融级的混合云要处理技术平滑演进搞笑的话,还是要具备可演进可迭代的能力,就说 让.我全是PaaS、微服务、Serverless等层面都提供了双模的「混合」能力。

金融行业业务与技术发展趋势

最后让让.我能这样就看,无论是银行刚刚 整个金融领域的发展趋势,和技术架构的演进趋势我我觉得是一一对应的,在不同的阶段都要不同的能力。我相信就说 银行现在刚刚 位于在做数字化转型、移动化转型的阶段,刚刚 随着移动化转型完成接入整个互联网的渠道刚刚 ,我我觉得支付宝前面碰到的就说 疑问图片相信就说 的金融机构一定会碰到,就说 也希望今天的分享会对让.我全是些启发。谢谢让让.我。