技术破局：如何实现分布式架构与云原生？| 含 ppt 下载

2月19日-2月26日，蚂蚁金服开展了“共战‘疫情’，技术破局”数字课堂线上直播，邀请资深专家从“云原生”、“研发效能”、“数据库”三方面分享蚂蚁金服的实践经验并在线答疑，解析 PaaS 在金融场景的落地建设实践，解析支付宝移动端弹性动态架构，分享 OceanBase 2.2版本的特性和实践。

本文根据 蚂蚁金服 SOFAStack 产品专家俞仁杰，在蚂蚁金服数字课堂直播间分享的云原生应用 PaaS 平台的建设实践内容整理，以下为演讲整理全文：

大家好，欢迎来到蚂蚁金服数字课堂直播间。今年 2 月，SOFAStack 金融分布式架构产品已经在阿里云上完成了商业化发布，为了让更多朋友了解到我们的产品的能力、定位以及背后的设计思路，后续我们会有一系列的直播分享。我们今天想分享给大家的话题叫《云原生应用 PaaS 平台的建设实践》，主要会围绕 PaaS 产品能力在一些需要稳妥创新的金融场景下的落地思路，并且能够更好地与云原生架构做好链接。

金融场景云原生落地面临挑战

云原生是业务快速变化背景下的必然技术趋势

回顾 IT 的发展史，云计算分类为 IaaS PaaS 和 SaaS 已经有十几年了。而事实上，整个云计算行业的发展，我们能够明显看到企业在落地云计算战略的时候经历的三个阶段，Cloud-Based, Cloud-Ready, Cloud-Native。这三个阶段其实是因为业务的变化越来越敏捷，要求企业关注重心上移，把更多的精力和人才投入到业务逻辑的建设上，而把下层自已并不擅长并且越来越复杂的基础设施、中间件逐渐交给云计算厂商去实现，专业的人做专业的事。

这本质是社会分工的进一步细化，也符合人类社会发展的规律。在云原生时代，业界所提出的容器技术，Service Mesh 技术，Serverless 技术都是希望让业务研发与基础技术更加的解耦，让业务创新和基础技术创新都更容易的发生。

容器技术带来的是一种应用交付模式的变革

云原生就是业务快速变化背景下的必然技术趋势。而这个趋势背后的实质载体，就是我们所说的云原生、Kubernetes 以及以 Docker 为代表的容器技术，这些所带来的，本质是一种应用交付模式的变革。而为了真正能够使业界、社区所倡导的新兴应用交付模式落地到实际的企业环境，我们需要一个以应用为中心的平台来进行承载，贯穿应用运维的各项生命周期。

围绕“云原生”这个关键词，其实在社区和业界已经有了非常多的交流和资料，围绕Docker/K8S 的最佳实践、DevOps CICD、容器网络存储设计、日志监控对接优化等等等等，而我们今天的分享，主要想表达的是我们围绕在 K8S 之上塑造一个 PaaS 平台的产品价值主张。Kubernetes 是一个非常好的编排和调度框架，它核心的贡献是让应用的编排和资源的调度更加的标准化，同时提供了一个高度可扩展的架构，方便上层进行各种控制器和调度器的定制。但是，它并不是一个 PaaS。PaaS 底层可以基于 Kubernetes 去实现，但是在上层要补足非常多的能力才能真正把 Kubernetes 用于生产环境，特别是金融行业的生产环境。

金融场景需要“稳妥创新”

生产环境落地云原生需要着重考虑哪些挑战？

我们之前做过一些调研和客户访谈。就现在 2020 年来说，绝大多数金融机构都展现出了对 Kubernetes、容器等技术的极大兴趣，有不少机构也已经在一些非关键的业务、或开发测试环境搭建了开源或商业版的集群。驱动力很简单，金融机构非常希望这一整套新的交付模式帮助到业务飞速迭代。然而对比落差非常明显的是，真正敢于在核心生产环境落地云原生架构的，又少之又少。因为金融业务创新的前提，是要保障稳妥。

