本章节对Datalink可以支持的【架构模式】做一下介绍,将列举一些典型架构场景(但datalink能支持的并不仅限于这些场景)

re-sharding

使用了【分库分表】技术后,数据的多维度查询是一个常见的棘手问题(如:打车场景下,订单以member_id做sharding后,需要解决以driver_id进行查询的需求;电商场景下,以买家ID做sharding后,需要解决以卖家ID进行查询的需求),借助Datalink我们可以将member维度的数据实时同步到driver维度,并在同步过程中进行ReSharding操作,这样,当通过driver_id进行查询时去对应维度的数据库进行查询即可。在我们的场景中,ReSharding是通过MysqlTaskReader+SddlTaskWriter实现的。

big-data

搭建大数据平台,第一步需要解决的就是数据来源的问题,目前借助Datalink提供的MysqlTaskReader、HbaseTaskReader和HdfsTaskWriter,我们可以将Mysql和HBase的数据实时同步到Hadoop中,然后在Spark中通过ETL任务对数据进行清洗和整合。当引入其它类型DB时,开发对应的TaskReader即可,有些DB做增量Reader插件难度可能会比较大,此时可以考虑使用DataX,做定时增量或定时全量,当然,还是优先使用实时增量最好,一是部署运维方便,二是实时性更高一些。超出Datlink的范畴,谈一下Datax,从大数据平台向外同步数据,我们基本上都是基于Datax来实现的,Sqlserver数据同步到大数据平台,也是使用的DataX,但目前正在考虑写一个增量版的SqlServerReader插件用来替换Datax-Job定时方案。

cqrs

这里套用一下CQRS这个名词,C代表【领域模型】,Q代表【查询模型】,【领域模型】强调的是规范化,以保证系统的高可扩展性,【查询模型】强调的是快速响应,以保证查询的高效性。系统越复杂,【领域模型】和【查询模型】能一起复用的概率就越低,所以现在很多的互联网应用都采用了CQRS架构,一级系统(即C端系统)基于领域模型执行交易,二级系统(即Q端系统)构建查询模型支撑查询,构建这样一个架构的核心关键就是数据同步,并且我们可以在数据同步的过程中进行模型转化,如过滤掉查询不用的数据、将多条数据合并成一条数据、将多个字段合并成一个字段等等,二级系统中还会针对查询场景做单独的索引优化等。

eda

同样套用一下EDA这个名词,系统间交互,除了RPC之外用的最多的便是消息了,一条条的消息就是一个个的事件,通过事件的传播和消费,不断驱动业务流程的演进,这是EDA的基本架构思想,目前大部分公司也都在使用这种架构模式。在EDA架构中,核心基础设施是MQ,核心设计工作是定义事件,在一些复杂场景必须去精心定义【领域事件】,但在很多简单场景下直接复用DB的事件模型即可(如:Mysql-Binlog的增、删、改Event),在Datalink中通过组合使用MysqlTaskReader + MQTaskWriter,实现把Mysql的【增删改Event】不断发送到Mq,就可以提供一套通用的EDA解决方案,来满足大部分场景的使用需求,并且数据一致性还可以轻松得到充分保证(自行设计的话很多团队应该都是显示调用API发送事件,这种方式不仅增加开发工作量,极端场景还存在事件漏发的情况)。基于DB的Log-Event-EDA,下面举几个例子:

• 获取到订单表插入事件时,触发短信通知,通知用户下单成功
• 获取到用户表修改或删除事件时,清空缓存服务器中该条数据对应的信息
• 当Datalink提供的通用功能无法满足使用需求时,业务应用也可以自己消费binlog实现自己的定制化需求

上面列举了Datalink可以支持的几个【架构模式】,其它的一些具体场景还有

• 基础参数共享
• 实时归档(只需在源端删数据即可,往归档库同步过程中将Delete-Event过滤掉)
• 数据镜像
• 支持迁库、拆库、合库
• 灾备
• 构建二级索引
• SearchBuild
• 等

场景是千变万化的,希望使用该产品的朋友可以发掘更多的架构模式和使用场景