金融级云原生探索实践系列 - 开篇-阿里云开发者社区

开发者社区> 金融级分布式架构> 正文

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

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

由蚂蚁金服主办的 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。相比之前基于包的经典发布运维体系,效率有极大提升。

1.png
图一 容器应用服务与版本

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

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

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

发布单

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

CafeDeployment

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

  • 原地升级(InplaceSet):升级过程中 Pod 的 IP 保持不变,可和经典的运维监控体系做无缝集成。
  • 替换升级(ReplicaSet):和社区版本的 ReplicaSet 能力保持一致。
  • 有状态应用(StatefulSet):和社区版本的 StatefulSet 能力保持一致。

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

2.png
图二 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。

3.png
图三 经典与云原生的互访

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

第三,采用原地升级方式(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 。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

SOFAStack™(Scalable Open Financial Architecture Stack)是一套用于快速构建金融级分布式架构的中间件,也是在金融场景里锤炼出来的最佳实践。

官方博客
官网链接