在金融行业数字化转型的驱动下，国有银行、股份制银行和各级商业银行也纷纷步入容器化的过程。
如果以容器云上生产为指标，那么整个容器云平台的设计、建设和优化对于银行来说是一个微小的挑战。如何更好地利用云原生技术，帮忙银行实现麻利、轻量、疾速、高效地进行开发、测试、交付和运维一体化，从而重构业务，推动金融科技的倒退，是个长期课题。
本期云原生漫谈，将和您一起探寻如何打造更适宜云原生的数据存储计划。
近年来，金融服务状态经验了微小的变动。线上业务的衰亡，带来了海量的数据接入和业务的不确定性。
数据系统治理弹性需要晋升、数据系统拜访查问需要晋升，对数据存储、解决、开掘的性能、稳定性、可靠性都提出了更高的要求。除此之外，金融企业 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 能力，是对数据服务（中间件、数据库）的进一步加强。
高并发状况下，如何实现故障疾速复原？
随着容器的一直成熟，不论是人工还是自动化开发运维都曾经有大量用户实际的案例，可能实现在高并发时刻的疾速扩容和故障复原。
除了通过存储保证数据一致性之外，倡议还能够思考进行：
- 利用的容器化革新，确保故障自愈。
- 利用的无状态化革新，确保弹性伸缩与故障自愈。
- 利用的微服务化革新，确保业务一致性，升高对数据库的要求，从而进一步升高存储一致性的要求。
通过上述革新，将传统的单体利用解耦，使与事务无关的业务逻辑并行运行，联合音讯队列 / 服务网格、关系型数据库等，针对不同业务需要，能够别离实现数据的最终一致性和强一致性，打造更适宜云原生的数据存储计划。