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

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

楔子

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

这将是一系列技术分享文章的开端，基于在实际金融机构和场景中落地的云原生产品项目经验，咱们但愿和你们一块儿分享从中得到的洞察和总结，探讨咱们的产品观点、技术实现，并不是常期待你们的建议和指点，欢迎一块儿交流共创。

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

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

咱们的观点是，金融场景下的云原生，绝对不止是 12Factors，亦不止是 CNCF TOC 所定义的 5 大件，咱们不只要提供标准、经过一致性认证的 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 版本，还不成熟，另外，咱们定义的模型和涉及到的业务场景很复杂。这部份内容正在建设中，后续将继续更新。

展望

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

关于咱们

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

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

公众号：金融级分布式架构（Antfin_SOFA）