我们团队在服务蚂蚁内部业务、外部金融机构的过程中，总结了以上这几个方面，事实上这六大方面也是我们内部 SRE 不断挑战的几点。我们在今天以及未来的分享中，会逐步总结深化应对这些挑战的产品思路。

K8S 体系下的应用变更与发布管控

我们今天分享的一个核心内容，就是我们如何在产品层面做应用变更的风险保障的。并围绕此话题向大家介绍变更“三板斧”的背景、K8S 原生部署能力、我们产品围绕变更需求做的扩展并向大家介绍我们在开源方面的规划。

需求背景：变更“三板斧”

所谓“三板斧”就是可灰度、可监控、可应急。这是蚂蚁内部运维的一条红线准则，所有的变更，都必须要遵从这个规则，即使再细小的变更，再严密的测试，也不能忽略这条规则。为了满足这个需求，我们在 PaaS 产品层设计了各种各样的精细化发布策略，比如分组发布、beta 发布，灰度发布，蓝绿发布等。这些发布策略跟我们在做传统运维时用的手段是非常相似的，但很多使用容器的用户认为在 K8S 里实现会非常的困难。

有些时候，由于对业务连续性的极高要求，也很难接受原生 K8S 模型标准化模式，比如原生 Deployment 做灰度或者金丝雀发布时，默认情况下在 Pod 变更和流量治理层面的管控还稍显不足，无法完全做到无损发布或按需过程管控。因此，我们在 PaaS 产品层面做了定制，在 Kubernetes 层面做了自定义资源的扩展，目的是能够在云原生的场景下，依然对整个发布过程实现精细化管控，使得大规模集群发布、灰度、回滚时更加优雅，符合技术风险三板斧原则。 

Kubernetes 原生发布能力

我们先来回顾一下 K8S 的原生 Deployment 对象，及其背后的 ReplicaSet，其实已经是在最近好几个大版本中已经逐渐的稳定了。 简单的来说，最常见的 K8S 发布场景，我们会通过 Deployment 的对象，声明出我希望的发布模式以及 Pod Spec 定义。在运行时，会有 ReplicaSet 对象来管理 Pod 数量的预期，默认情况下会提供滚动发布或重建发布能力。

image.png

这幅图的下半部分，是围绕 Deployment 作滚动发布时的示意图，这里不再做过多的展开，它的本质根据用户根据我们的运维需求设定好一定的步长，创建新的 Pod，销毁旧的 Pod，因此能做到整个应用版本的变更和发布过程中，都能有对应的容器对外提供服务。 对大部分场景来说，它是够用的，而且整个过程也是非常好的理解，事实上在 K8S 体系，大家除了 Pod/Node，看的最多的就是 Deployment了。

CAFEDeployment：感知底层拓扑和领域模型

回顾完 Deployment，我们可以再给大家看一下我们根据实际需求作的 CRD 扩展，CAFEDeployment。CAFE 是我们 SOFAStack PaaS 产品线的名称，本文的最后会作一些介绍。

CAFEDeployment 有一个很重要的能力，就是能够感知到底层拓扑，这个拓扑是什么意思呢？能够知道我想把我的 Pod 发布到哪里，哪边的 Node，不只是基于亲和性的规则作绑定，而是真正能把高可用、容灾、以及部署策略等场景息息相关的信息，带到整个围绕发布的领域模型中。对此，我们提出了一个叫部署单元的领域模型，他是一个逻辑概念，在 yaml 中简单的叫做 Cell。在实际使用中，Cell 的背后，可以是不同的 AZ 不同的物理机房，不同的机架，一切都是围绕着不同级别的高可用拓扑。

CAFEDeployment：精细化分组发布扩容

感知到了底层拓扑，我们再看一下 CafeD 的典型发布过程。这也是后面会通过产品控制台和命令行来演示的内容。这幅图所展现的过程，是一个精细化的分组发布，目的是能够让容器实例层面的变更，做到足够的可控和灰度。每一个阶段都能暂停、验证、继续或回滚。

