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

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

互联网技术发展突飞猛进，咱们正在进入云原生时代，这个过程当中金融行业要如何拥抱云原生？在近两年蚂蚁金服将云原生在金融领域落地，沉淀下一些实践经验，接下来我想分享在蚂蚁的演进过程中，咱们心中的云原生是什么样的，在金融领域落地的时候遇到什么问题，以及咱们是怎么解决的。

通过多年云计算的蓬勃发展，上云已经不是太大问题，接下来的问题是怎么把云用好，用得更高效。RightScale 2019年最新数据显示，如今公有云规模占22%，只使用私有云的客户占3%，更多客户经过混合的模式去使用云，经过混合云取得数据隐私、安全与效率、弹性的平衡。

再看全球整个IT行业，公有云的比例只占整个基础IT市场的10%，市场空间仍然很大，IT市场中剩下不少都是传统企业客户。为何传统行业没法很好地利用公有云，一个重要的缘由是由于他们的 IT 系统通过很长时间建设，不少都有本身的机房。另外有些则业务比较稳定，对上公有云没有很强的需求。它们一般会发展混合云策略，把一些核心业务留在私有云，而把一些边缘业务或创新业务放在公有云上。

这些特色在金融行业也很是明显，除此以外金融行业还有两个特征：

• 业务形态走向开放和互联网化：随着互联网和数字化经济的发展，金融机构须要进行数字化转型，以及业务敏捷化、服务场景化，以应对新的商业模式带来的冲击；
• 监管合规的诉求：金融行业的业务特色决定了必须是强隔离，强监管的，因此公有云上的资源共享模式在监管方面会有比较大的挑战。

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

那么，什么样的混合云是适合金融机构的呢？以蚂蚁的演进历程为例。

蚂蚁在第四代架构的时候演变成为云平台架构，并且为了应对互联网业务形态下突发性业务对资源的弹性需求，蚂蚁也在同一阶段将架构直接进化成弹性混合云架构。如今蚂蚁已经演进到第五代云原生架构。蚂蚁又是如何在云原生的架构下，把混合云变成金融级的混合云，我想会对各位有些启发。在这个发展过程当中，有一条主线，是不一样阶段蚂蚁对研发的标准和要求，包括：自主、成本、安全、稳定、海量、敏捷，这也是在在线金融的时代，咱们对云原生架构的要求。

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

创建金融级的在线交易系统，第一步是要实现金融级分布式的架构，蚂蚁在这方面的表明技术是SOFAStack和OceanBase，目前都已对外商业化，并有丰富的案例。SOFAStack表明的是，在整个应用层或者无状态服务这个层面上，如何去作可伸缩、可扩展的一套架构。OceanBase表明的是以数据库为表明的存储或者是有状态服务层面，如何在架构上面去进行分布式。它们拥有四个特性：

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

一致性，在任何异常状况下数据最终一致，确保资金安全；

可扩展，支持应用级、数据库级、机房级、地域级的快速扩展；

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

而这四个关键的特性都是金融业务最为看重的，并且须要在应用和存储上端到端实现。

以一致性为例，在单个数据库内是能够确保数据一致性的，但在大规模应用的状况下，单个数据库老是会出现瓶颈，数据每每会像服务或者应用同样，按照相似交易、支付、帐目等粒度垂直拆开，当这些数据分别存储在不一样的数据库集群后，就须要在应用层来解决一致性问题了，同时为了支持海量数据，数据库集群内部也会作分别和多副本，OceanBase 就是这样一套分布式数据库，在其内部也要实现分布式事务。只有这样上下配合才能解掉全部分布式架构下的一致性问题，缺一不可。

再好比可扩展性方面，有些系统号称作了分布式架构，实际可能只是用了微服务框架，作了应用层的服务化改造，但数据库层既没有用水平扩展的技术，也没用分布式数据库，整个系统的可扩展性就卡在数据层的短板上。

因此，真正的分布式系统，须要实现端到端的分布式，才能实现无限可扩展和高性能，而真正的金融级分布式系统则要实现端到端的高可用和一致性。

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

咱们认为，高可用架构最关键的目标是数据不丢，业务不停。在这个目标的基础上，咱们设计并实施了三地五中心的异地多活架构。它的核心优点包括城市级容灾，低成本交易，无限可扩展，以及RPO=0，PTO<30s. 你们知道咱们在去年云栖大会上作了一次剪网线的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 ，因此很难彻底采用不可变基础设施的模式来支撑。有些时候，因为对业务连续性的极高要求，也很难接受原生 K8s workload 的运维模式，好比原生 deployment 作灰度或者金丝雀发布时，对应用和流量的处理都是很是简单粗暴的，这样会致使运维变动时的业务的异常和不连续。这些咱们都经过扩展原生的 Deployment 成更适合金融业务要求的 CAFEDeployment，使得大规模集群发布、灰度、回滚时更加优雅，符合咱们的「技术风险三板斧原则」。

