技术破局：如何实现分布式架构与云原生？| 含 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。