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