摘要：

云原生是一个不断丰富的理念和技术体系，它在基础架构、应用程序和管理上都将深刻的影响和改变企业云的未来！近年来，在证券行业数字化转型的驱动下，证券行业云原生实践已从试用阶段步入到大规模推广阶段，企业业务在转向微服务、容器化的建设，带来了海量的数据接入和业务的不确定性。数据系统管理弹性需求提升、数据系统访问查询需求提升，对数据存储、处理、挖掘的性能、稳定性、可靠性都提出了更高的要求。此过程中为有状态应用提供持久、高可靠和高性能的存储成为了一项挑战。除此之外，证券企业IT还要建立数据“敏态引擎”，不仅要通过统一的智能化编排系统配合业务上线，快速实现其敏态业务，而且利用存储系统自身的自动化运维能力夯实稳态业务，打造券商业敏稳双态引擎，助力企业快速转型与发展。全篇共分为二部分：《需求路线选择分析篇》、《技术架构与实现篇》，希望能为同行带来参考价值。

1、K8S存储系统

提及云原生容器存储必然先了解CSI/PV/PVC/StorageClass的几个基本概念。K8s 存储卷是一个集群级别的概念，其对象作用范围是整个 K8s 集群，而不是而一个节点；K8s 存储卷包含一些对象（PVC、PV、SC），这些对象和应用负载（Pod）是独立，通过编排模板进行关联；K8s 存储卷可以有自己的独立生命周期，不依附于 Pod。

1.1 CSI

CSI英文全称是Container Storage Interface，是容器编排系统（COS）上通用的容器存储接口，第三方存储厂商可以通过编写CSI插件来将其文件存储和块存储提供给K8S上容器化的工作负载，而无需修改K8S的核心代码。K8S作为事实上的容器编排（CO）标准，对CSI持久化存储接口的支持已经可以商用。K8S的V1.13版本已经支持了GA版本的CSI组件。目前K8S主要持久化存储主要通过该标准接口进行对接。绝大部分Out-tree存储类型已替代In-tree存储类，out-tree的volume插件不侵入K8S的核心源码，更加灵活。存储供应商可以自己定制适配于自己产品volume插件。CSI就是属于out-tree的volume插件，CSI的生产级应用也越来越成熟。

在Pod创建过程中，通过指定创建外部卷存储，PVC通过StorageClass的动态供给生成对应绑定的PV，PV的创建与绑定由CSI来进行。这时候CSI就可以自己定义如何加载一个卷，如何挂载一个卷。

1.2 PV以及PVC

PV 是 PersistentVolume 的缩写，译为持久化存储卷；PV 在 K8s 中代表一个具体存储类型的卷，其对象中定义了具体存储类型和卷参数。即目标存储服务所有相关的信息都保存在 PV 中，K8s 引用 PV 中的存储信息执行挂载操作。PV accessModes：支持四种类型，ReadWriteMany、ReadWriteOnce、ReadOnlyMany和ReadWriteOncePod。这里定义的访问模式只是编排层面的声明，具体应用在读写存储文件的时候是否可读可写，需要具体的存储插件实现确定。PV的PersistentVolumeReclaimPolicy也有三种策略，这个策略是当与之关联的PVC被删除以后，这个PV中的数据如何被处理，他们分别是：Retain、Recycle和Delete。定义PV属性有如下字段：

• accessModes：存储卷的访问模式，支持：ReadWriteOnce、ReadWriteMany、ReadOnlyMany 三种模式；具体含义同 PVC 字段；
• capacity：定义存储卷容量；
• persistentVolumeReclaimPolicy：定义回收策略，即删除 pvc 的时候如何处理 PV；支持 Delete、Retain 两种类型，动态数据卷部分会详细说明此参数；
• storageClassName：表示存储卷的使用的存储类名字，动态数据卷部分会详细说明此参数；
• volumeMode：同 PVC 中的 volumeMode 定义；
• Flexvolume：此字段表示具体的存储类型，这里 Flexvolume 为一种抽象的存储类型，并在 flexvolume 的子配置项中定义了具体的存储类型、存储参数。

