金融云原生漫谈（五）｜如何打造更适合云原生的数据存储方案？

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

首先，容器云平台的底座主流是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 工作负载有以下特性：

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

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

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

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

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

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

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