金融级云原生探索实践系列 - 开篇

由蚂蚁金服主办的 SOFAStack Cloud Native Workshop 将在 6月24日于 KubeCon + CloudNativeCon + Open Source Summit China 大会的同场活动中进行，欢迎报名参与，更多信息可点击“ 阅读原文”进行查看。 
欢迎加入 SOFA 钉钉互动群（钉钉搜索群号）：23195297

本文作者：蚂蚁金服 卿祤、 首仁

| 楔子

为支撑业务高速发展并积极拥抱主流技术，蚂蚁金服从 2017 年开始探索并构建以Kubernetes 为核心的云原生应用 PaaS 平台。在 2018 年，已在网商银行顺利落地了 K8S 容器引擎，并顺利支撑了 2018 年双十一。2019 年伊始，国泰产险作为互金行业的典型代表，正基于 SOFAStack [1] 容器应用服务和监控分析产品探索云原生架构转型。时至今日，已完成了关键业务 SOFABoot [2] 应用的容器化改造，在开发、测试乃至灰度生产环境践行云原生的运维实践。

这是一系列技术分享文章的开端，基于在实际金融机构和场景中落地的云原生产品项目经验，我们希望和大家一起分享从中获得的洞察和总结，探讨产品观点、技术实现，并非常期待大家的建议和指点，欢迎一起交流共创。

| 云原生容器产品的金融机构落地挑战

从去年开始，云原生、Kubernetes、容器这些关键字逐渐从社区走向金融科技圈，越来越多的金融机构客户开始向我们咨询，云原生技术是什么，能够给企业带来什么价值，对现有业务有什么影响？落地的路径可能会是哪些？

我们的观点是，金融场景下的云原生，绝对不止是 12Factors [3]，亦不止是 CNCF TOC 所定义的 5 大件 [4]，我们不仅要提供标准、通过一致性认证的 Kubernetes 产品，还需要满足更多金融场景需求，创造实际业务价值。

经过很长一段时间的产品研发实践、深挖内外容器平台落地诉求，金融客户的关注点可能包括但不限于以下几点：

• 业务采用了云原生能否节省资源，提升工程效率？

• 发现问题后如何做到快速止损，甚至线上零故障？

• 如何在云原生下做到业务同城双活甚至异地多活的高可用容灾能力？

• 能否和现有业务能无缝集成，如何做平滑升级？

• 采用了云原生平台能否保证和现有云上一致的安全性？

• 云原生能否支撑大规模分布式系统的架构？

• ...

而基于以上实际场景下的落地挑战，我们对自身容器平台产品的设计和实施，提出了以下六大关键价值主张。

| 云原生容器产品的价值主张

一 使用 Immutable Infrastructure 的思想进行设计

在 PaaS 平台中，核心是应用。在之前的经典运维体系中，要对应用打一个全量快照不是件容易的事情，但在云原生世界中，会方便许多。从描述流量接入层的 Service 到描述应用配置和代码包的 Pod template，这些已是 kubernetes 的标准 Resources。

为了解决应用管理需求，我们定义了一个 CafeAppService 对象，用于整体描述上述内容，并通过 Revision 对象属性作版本控制（和 Knative 中的 Revision 类似）。用户每次的修改都是一个 Revision，发布一个应用本质上是发布该应用的一个 Revision，故可做到快速的弹性扩缩容，并且可以方便回滚到之前发布成功过的 Revision。相比之前基于包的经典发布运维体系，效率有极大提升。

图一 容器应用服务与版本

二 可审计和无损应用发布的能力

发布变更是 PaaS 平台提供的重要能力。对于金融客户来说，每次发布必须要有据可查，而且要保证安全无损。这里，我们将蚂蚁的安全生产理念融入其中，在产品层面上提供“可灰度，可回滚（应急），可监控”的能力。

为了做到上述能力，我们提供了发布单的概念，并定义了一个原生的 CRD：CafeDeployment。接下来逐一介绍。