PVC 是 PersistentVolumeClaim 的缩写，译为存储声明；PVC 是在 K8s 中一种抽象的存储卷类型，代表了某个具体类型存储的数据卷表达。其设计意图是：存储与应用编排分离，将存储细节抽象出来并实现存储的编排（存储卷）。K8s 中存储卷对象独立于应用编排而单独存在，在编排层面使应用和存储解耦。PVC 定义的存储接口包括：存储的读写模式、资源容量、卷模式等。定义PVC属性主要有如下字段：

• storage：定义此 PVC 对象期望提供的存储容量，同样此处的数据大小也只是编排声明的值，具体存储容量要看底层存储服务类型。
• volumeMode：表示存储卷挂载模式，支持 FileSystem、Block 两种模式；
• FileSystem：将数据卷挂载成文件系统的方式供应用使用；
• Block：将数据卷挂载成块设备的形式供应用使用。

PVC 和 PV 总是成对出现的，PVC 必须与 PV 绑定后才能被应用（Pod）消费；PVC 和 PV 是一一绑定关系，不存在一个 PV 被多个 PVC 绑定，或者一个 PVC 绑定多个 PV 的情况；PVC 是应用层面的存储概念，是属于具体的名词空间的；PV 是存储层面的存储概念，是集群级别的，不属于某个名词空间；PV 常由专门的存储运维人员负责管理；消费关系上：Pod 消费 PVC，PVC 消费 PV，而 PV 定义了具体的存储介质。

PVC 只有绑定了 PV 之后才能被 Pod 使用，而 PVC 绑定 PV 的过程即是消费 PV 的过程，这个过程是有一定规则的，下面规则都满足的 PV 才能被 PVC 绑定：

(1) VolumeMode：被消费 PV 的 VolumeMode 需要和 PVC 一致；
(2) AccessMode：被消费 PV 的 AccessMode 需要和 PVC 一致；
(3) StorageClassName：如果 PVC 定义了此参数，PV 必须有相关的参数定义才能进行绑定；
(4) LabelSelector：通过 label 匹配的方式从 PV 列表中选择合适的 PV 绑定；
(5) storage：被消费 PV 的 capacity 必须大于或者等于 PVC 的存储容量需求才能被绑定。

满足上述所有需要的 PV 才可以被 PVC 绑定。如果同时有多个 PV 满足需求，则需要从 PV 中选择一个更合适的进行绑定；通常选择容量最小的，如果容量最小的也有多个，则随机选择。如果没有满足上述需求的 PV 存储，则 PVC 会处于 Pending 状态，等待有合适的 PV 出现了再进行绑定。

应用负载、PVC、PV 三者关系非常明确。从实现上看，只要有了 PV 既可以实现存储和应用的编排分离，也能实现数据卷的挂载。为何要用 PVC + PV 两个对象呢？K8s 这样设计是从应用角度对存储卷进行二次抽象；由于 PV 描述的是对具体存储类型，需要定义详细的存储信息，而应用层用户在消费存储服务的时候往往不希望对底层细节知道的太多，让应用编排层面来定义具体的存储服务不够友好。这时对存储服务再次进行抽象，只把用户关系的参数提炼出来，用 PVC 来抽象更底层的 PV。所以 PVC、PV 关注的对象不一样，PVC 关注用户对存储需求，给用户提供统一的存储定义方式；而 PV 关注的是存储细节，可以定义具体存储类型、存储挂载使用的详细参数等。使用时应用层会声明一个对存储的需求（PVC），而 K8s 会通过最佳匹配的方式选择一个满足 PVC 需求的 PV，并与之绑定。所以从职责上 PVC 是应用所需要的存储对象，属于应用作用域（和应用处于一个名词空间）；PV 是存储平面的存储对象，属于整个存储域（不属于某个名词空间）。