以图上这个例子进行说明，我们的目标是发布或变更 10 个 Pod，且需要让这 10 个 Pod 能够均匀分布在两个可用区，确保在应用层面是高可用的。同时，在发布的过程，我们是需要引入分组发布的概念，即每个机房都要先仅仅发布一个实例，暂停验证之后，再进行下一组的发布。于是第 0 组，就变成两边各 1 个实例，第 1 组各两个，第 2 组则是剩下的 2 个。在实际的生产环境中，围绕容器大规模变更会配合业务监控及更多维度的观察，确保每一步都是符合预期、验证通过的。这样在应用实例层面的精细化管控，为运维提供了能够及时刹车回滚的机会，是线上应用发布的一个重要的保险绳。

CAFEDeployment：优雅摘流无损发布

讲完整个精细化的发布，我们再讲一个精细化的摘流。无损发布需要确保南北和东西向的网络流量都能被优雅摘除，确保在容器停机、重启、缩容的时候能够对线上业务无感。

这张图展示了一个 Pod 作变更发布时的控制流程规范。时序图中包括了 Pod 以及其相关联的各组件控制器，着重是和网络相关的如 Service Controller、LoadBalancer Controller 作配合，进行切流、流量回复检查等操作以实现无损发布。

在传统经典运维场景基于指令式的运维习惯下，我们可以通过依次执行命令每个组件进行原子操作，确保入口流量、应用间流量都能完全摘除后，再执行实际的变更操作。而在云原生 K8S 场景下，这些复杂的操作都留给了平台，运维人员只需作简单的声明即可。我们在部署时把应用所关联的流量组件（不限于 Service loadbalancer/ RPC/ DNS...) 都透传到 CAFEDeployment，添加对应的“finalizer”，并通过 ReadinessGate 来做 Pod 是否可以承载流量的标识。

以原地升级控制器 InPlaceSet 控制下的 Pod 为例，在做指定 Pod 更新时，会设置 ReadinessGate=false，相关联的组件感知到变化后，逐个注销对应的 IP，触发实际摘流动作。在等待相关 Finalizer 都被摘除之后，进行升级操作。待新版本部署成功后，设定 ReadinessGate=true，在依次触发各关联组件的实际流量挂在动作。待检测到 finalizer 和实际 CAFEDeployment 中声明的流量类型全部一致后，当前 Pod 才算发布完成。

开源版本介绍：OpenKruise - UnitedDeployment

我们再回到 PPT 的一个讲解，其实刚刚说的 CAFEDeployment，它在我们整个 CAFED 的一个商业化的产品，事实上在整个商业板的同时，我们也在做一些社区的开源，而在这个里面我想介绍一下 OpenKruise 项目，OpenKruise 源于整个阿里巴巴经济体的大规模云原生运维实践，我们把许多基于 K8S 体系下的自动化运维运维操作通过 K8S 标准扩展的方式开源出来，对原生 Workload 无法满足的能力作了强有力的补充，解决应用的自动化，包括部署、升级、弹性扩缩容、Qos 调节、健康检查、迁移修复等场景问题。

当前 OpenKruise 项目提供了一套 Controller 组件，其中的 UnitedDeployment 可以理解为 CAFEDeployment 的开源版本。除了基本的副本保持和发布能力，他还包含了 CAFEDeployment 的主要功能之一，多部署单元的 Pod 发布能力。 同时，由于UnitedDeployment 是基于多种类型的 workload（目前支持社区的 StatefulSet 和 OpenKruise AdvancedStatefulSet）实现对 Pod 的管理，因此它还能保留相应 Workload 的特性。 

UnitedDeployment 的核心贡献者吴珂(昊天) (Github:wu8685) 来自于 SOFAStack CAFE 团队，主导了整个 CAFEDeployment 的设计与开发。当前我们正在努力把更多能力在经过大规模验证之后，通过标准化的方式整合进开源版本中，逐步减少两个版本的差异，使之趋于统一。

展望与规划

