数据脱敏大数据架构设计

需求背景

系统有数据识别、数据脱敏逻辑，支持可配置规则，自定义等，须要进行异构数据同步，大数据量。如今针对如下几个需求进行讲解

一、支持冗余设计 二、支持任务自动分发，支持自动负载均衡 三、支持随时扩容节点而无需关停原有的系统和业务

架构和模块

架构图

五核心模块及其主要功能

• 调度平台

  • 使用Nginx方式来调用数据中心，经过注册中心获取数据中心的服务列表
  • 能够合理的根据数据同步的状况，去调用服务；好比数据同步可能存在的顺序性，执行延时；
  • 读取控制台DB的配置信息，定时执行数据同步任务
  • 对数据同步的调用，能够按照简单的轮询方式，也能够根据数据同步服务器的性能状况，进行负载均衡

• 数据同步

  • 负责执行数据库异构数据同步任务，可支持增量，全量模式，用DataX框架来实现
  • 服务于调度平台的调用
  • 会存储数据同步的执行结果，供控制台进行展现
  • 会上报服务器的性能指标到数据同步DB，以供调度平台参考

• 控制台

  • 配置管理界面，服务于用户进行数据同步任务的配置信息，并存储到控制台DB中；

• 数据识别

  • 负责针对数据库的数据进行数据识别任务

• 数据脱敏

  • 按照内置规则、自定义配置，负责脱敏数据
  • 可提早进行数据脱敏，以供数据同步转换环节调用

三个辅助服务发现模块

• 注册中心
  • 用于服务发现和注册
  • 数据同步注册实例并按期报心跳
  • 能够用zookeerper来实现
  • 调度平台经过域名访问注册中心获取数据同步的地址列表
• Nginx
  • 和域名系统配合，协助调度平台访问注册中心获取数据同步地址列表
  • 和域名系统配合，协助用户访问控制台进行配置管理

可用性分析

高可用经过Nginx、注册中心来实现，能够支持动态扩容。每一个主要模块都是以无状态集群方式部署的，各自模块均可以经过注册中心来实现服务注册，模块之间的调用服务发现来获取，并以域名方式实现。

考虑到扩展，因此设想的方案是尽量的作到每一个服务职责单一。

这样的拆分，也是考量到每一个环节的瓶颈都不同，目前预估不是很精确，这样能够为后续扩展提供方便性。

数据脱敏、数据识别须要单独独立出来，缘由：自己的服务不在数据同步中，可能提早预处理进行。

经过集群部署方式，支持冗余设计。

调度平台、Nginx集群经过数据同步性能状况,实现任务自动分发，支持自动负载均衡。

可用性分析

可用性表格分析

场景	影响	降级	缘由
某台数据同步下线	无影响	-	数据同步无状态，调度平台重连其余的数据同步服务。
全部数据同步下线	调度平台没法执行数据同步任务	控制台正常运行；调度平台把数据同步任务放入执行队列，等待执行	-
某个Nginx下线	无影响	-	多Nginx部署，数据彻底同步，注册中心、控制台域名经过SLB自动切换到其余存活的Nginx
控制台DB宕机	调度中心无影响，控制台没法更新配置	调度平台开启配置缓存后，对配置的读取不受数据库宕机影响
某台数据识别、数据脱敏下线	无影响	-	数据识别、数据脱敏无状态，数据同步重连其余的数据识别、数据脱敏同步服务
所有数据识别、数据脱敏下线	无影响	-	数据同步可执行在线脱敏功能，会影响任务时长。

结论

数据同步、控制台、调度平台、数据识别、数据脱敏是数据脱敏的几大核心微服务模块，相互协做完成配置中心业务功能，Nginx、注册中心是辅助微服务之间进行服务发现的模块。

采用微服务架构设计，架构和部署（部署方式能够用容器思路来操做）都有一些复杂，可是每一个服务职责单一，易于扩展。