当前，新一轮科技革命和产业变革方兴未艾，数字经济蓬勃发展，金融信息化进入数字化、智能化新时代。受服务实体经济角色定位、传统IT架构升级、业务模式数字化转型、顶层政策标准指引、金融信创需求驱动等因素的影响，金融行业上云进程不断加速，云原生架构演进之路将是金融IT演进 的必由之路。中间件作为作为业务层和IaaS层之间的支撑桥梁，也是实践云原生的核心设计理念的关键技术。

2020年，中原银行建成分布式缓存平台，以集约化管理分布式缓存服务，降本增效的同时可以节省资源、提高专业化管理水平，使得运维成本可控并且更易于管理。随着业务需求的持续增长，分布式缓存平台集群规模也在不断扩大，传统的虚拟机部署模式已经无法满足这种规模下的高效运维需求，Redis服务上云势在必行。然而不同于简单的无状态服务，Redis集群各个节点是有状态的，不能平滑地做容器化部署，需要去做复杂的适配工作。云原生技术Kubernetes Operator 可自定义很多常见且复杂操作，是管理拓扑结构复杂的有状态服务的理想方式，使用Kubernetes Operator 来进行Redis集群自动化运维和管理已成为趋势。

中原银行Redis Operator 实现了对哨兵集群的支持、Cluster模式的扩缩容支持、IP池支持、适配了认证中心、跨中心部署，同时将创建、编辑集群的操作集成到了我们管理端，使得集群创建、伸缩更为便捷，运行过程更为稳定。

Redis Operator 由两个部分组成：

1）自定义资源（Custom Resource Definition (CRD)）提供了一个新 API 对象和其定义描述的结构。

2）控制器(Controller)，在 Kubernetes 操作响应事件后，负责触发处理相关逻辑以修改资源状态。

图2. Redis Operator 工作流程

具体工作原理如下：

1）用户使用自定义资源定义 (CRD)向 Kubernetes 中增加关于他们应用程序特定类型的资源定义信息。

2）Kubernetes API Server将该信息存储在 etcd 存储库中，使得 Kubernetes Master 和所有其他进程都可以访问这些信息。

3）Redis Operator 轮询 API Server 上的 CRD，并对创建、更新和删除命令做出反应。

4）当一个新的自定义资源被创建时，Redis Operator 接收到通知并执行操作 (例如 创建相关联的 Statefulset) 以确保资源的正确状态。

5）如果自定义资源的定义更改了，Redis Operator 会检测到这一点并相应地更新相关的 Kubernetes 资源。

6）当用户要求 Kubernetes 删除自定义资源时，Redis Operator 将删除与此资源相关的所有 Kubernetes 资源，以确保所有资源都正确地维护和清理。

7）在自定义资源更新前，需调用缩容逻辑判断进行Slots迁移，同样地在自定义资源更新后需调用扩容逻辑判断。

简单来说，Redis Operator 通过 CRD 扩展 Kubernetes API ，并通过操作控制器来响应自定义资源上的事件。这使得用户可以更加方便地管理基于应用程序模式的服务生命周期，并简化了 Kubernetes 平台上操作管理的复杂性。

通过编写哨兵集群描述文件，我们可以轻松部署所需的哨兵集群。只需要按照哨兵集群的定义规范指定要求，然后将其提交到 Kubernetes 中即可实现快速、简单地部署。

图3. 哨兵集群定义

中原银行分布式缓存平台包含以下3个主要组件。

1）分布式缓存管理端：负责管理用户接入管理、集群状态的实时可视化监控面板、集群响应速度快速诊断定位能力、集群配置热更新能力、集群访问实时监控能力以及key的实时统计分析等能力。

2）分布式缓存Region-proxy组件： 负责转发业务系统请求以及管理端请求，简化跟Redis集群的交互流程，抽象层次更高、第三方不再关注Redis集群具体IP。

3）分布式缓存平台Redis Operator组件：负责维护Redis集群在Kubernetes 中的拓扑结构，监听来自用户以及其他关于集群的事件并进行响应处理。

缓存平台架构如图4所示，管理端实现了更高级别的抽象，无需关注集群节点的具体IP，通过每个区域中的Region-Proxy以及Operator实现集群的观测管理。

图4. 分布式缓存平台架构

只需要提供集群的抽象信息，包括 Namespace、Name 和集群类型，管理端就能快速发现集群中的节点。当需要扩展或缩小集群规模时，管理端可以感知节点变化并自动调整，无需再根据 IP 进行手动调整，这大大提高了运维效率。

图5. 导入集群示例

导入集群后，管理端可以通过 Region-proxy 和 Operator 收集集群信息并进行展示，如图6所示：

图6. 哨兵集群拓扑结构

同样，当导入 Cluster 集群时，管理端也可以自动进行识别。图7显示了一个三主三从集群的拓扑结构。

图7. Cluster集群3主3从

如图8所示，将集群规模调整为4主4从后，管理端会同步刷新集群结构。

图8. Cluster集群4主4从（3主3从扩容而来）

虚机部署和Operator部署对比如表1所示。

表1.虚机部署和Operator部署对比

在虚机部署中，我们需要处理版本上传、配置参数修改、节点启动、集群创建以及网络策略等繁琐步骤。如果采用 Operator 部署，则可以省去这些麻烦，只需要对 YAML 进行编辑和修改即可快速应用。此外，虚拟机部署的时间与节点数量成正比，而 Operator 不受节点数量影响。

中原银行Redis Operator 是一个用于部署和管理 Redis 集群的工具，其大大简化 了Redis 部署过程，能够实现Redis集群的快速部署。使用 Redis Operator 进行部署可以将部署时长从 60 分钟以上缩短至15 分钟以内。此外，Redis Operator 能够胜任大规模 Redis 集群的运维工作，并且可以自动发现和调整节点数量，极大地提高了运维效率。

随着云原生技术的发展，越来越多的互联网团队开始将Kubernetes作为新的重要基础设施。然而由于容器对外部基础环境的不感知和状态易失的特性，与有状态应用的管理似乎有天然的矛盾。Operator的出现，为“有状态应用容器化”提供了一个优雅的解决方案。Redis Operator 作为 Kubernetes Operator 的一个实际应用，证明了 Operator 相对于传统部署方式的优势和便利性。Redis Operator 把 Redis 集群的部署和管理逻辑封装成单独的组件，自动化地解决了一系列基础设施的问题，从而极大地简化了应用程序的部署和管理。在缓存这个重要服务领域，Redis Operator 能够大幅提升应用程序的可靠性和安全性，并减少故障率和安全漏洞，为用户创造更高效、更安全、更稳定的运维环境。

未来，我们将继续加强对 Kubernetes Operator 技术的深入研究和创新，探索更优异的 Redis Operator 解决方案，以满足用户对于自动化、安全性和稳定性的需求。此外，我们还将与社区合作和交流，共同推进 Operator 的标准化和规范化，加速它的发展和普及，让 Kubernetes Operator 成为云原生应用开发和管理的重要工具，为企业云原生演进之路添砖加瓦。