| 编辑推荐: |
本文主要会围绕PaaS产品能力在一些需要稳妥创新的金融场景下的落地思路，并且能够更好地与云原生架构做好链接。
来自于蚂蚁技术AntTech ,由火龙果软件Linda编辑、推荐。 |
|
金融场景云原生落地面临挑战
云原生是业务快速变化背景下的必然技术趋势
回顾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数量的预期，默认情况下会提供滚动发布或重建发布能力。
这幅图的下半部分，是围绕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
中间件、服务网格ServiceMesh、阿里云容器服务ACK 做了深度集成。
CAFE提供的关键差异化能力，是为应用生命周期管理提供具有技术风险防控保障（包括变更管控，容灾应急能力），并随之提供可演进的单元化混合云能力。是金融场景下落地分布式架构，云原生架构，混合云架构的关键底盘。
SOFAStack 金融分布式架构
最后一页，其实才是今天真正的主题。今天所介绍的CAFE，是 SOFAStack金融分布式架构产品中的一部分。当前SOFAStack已经在阿里云上商业化发布了，大家可以来申请试用，并与我们作进一步的交流。大家可以通过搜索引擎、本文提供的产品链接、阿里云官网了解更多。
|