因此，金融级的「混合云」首要解决的问题是弹性和异构的问题，且要符合大规模金融级运维的稳定性。解决了这些问题，再往前去演进新业务的时候，金融行业会很是看重如何作稳妥的创新，如何在开发和运维保持传统模式继续支持业务的同时，引入新的运维和开发模式，双模齐头并进。

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

双模PaaS

云原生其实源自于PaaS，因此在应用云原生架构的时候，也先在 PaaS 层遇到了平滑演讲的问题。如何让客户既能保留之前的习惯，同时又可能会去尝试新的交付模式？传统的模式你们习惯于交付代码包，习惯于基于虚拟机的运维；而云原生时代以容器镜像为交付载体，而运行实例则是镜像的实例化容器。咱们采用容器来模拟 VM 的运行模式，经过扩展 Deployment 来模拟 VM 的运维模式，同时也支持容器的模式。

再往上，不管是基于传统架构的PaaS，仍是基于K8s的一套PaaS，实现的主要操做都是同样的，都是建站、发布、重启、扩容/缩容、下线等等。实现两套无疑很是浪费资源，也增长了维护成本。对于用户来讲干的事情是同样的，因此咱们用 K8s 实现了全部的公共部分，统一元数据、统一运维操做、统一资源抽象，在产品层和运维方式上，提供两种界面。同时在交付的方式上，也能支持传统的应用模式、技术栈模式，也能够基于镜像，固然在应用以外咱们还能够去支持函数。

SOFA双模微服务平台

再往上走就是双模的微服务，一样面临老系统和新系统的问题，咱们之前分享过，是经过Mesh方式来统一解决的。云原生架构下，Mesh 是 Pod 里的 Sidecar，但老系统每每没有跑在 K8s 上，就天然不支持 Pod 和 Sidcar 的运维模式，因此咱们就得用 Agent 的模式来管理 Mesh 进程，以支持 Mesh 可以帮助老架构下的应用完成服务化改造，并支持新架构和老架构下服务的统一管理。

数据面要双模，控制面也支持双模，传统基于 SDK 的微服务会找老的服务注册服务，但 Mesh 会基于控制面，咱们会将控制面和老的服务注册服务打通，并由后者来作真正的服务注册发现服务，以实现全局服务的可见和路由，同时了解过蚂蚁服务注册体系的同窗知道，咱们如何在超大规模和多机房环境下实现高可用的设计，而这些能力很难短时间在社区的控制面实现，咱们正在逐步将这个能力沉淀到新架构上，因此这种控制面的双模也很是适合服务化架构在这种混合模式下，平稳过渡到云原生架构。

最后就是Serverless，最近Serverless很是火热，它的场景虽然很是丰富，可是背后对性能有很高要求，每一个应用的启动速度须要很是快，不然可能没法在生产环境使用。

咱们内部的 Node 系统大量采用 Serverless 架构，并对启动速度进行了优化，目前平均在4s 左右，正在往进入1秒内优化。可是Java应用就很痛苦，普通 Java 应用的启动时间大约在 30s 到 1min以内。虽然Serverless很美好，可是Java应用却由于启动速度问题，很难用到这个架构红利。咱们采用了 JVM 的 SVM 技术将应用进行静态编译，实现了一个正常启动时间在60秒钟左右的应用优化到 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 等层面都提供了双模的「混合」能力。

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

最后你们能够看到，不管是银行或者整个金融领域的发展趋势，和技术架构的演进趋势实际上是一一对应的，在不一样的阶段须要不一样的能力。我相信不少银行如今可能处于在作数字化转型、移动化转型的阶段，可是随着移动化转型完成接入整个互联网的渠道之后，其实支付宝前面碰到的不少问题相信不少的金融机构都会碰到，因此也但愿今天的分享会对你们有些启发。谢谢你们。

---

OceanBase 登顶TPC-C测试榜，实现中国数据库零的突破，想要了解背后的技术细节？欢迎下载电子书《OceanBase TPC-C测试技术解析》，长按识别如下二维码，关注“蚂蚁金服科技”官方公众号，并在对话框内回复“TPCC”，便可免费下载。