蚂蚁金服在过去十五年重塑支付改变生活，为全球超过十二亿人提供服务，这些背后离不开技术的支撑。在 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 层遇到了平滑演讲的问题。如何让客户既能保留以前的习惯，同时又可能会去尝试新的交付模式？传统的模式大家习惯于交付代码包，习惯于基于虚拟机的运维；而云原生时代以容器镜像为交付载体，而运行实例则是镜像的实例化容器。我们采用容器来模拟 VM 的运行模式，通过扩展 Deployment 来模拟 VM 的运维模式，同时也支持容器的模式。
再往上，无论是基于传统架构的 PaaS，还是基于 K8s 的一套 PaaS，实现的主要操作都是一样的，都是建站、发布、重启、扩容 / 缩容、下线等等。实现两套无疑非常浪费资源，也增加了维护成本。对于用户来说干的事情是一样的，所以我们用 K8s 实现了所有的公共部分，统一元数据、统一运维操作、统一资源抽象，在产品层和运维方式上，提供两种界面。同时在交付的方式上，也能支持传统的应用模式、技术栈模式，也可以基于镜像，当然在应用之外我们还可以去支持函数。
再往上走就是双模的微服务，同样面临老系统和新系统的问题，我们以前分享过，是通过 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 等层面都提供了双模的「混合」能力。
最后大家可以看到，无论是银行或者整个金融领域的发展趋势，和技术架构的演进趋势其实是一一对应的，在不同的阶段需要不同的能力。我相信很多银行现在可能处于在做数字化转型、移动化转型的阶段，但是随着移动化转型完成接入整个互联网的渠道以后，其实支付宝前面碰到的很多问题相信很多的金融机构都会碰到，所以也希望今天的分享会对大家有些启发。谢谢大家。
本文作者：缪克卢汉
阅读原文
本文为云栖社区原创内容，未经允许不得转载。