需求背景
系统有数据识别、数据脱敏逻辑,支持可配置规则,自定义等,需要进行异构数据同步,大数据量。现在针对以下几个需求进行讲解
1、支持冗余设计 2、支持任务自动分发,支持自动负载均衡 3、支持随时扩容节点而无需关停原有的系统和业务
架构和模块
架构图
五核心模块及其主要功能
-
调度平台
- 使用Nginx方式来调用数据中心,通过注册中心获取数据中心的服务列表
- 可以合理的根据数据同步的情况,去调用服务;比如数据同步可能存在的顺序性,执行延时;
- 读取控制台DB的配置信息,定时执行数据同步任务
- 对数据同步的调用,可以按照简单的轮询方式,也可以根据数据同步服务器的性能情况,进行负载均衡
-
数据同步
- 负责执行数据库异构数据同步任务,可支持增量,全量模式,用DataX框架来实现
- 服务于调度平台的调用
- 会存储数据同步的执行结果,供控制台进行展示
- 会上报服务器的性能指标到数据同步DB,以供调度平台参考
-
控制台
- 配置管理界面,服务于用户进行数据同步任务的配置信息,并存储到控制台DB中;
-
数据识别
- 负责针对数据库的数据进行数据识别任务
-
数据脱敏
- 按照内置规则、自定义配置,负责脱敏数据
- 可提前进行数据脱敏,以供数据同步转换环节调用
三个辅助服务发现模块
- 注册中心
- 用于服务发现和注册
- 数据同步注册实例并定期报心跳
- 可以用zookeerper来实现
- 调度平台通过域名访问注册中心获取数据同步的地址列表
- Nginx
- 和域名系统配合,协助调度平台访问注册中心获取数据同步地址列表
- 和域名系统配合,协助用户访问控制台进行配置管理
可用性分析
高可用通过Nginx、注册中心来实现,可以支持动态扩容。每个主要模块都是以无状态集群方式部署的,各自模块都可以通过注册中心来实现服务注册,模块之间的调用服务发现来获取,并以域名方式实现。
考虑到扩展,所以设想的方案是尽可能的做到每个服务职责单一。
这样的拆分,也是考量到每个环节的瓶颈都不一样,目前预估不是很精确,这样可以为后续扩展提供方便性。
数据脱敏、数据识别需要单独独立出来,原因:本身的服务不在数据同步中,可能提前预处理进行。
通过集群部署方式,支持冗余设计。
调度平台、Nginx集群通过数据同步性能情况,实现任务自动分发,支持自动负载均衡。
可用性分析
可用性表格分析
场景 | 影响 | 降级 | 原因 |
---|---|---|---|
某台数据同步下线 | 无影响 | - | 数据同步无状态,调度平台重连其他的数据同步服务。 |
所有数据同步下线 | 调度平台无法执行数据同步任务 | 控制台正常运行;调度平台把数据同步任务放入执行队列,等待执行 | - |
某个Nginx下线 | 无影响 | - | 多Nginx部署,数据完全同步,注册中心、控制台域名通过SLB自动切换到其他存活的Nginx |
控制台DB宕机 | 调度中心无影响,控制台无法更新配置 | 调度平台开启配置缓存后,对配置的读取不受数据库宕机影响 | |
某台数据识别、数据脱敏下线 | 无影响 | - | 数据识别、数据脱敏无状态,数据同步重连其他的数据识别、数据脱敏同步服务 |
全部数据识别、数据脱敏下线 | 无影响 | - | 数据同步可执行在线脱敏功能,会影响任务时长。 |
结论
数据同步、控制台、调度平台、数据识别、数据脱敏是数据脱敏的几大核心微服务模块,相互协作完成配置中心业务功能,Nginx、注册中心是辅助微服务之间进行服务发现的模块。
采用微服务架构设计,架构和部署(部署方式可以用容器思路来操作)都有一些复杂,但是每个服务职责单一,易于扩展。