写点什么

金融云原生漫谈(五)|如何打造更适合云原生的数据存储方案?

作者:York
  • 2022 年 1 月 11 日
  • 本文字数:2532 字

    阅读完需:约 8 分钟

金融云原生漫谈(五)|如何打造更适合云原生的数据存储方案?

在金融行业数字化转型的驱动下,国有银行、股份制银行和各级商业银行也纷纷步入容器化的进程。

 

如果以容器云上生产为目标,那么整个容器云平台的设计、建设和优化对于银行来说是一个巨大的挑战。如何更好地利用云原生技术,帮助银行实现敏捷、轻量、快速、高效地进行开发、测试、交付和运维一体化,从而重构业务,推动金融科技的发展,是个长期课题。

 

本期云原生漫谈,将和您一起探寻如何打造更适合云原生的数据存储方案。




近年来,金融服务形态经历了巨大的变化。线上业务的兴起,带来了海量的数据接入和业务的不确定性。

 

数据系统管理弹性需求提升、数据系统访问查询需求提升,对数据存储、处理、挖掘的性能、稳定性、可靠性都提出了更高的要求。除此之外,金融企业 IT 还要建立数据“敏态引擎”,能够通过统一的编排系统配合业务上线,可以实现快速扩容。同时,存储系统自身的自动化运维能力,也成为 IT 建设者关注的焦点……

 

那么,云原生时代,我们需要什么样的数据存储方案?针对底层的 IT 基础架构,和数据存储环境挑战,金融 IT 建设者们真实发问:

 

  • 容器云数据持久化存储方案怎么选?

  • 容器云的数据资源如何分配?

  • 如何提升容器云平台的数据一致性?

  • 高并发情况下,如何实现故障快速恢复?

 

本篇文章将为您抽丝剥茧。

 

容器云数据持久化存储方案怎么选?

 

首先,容器云平台的底座主流是 Kubernetes,所以从理论上来说,只要支持 K8s CSI 存储接口的商用存储产品,就可以选择使用。

 

在实际生产环境中,NFS 是最常见的协议,也是容器云平台在数据持久化方面最简单的实现方式。容器自身可以支持文件、块、对象三类存储形式。可以依据行内应用场景的需求,以及自身的运维能力,选择最合适的存储协议。

 

  • 文件存储:适合少量数据存储、配置文件场景

  • 块存储:适合数据库等高性能场景(当然,也有一些文件存储可以提供极高的性能,取决于存储)

  • 对象存储:适合存放图片、视频、网盘文件等场景,需要应用支持

 

Kubernetes 是基于 CSI 插件的方式提供对于存储实现扩展,不仅仅是存储协议,具体存储设备也需要提供对应的 CSI 才能实现与 k8s 最佳的融合。

 

另外,也可以考虑直接采用比较成熟的块解决方案,例如 TopoLVM,适用于中间件或数据服务相关场景,产品中也内嵌了 Ceph 提供分布式存储能力,可实现存算一体或存算分离两种使用场景。

 

容器云的数据资源如何分配?

 

很多银行在采用容器云之后,应用数量急剧增加,然而数据库资源怎么分配才能轻松实现快速扩容,提高资源利用率呢?

 

首先,容器云上各个业务应用的数据库,可以由 DBaaS 平台提供。DBaaS 平台提供了多种数据库服务,譬如 MySQL,分布式数据库 TDSQL、TiDB,Oracle, MongoDB,Redis 等。

 

而互联网应用,则一般选择分布式数据库服务,和 Redis 缓存服务。

 

DBaaS 平台提供资源管理和调度,经过迭代调优的调度策略,以及充足的资源池供应,避免了多个应用共存一套库,数据库单个节点的连接数可以轻松突破 3000。

 

如何提升容器云平台的数据一致性?

 

银行高并发场景下,数据一致性非常重要,很多银行都希望通过容器云平台有效保证承载运行数据的一致性,实现快速扩容、故障快速恢复。

 

简单来说,一致性问题应该分为业务一致性数据一致性两个方面:

 