讲到这里，因为时间关系，围绕一些细节的技术实现就先分享到这里了。回顾一下前面关于 CAFEDeployment 关于整个发布策略的内容介绍，我们产品设计的一个关键价值主张就是，能够为应用和业务在拥抱新兴技术架构的时候，提供一个稳妥演进的能力。无论是虚拟机为代表的经典运维体系，还是规模化容器部署的云原生架构，都需要精细化的技术风险管控。同时，在宏观上，又能往最先进的架构上演进。

实践参考：某互联网银行容器应用交付演进路线

以某个互联网银行的容器化演进路线为例。在成立之初，就确定了以云计算基础设施之上构建微服务分布式体系。但从交付模式上看，一开始采用的还是基于经典虚拟机的 PaaS 管控模式，从 2014 年到 2017 年，业务都是通过 Buildpack 把应用包发布到虚拟机上。这种运维模式虽然持续了三年，但是我们在这个过程中帮助完成了同城双活、两地三中心、到异地多活单元化的架构升级。

在 2018 年，随着 Kubernetes 的逐渐成熟，我们在底层基于物理机和 K8S 构建了底盘，同时，用容器模拟 VM，完成了整个基础设施的容器化。但于此同时，业务并不感知，我们通过实际在底层 K8S 之上的 Pod，以“富容器”的方式为上层应用提供服务。而从 2019 年到 2020 年，随着业务的发展，对于运维效率、扩展性、可迁移性、精细化管控的要求更是驱使着基础设施往更加云原生的运维体系演进，并逐渐落地 Service Mesh、Serverless、单元化联邦集群管控等能力。

云原生单元化异地多活弹性架构

我们正在通过产品化、商业化的方式，把这些年来积累的能力开放出来，希望能够支持到更多金融机构也能够在互联网金融业务场景下快速复制云原生的架构能力并为业务创造价值。

大家可能在很多渠道了解到蚂蚁的单元化架构、异地多活的弹性和容灾能力。这里我给到大家一张图，是我们当前在建设，且马上在几个月内在一家大型银行作解决方案落地的架构抽象。在 PaaS 层面，我们在 K8S 上建设一层联邦能力，我们希望每一个机房都有独立的 K8S 群，因为一个 K8S 集群直接进行跨机房、跨地域部署是不可行的，无法满足容灾需求。进而通过多云联邦的管控能力，这同样需要我们 PaaS 层产品针对 Kubernetes 做一些扩展，定义逻辑单元，定义联邦层资源等等，最终达成多机房多地域多集群的单元化架构。结合之前分享中我们提到的，CAFEDeployment、ReleasePipeline，还有一些 Fedearation 层的联邦对象，我们做了大量扩展，最终目的是在这些复杂的场景中为业务提供统一的发布管控和容灾应急能力。

SOFAStack CAFE 云应用引擎

说到这里，终于可以解释下前面提了很多的 CAFE 是什么意思了。CAFE, Cloud Application Fabric Engine 云应用引擎，是蚂蚁金服 SOFAStack 云原生应用 PaaS 平台的名称，不仅具备 Kubernetes 标准化的云原生能力，更在上层把经过生产检验的应用管理、发布部署、运维编排、监控分析、容灾应急等金融级运维管控能力开放了出来。同时，与 SOFAStack 中间件、服务网格 Service Mesh、阿里云容器服务 ACK  做了深度集成。

CAFE 提供的关键差异化能力，是为应用生命周期管理提供具有技术风险防控保障（包括变更管控，容灾应急能力），并随之提供可演进的单元化混合云能力。是金融场景下落地分布式架构，云原生架构，混合云架构的关键底盘。

SOFAStack 金融分布式架构

最后一页，其实才是今天真正的主题。今天所介绍的 CAFE，是 SOFAStack金融分布式架构产品中的一部分。当前 SOFAStack 已经在阿里云上商业化发布了，大家可以来申请试用，并与我们作进一步的交流。大家可以通过搜索引擎、本文提供的产品链接、阿里云官网了解更多。

在【金融级分布式架构】微信公众号后台回复 “CAFE” ，即可下载完整PPT。