发布单

主要两个用途：做应用发布的审查记录，用于统计分析，故障复盘回顾等；协调多个应用的发布顺序，这是由于金融业务对系统的可靠性要求高，尤其在涉及资金的主链路，另外，不少系统由于业务原因，存在依赖关系，必须做有序发布。

CafeDeployment

在这里只做简单介绍，后续会有专题介绍。该 CRD 拥有三种能力：

• 原地升级（InplaceSet）:升级过程中 Pod 的 IP 保持不变，可和经典的运维监控体系做无缝集成。

• 替换升级（ReplicaSet）:和社区版本的 ReplicaSet 能力保持一致。

• 有状态应用（StatefulSet）:和社区版本的 StatefulSet 能力保持一致。

除此之外，相比社区的 deployment，还具备 beta 验证，自定义分组策略，分组暂停，引流验证（配合 ServiceMesh）的能力。

图二 CafeDeployment 图示

三 具有高可用容灾能力的工作负载

金融业由于监管的要求对系统可用性和容灾能力具有很高的要求。从应用的生命周期来看，最主要有两个状态：发布态 和 运行态。

对于发布态，由于存在 Pod 上下线的过程，线上有抖动不可避免，要做的是尽可能的降低抖动幅度以及降低系统报错率。kubernetes 的 deployment 在发布一个 pod 时，pod 里容器的 kill 和对应 endpoint 的销毁是异步的，这就意味着可能出现 pod 里应用容器已经 kill 了，但仍然会有流量打到该 Pod，导致出现报错，甚至故障。为了防止这种情况，我们采用 finalizer 的机制，保证在南北流量和东西流量（7 层协议）都切断的情况下才对 Pod 进行更新。

同时，还通过 CafeDeployment 里的灰度发布策略，保证发布态时线上系统的水位不会过低，防止出现流量过载，造成系统异常。

对于运行态，要考虑以下几个方面：Pod 异常退出后的重新上线，Node 故障后的 Pod 的迁移，机房级故障后系统仍然可用。对于第一点，Kubernetes 本身已经有了较好的机制；第二点，我们做了增强，使用自定义的 NodeLifecycle Controller 结合更加详细的监控信息来判断Node是否出现故障，然后做 Pod 迁移；第三点，从 Scheduler 方面进行保障，CafeDeployment 可以定义相应的高可用拓扑结构，以同城双活为例，在创建 Pod 时，调度器会根据定义好的拓扑信息尽量将 Pod 均分到不同的可用区，达到同城双活的状态。

四 一致的验证授权体验

蚂蚁金服 PaaS 平台在近 4 年的时间里，已经有了一套完整的 IAM 体系，并且许多客户已经基于此定义了许多的角色，用做安全防护。我们从两方面来提供一致性的体验：

首先，在产品上的操作上提供和原先一样的验证授权机制。只要客户将 K8S 内预先定义好的角色或者权限分配相应的用户或用户组，那该用户或者属于该用户组的用户就能在产品上做相应的操作。

其次，IAM 的权限和角色与 Kubernetes 的 RBAC 做映射。根据用户在 IAM 所具备的角色，在 Kubernetes 集群中创建相应的 ClusterRole，并生成访问 Kubernetes 集群的 token，创建 ClusterRoleBinding 与 token 绑定。这样用户使用 kubectl 操作集群时也可以具备相同的权限，保证权限的一致性。

五 经典到云原生的过渡能力

目前互金行业的应用的运行时绝大部分仍然以虚拟机为主，并且以传统的应用包方式进行部署和日常升级运维。对于向云原生的转型一定不是一蹴而就的，会有过渡期，在这段时间内，就面临着需要同时在经典与云原生下两种模式下同时做运维管理。

针对这种场景，APaaS 平台提供以下能力帮助客户解决痛点。