1.3 静态、动态存储卷

基于上述我们了解到，PVC 是针对应用服务对存储的二次抽象，具有简洁的存储定义接口。而 PV 是具有繁琐存储细节的存储抽象，一般有专门的集群管理人员定义、维护。而我们在云原生存储管理中，根据 PV 的创建方式可以将存储卷分为动态存储和静态存储卷。静态存储卷由管理员创建的PV，动态存储卷则是由 Provisioner 插件创建的PV。

动态存储卷和静态存储卷最终的效果都是：Pod -> PVC -> PV 的使用链路，且对象的具体模板定义都是一致的；动态存储卷和静态存储卷区别是：动态卷是插件自动创建 PV，而静态卷是集群管理员手动创建 PV。提供动态存储卷的优势在于能让 K8s 实现了 PV 的自动化生命周期管理，PV 的创建、删除都通过 Provisioner 完成；自动化创建 PV 对象，减少了配置复杂度和系统管理员的工作量；动态卷可以实现 PVC 对存储的需求容量和 Provision 出来的 PV 容量一致，实现存储容量规划最优。

2 证券行业云原生存储方案

云原生存储面临着信创大背景要求以及基于目前存储能力，新一代无损存储网络在券商行业悄然而至。RoCE将成为国内未来存储的发展趋势，为存储传输效率提高百分之50以上，特别适合金融AI模型训练、大数据、大模型等场景，它不仅能满足应用大数量，还可以应对大量微突发数据需求等等。

采用社区的 ROOK + Ceph 存储方案进行深度定制，实现了一个自动管理的、自动扩容的、自动修复的分布式存储服务。基于 Ceph 提供统一存储，包括文件存储，块存储、对象存储，优点很明显：

• 支持存算一体/存算分离两种部署模式
• 提供图形化方式配置和自动部署存储集群和存储管理服务
• 分布式和多副本机制保障数据安全可靠
• 简单可靠的自动化管理，快速扩容存储资源
• 提供弹性和高性能存储服务
• 支持可视化的容量和性能监控，便于日常运维和管理
• 提供持久卷快照备份和克隆新卷功能

本地存储是一种软件定义的服务器本地存储方案，提供简单、易维护和高性能的本地存储服务能力。基于社区的 TopoLVM 方案，通过系统的 LVM 方式来实现本地存储的持久卷编排管理。TopoLVM能投提供：

• 基于 TopoLVM 提供云原生架构的本地存储方案
• 提供与本地磁盘一致的零损耗高性能存储
• 支持通过 Operator 图形化快速部署
• 支持动态创建 PVC，持久卷动态扩容
• 配合 Kubernetes 实现自动定点部署配置
• 提供持久卷快照备份和克隆新卷功能

TopoLVM、Rook-Ceph、商业存储（需支持CSI接口标准）等都支持云原生存储建设。TopoLVM，一个用于本地存储的新CSI插件，可使用LVM动态配置卷。它实现了动态卷配置，原始块卷，文件系统指标，并将实现在线卷大小调整和临时卷。具备简单、方便、成本低等优势，但是很明显其监、管、控方便还不到位。Ceph是一款开源，高度可扩展的分布式存储解决方案，用于有多年生产的块存储，共享文件系统和对象存储。Rook-Ceph框架，虽然在一定程度上帮助减轻管理负担，但是其ceph的短板还是存在，而且多了一层Rook Operator这一层技术栈，同样是增加了使用成本以及故障点，推荐作为创新内容推进。选择使用商业存储，是将专业的事情交给专家处理。