通常,业务一致性应该由微服务或上层应用保证。 而数据一致性问题如果面对单一应用,应用层面会通过操作系统保证崩溃一致性,存储层面会保证多 lun 的一致性及复制一致性。例如在某个场景下,数据库的数据文件和日志文件,分别存储在两个 lun 里,那么通常数据库会通过 dependency write 保证一定会先写日志再写数据,但是存储 down 机的瞬间,存储是否能保证日志文件和数据文件两个 lun 是一致的,这是存储对崩溃一致性的处理能力。同时,如果把两个卷分别通过 async/sync 复制到远端存储,那么就会涉及目标 lun 的复制一致性,即必须保证在某个时刻,哪怕发生了某种灾难,远端的两个卷里的数据也是一致的。

 

在容器场景里,这两种一致性问题的处理方式是不一样的:

 

对于业务一致性,一般在微服务领域会处理分布式一致性问题,这点已经通过开源方案做得很好了,也有不少客户会选择此类方案;

 

对于数据一致性,这点上,单一容器内并不会有额外的处理,OS 对崩溃一致性的处理并不会更好或坏,而存储侧的能力还需要存储来解决。

 

但是还有一个相关的话题是应用状态保留的问题,即“重启一致性“,毕竟容器领域,重启是常见现象,也可以拿出来分享:

 

容器平台采用 K8s 的 Statefulset 工作负载来保证平台承载的应用数据的一致性,稳定的持久化存储,即 Pod 重新调度后还是能访问到相同的持久化数据,基于 PVC 来实现。

 

Statefulset 工作负载有以下特性:

  • 稳定的网络标志:即 Pod 重新调度后其 Pod Name 和 Host Name 不变,基于 Headless Service(即没有 Cluster IP 的 Service)来实现;

  • 有序部署,有序扩展:即 Pod 是有顺序的,在部署或者扩展的时候要依据定义的顺序依次依次进行(即从 0 到 N-1,在下一个 Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态),基于 init containers 来实现;

  • 有序收缩,有序删除(即从 N-1 到 0):容器云平台一般采用 HPA(Horizontal Pod Autoscaler)Pod 自动弹性伸缩进行故障快速恢复,可以通过对 Pod 中运行的容器各项指标(CPU 占用、内存占用、网络请求量)的检测,实现对 Pod 实例个数的动态新增和减少。

 

现在国内容器云产品在 K8s 的工作负载支持方面都做得不错,以灵雀云为例,我们在产品中使用 K8s 的 Operator 技术进行有状态应用的部署、运维等能力,并且提供中间件的容器化服务 RDS 能力,是对数据服务(中间件、数据库)的进一步增强。

 

高并发情况下,如何实现故障快速恢复?

 

随着容器的不断成熟,不管是人工还是自动化开发运维都已经有大量用户实践的案例,能够实现在高并发时刻的快速扩容和故障恢复。

 

除了通过存储保证数据一致性之外,建议还可以考虑进行:

 

  • 应用的容器化改造,确保故障自愈。

  • 应用的无状态化改造,确保弹性伸缩与故障自愈。

  • 应用的微服务化改造,确保业务一致性,降低对数据库的要求,从而进一步降低存储一致性的要求。

 

通过上述改造,将传统的单体应用解耦,使与事务无关的业务逻辑并行运行,结合消息队列 / 服务网格、关系型数据库等,针对不同业务需求,可以分别实现数据的最终一致性和强一致性,打造更适合云原生的数据存储方案。

发布于: 刚刚阅读数: 2
用户头像

York

关注

云原生的美男子YORK 2021.01.07 加入

云原生技术社区为云原生技术实践联盟(CNBPA)旗下技术社区,专注泛云原生全栈云前沿技术和落地实践的布道。分享容器、Kubernetes、DevOps、Service Mesh、Serverless、数据库、中间件等技术干货。

评论

发布
暂无评论
金融云原生漫谈(五)|如何打造更适合云原生的数据存储方案?