2022-03-18 对于redis的operator的概要设计

目录

摘要:

需求分析:

一. 分布式数据库的面临的核心业务功能

1. 1  分布式数据库集群的组建

 1.2 分布式数据库的高可用, 也就是规格的保持, 核心组建是备库重建.

1.3  分布式数据库规格的调整, 扩容与缩容

二.  整体技术架构对开发流程及迭代速度的影响

产品迭代所面临的整个产品体系结构上的复杂性:

op服务所面临的复杂性:

三. 性能需求

3.1 内存占用

3.2 cpu占用

概要设计:

一. operator与数据库内核交互节点图:

说明:

二. operator组建redis-cluster集群及处理redis-cluster集群的高可用

说明:

三. 以修改redis集群密码为例, 说明使用operator的方式编写数据库实例, 可以节省的工作量

当前修改redis集群密码所要开发的工作量:

将operator与数据库内核结合组成实例的方式, 来修改redis集群的密码:

摘要:

此前云平台以上一任op组规划出的op服务, 作为代理k8s与上层业务交互的服务. 为加快业务迭代, 本文以operator为具体策略, 对此前的设计进行升级, 对一些不利于业务迭代的设计进行完善.

本文以redis数据库为具体例子, 提出以redis-operator来作为数据库实例与k8s交互间的作用层的设计.  目的有以下几个方面:

1.  减少数据库开发中仅起到接口转发的中间层, 减少开发者的工作量
2.  以云原生的方式进行业务与k8s层的交互, 使业务可以根据自己的需求快速实现, 而不需要依赖其他服务阻塞开发流程, 加快业务迭代速度
   1. 每个业务可以组成最小的迭代单元, 可快随迭代
   2.  可独立开发, 调试, 自测, 缩短整个迭代的周期
3.  将分布式数据库的业务实例中, 由于网络偶发故障造成的业务影响的范围, 降低到最小, 避免由于实例间通过网络接口交互造成的业务破坏
4.  便于后续的可维护性, 可扩展性
5.  使数据库内核的开发者可以将精力全部集中于分布式数据库本身,  集中突破数据库内核的性能和高可用问题, 实现公司数据库产品的核心竞争力, 超越业界其他产品
6.  便于上层业务快速迭代, 业务迭代与数据库核心设计分离, 使用户购买的实例可长期使用, 而非因为上层业务的调整造成必须升级用户的产品