使用云原生平台时，用户往往需要共享使用 Kubernetes 集群（多租户），以在满足多团队、多客户需求的同时简化运维、降低成本。虽然 Kubernetes 本身不直接提供多租户功能，但它提供了一系列可被用于支持实现多租户的功能。以租户粒度，进行资源隔离与管理、用户鉴权、特性管理等。云原生存储也应与租户权限机制相结合。因云原生是一种以应用为中心的软件开发方法，为实践者提供了一条高效、能够以可扩展、可复制的方式最大化利用云的能力、发挥云的价值的最佳路径，券商企业也需不断提升自身软件研发能力，方可构建像互联网公司一样敏捷弹性、快速试错、急速创新的IT交付模式。

云原生架构中的微服务和容器可以独立地扩展和缩减，以适应流量的变化。此外，云原生架构还支持多种编程语言和框架，可以灵活选择适合自己的技术栈，其高度的拓展性以及敏捷性，塑造在云原生应用集群高可用方面，根据业务的特点，如果业务读写请求要求不高，可采用“以漂代切”实现，以POD漂移替代主从切换，单副本替代多副本，而且可用性不降级；如果业务对数据库的读写等性能压力要求较高，连接数和并发量要求都比较高的需求下，可以采用主从集群模式，实现读写分离，支持个性化的数据初始化设计，以及强数据一致性。

传统MySQL高可用方案是完全依靠中间件做故障检测和主从切换，拉起时间与主从节点数据差异强相关；然而云原生数据库高可用方案中，由于K8S原生极致的漂移能力，其数据库拉起时间受限于StatefulSetSet模式自身机制，当需手动删除故障Node，将中间件与存储CDR结合，由存储发起故障POD的快速漂移，实现单副本模式下30s内HA切换。

云原生同城双活也可参考“以漂代切”思路来达到应用同城漂移，前提是结合存储双活能力，搭配云原生快速切换能力，从而实现跨集群恢复时间快于主从切换。目前我司投行数字化管理平台数据库基于“以漂带切”方式代替主从模式，在数据中心A集群和数据中心B集群都分别有部署，上次通过负载均衡实现应用流量及时切换。但如我司开源治理系统的数据库采用的时数据库主从模式，满足业务读写分离场景需求，且保证数据层面在同集群多数据副本的一致性。

云原生建设以应用粒度为主线，聚焦应用多中中心改可用、稳定、可靠等方面。方可打造证券企业云原生平台灾备运维双平面竞争力。企业级华为存储如何助力云原生多存储灾备一体化建设的呢？首先通过独立部署DME，提供基于容器全局搜索、端到端TOPO和性能分析能力。其次是DME统一纳管华为存储，为容器提供存储服务（块、文件和对象）按不同SLA池化发放，并支持存储池监控和配额管理。DME对接私有云云管平台，实现针对华为存储的池化发放、端到端TOPO和性能分析能力。最后DME通过和存储统一管理平台对接，纳管异构存储，实现三方存储池SLA发放、端到端 TOPO和性能分析能力。​

基于华为BCManager工具，可实现云原生应用细粒度eReplication复制，借助eBackup 完成应用数据在对端存储备份，实现业务在目标端环境快速拉起。

3 企业数字化转型技术核心

云原生的敏捷部署和交付、更高的可靠性和容错性、更高的可扩展性和灵活性、更高的安全性。这种种面向未来的架构模式，可以帮助企业构建高效、可靠、灵活和安全的应用生态系统。从应用架构的角度，云原生可以方便地支持微服务架构实现应用的现代化，更加灵活的应对变化和弹性扩展。在软件生命周期管理上面，云原生技术可以帮助把DevOps等最佳实践落地成可运用的标准化工具和框架，大大提升开发效率，加速迭代，帮助开发者和企业更便捷的上云和迁云，让应用在自有数据中心和云端实现动态迁移。

点击阅读第一篇：《需求路线选择分析篇》

本文协作专家：
王通-某证券公司-技术总监
黄庆-某证券公司 -资深工程师
刘明昭-某金融公司-技术工程部
蔡炯桐-某证券公司-系统工程师
黎果-某银行-项目经理

本文顾问专家
王帅-某证券公司-存储工程师