第一，支持经典与云原生的互访，拉齐两种模式的基础网络、应用层流量和接入层流量。在基础网络层面，采用VPC  Router 或者 ENI 方式，在几乎没有额外网络开销的前提下保证虚拟机和 Pod 可以互通；在应用层，虚拟机和Pod可以使用同一套中间件做服务注册与发现，并且可以相互调用；在接入层，虚拟机可通过 loadbalancer 类型的 Service 访问后端的 Pod，甚至不在 VPC 内的 on permise 应用也可通过公网类型 loadbalancer Service 访问到 Pod。

图三 经典与云原生的互访

第二，提供两种模式的混合发布能力。可以同时对经典虚拟机模式和云原生模式的应用进行发布运维，保持体验一致性。

第三，采用原地升级方式（InplaceSet）进行发布的云原生应用可和经典监控系统无缝对接，接入原有的监控与报警体系。直到所有应用做完云原生改造后，再迁移到云原生生态中主流的 metrics 监控体系。

六 支撑跨集群发布运维的能力

这是一个高阶话题，需要结合具体的业务场景来看。从实践经验来看，这会是一个架构演进路线：一开始采用一个集群管理多个可用区，在碰到容量瓶颈或者需要异地多活场景时，再开始考虑进行集群划分，采用多集群方式。以网商银行的业务为例，首先采取同城双活，然后到两地三中心，最后演进到现在的异地多活单元化架构。

在云原生架构下，我们需要解决两个问题。

第一，在架构演进过程中，如何保证上层接入产品少感知甚至不感知集群数量的变化。这类上层产品（比如发布运维、资源管理等），我们称为一方产品，通常具有“上帝”视角，需要获取到集群中的所有资源信息，当集群从一个演进到多个后，还需要能够分别出资源属于不同的集群，并作出相应的处理。我们从以下方面解决该问题。

• 定义一个模型来标明资源所属的集群，并且该模型需要和现有模型建立联系，以便集群扩展后做准确路由。

• 提供一个统一接入层来路由对不同集群的访问。

• 一方产品使用该模型和统一接入层来访问集群。

第二，在演进到多集群之后，如何提供跨集群资源的统一视图。这点参考社区Federation对象的设计，需要将不同集群里的资源状态进行同步，之说以没有直接采取社区Federation方案，首先社区这块目前还是alpha版本，还不成熟，另外，我们定义的模型和涉及到的业务场景很复杂。这部分内容正在建设中，后续将继续更新。

| 展望

金融级云原生之路才刚刚开始，将沉淀多年的技术积累与云原生紧密结合并开放给整个行业，是一个持续探索的过程。本文仅做是一个概览性介绍，其中的每一块内容都可作为一个专题来深度讲述，后面会持续更新，和大家分享我们最佳实践，欢迎关注。

文章涉及相关链接

[1] SOFAStack：

https://www.sofastack.tech/

[2] SOFABoot：

https://www.sofastack.tech/sofa-boot/docs/Home

[3] 12Factors：

https://12factor.net/zh_cn/

[4] 5 大件（CNCF 云原生定义）：

https://github.com/cncf/toc/blob/master/DEFINITION.md

| 关于我们

随着蚂蚁金融科技开放战略和国际化的业务背景，时至今日蚂蚁金服SOFAStack 已经服务了许多家国内外金融机构作分布式架构技术转型升级，过程中也逐渐打磨和丰富了大规模运维监控产品体系，即金融分布式架构-云应用引擎(SOFAStack-CAFE,  Scalable Open Financial Architecture - Cloud Application Fabric Engine)，其中容器应用服务(AKS, Application Kubernetes Service) 则是基于 K8S 打造的核心容器服务产品，致力于满足机房级高可用、安全、弹性、可观测性、发布变更管控策略等方面的要求，并力求降低复杂新兴技术带来的门槛和应用风险。

最后打个广告，欢迎加入 SOFAStack 产品研发团队，共建金融级云原生产品！目前产品经理、架构师 、前后端研发和质量等多个岗位开放招聘中，简历请投递：[email protected] 。