当前位置:首页 > 运营 > 正文

秃头也要学习的微服务进阶场景实战基于Bifrost的数据同步方案

基于Bifrost的数据同步方案

技术选型

项目组决定找一个开源中间件,它需要满足以下5点要求。

1)支持实时同步。

2)支持增量同步。

3)不用写业务逻辑。

4)支持MySQL之间的同步。

5)活跃度高。

根据这些要求,可以选用以下几个开源中间件:Canal、Debezium、DataX、Databus、Flinkx、Bifrost。

秃头也要学习的微服务进阶场景实战基于Bifrost的数据同步方案  第1张

• 图14-5 Bifrost架构图

可以看出,Bifrost其实也是模拟成MySQL的从库,监听源数据库的Binlog,然后再同步到目标数据库。它支持多种目标数据库,本项目是从MySQL同步到MySQL。

注意事项

使用数据同步这个方案时,应该注意什么?

1.数据同步的延时

这个数据同步方案是有一定延时的,所以如果业务对同步功能有高时效的要求,那么尽量不要使用这个方案。

举个例子,这里虽然同步了商品的数据到订单数据库,但是订单服务当中,如果提交订单需要检查库存的话,不建议把库存数据同步到订单数据库里,而是让订单服务每次都去请求商品数据库的库存。

所以,其实同步过来的数据基本上只是用来展示、查询的,不涉及业务数据变更。

2.同步过来的数据是只读的

因为这里的数据同步是单向的,所以目标数据库中同步过来的数据是不能修改的。在这个方案里,肯定不会去修改订单数据库里面同步过来的商品数

据。也有一些其他场景,比如同步一些基础配置或者公用数据到各个数据库,而后在使用这些同步数据时,可能会发现一些遗漏,比如城市/区/县数据,这种情况下,也不能直接在业务数据库里修改,而是应该通知提供数据的系统去修改,之后再同步过来。

3.监控一定要到位

Bifrost不是高可用的,它本身也提供了一些告警的功能。除了依赖它本身的告警功能以外,还要额外监控Bifrost这个服务的状态,确保它出现异常时能及时发现。Bifrost本身也提供了API接口,用来让第三方的监控对接。

4.核心逻辑不建议依赖同步数据

因为同步过来的数据是有延时的,并且Bifrost本身没有设计高可用,所以并不推荐在核心逻辑上使用同步的数据。

小结

系统上线后,商品数据的同步比较稳定。之后,商品服务的开发人员只需要关注自己的逻辑,无须关注使用数据的人。如果需要关联使用商品数据的采购单,采购服务的开发人员也不需要关注商品数据的同步问题,只需要在查询时加上关联语句即可,算是一个双赢的结局。

唯一遗憾的是Bifrost不是集群,无法应对高可用场景。不过,到目前为止,这个系统还没有出现宕机的情况,反而是那些部署多台节点负载均衡的后台服务常常出现这种情况。

Bifrost 的 作 者 也 介 绍 了 他 为 什 么 没 有 设 计 集 群(https://wiki.xbifrost.com/other/clusterwhynot/),部分引用如下。

在实际工作中,项目组很大一部分时间其实都是在处理线上高可用、分布式遇到的各种问题。

工作经验告诉我们,很多开源系统的高可用可能并不是我们想象中的那样高可用,尤其是那些对数据一致性有要求的场景,会存在很多问题。

在实际工作中,绝大多数一开始就使用各种分布式、高可用设计的项目,最后都失败了。

功能很多,又使用分布式和高可用,很难排查问题。

Bifrost是一个面向生产环境的产品,对生产环境抱有敬畏之心。

Bifrost并不想在一个项目刚开始的时候,就进行各种分布式、高可用等设计。

这些描述不一定准确,但是笔者的确碰到过两次“高可用最终并不是真正的高可用”的情况,所以那时候就想在系统当中引入一个非高可用的中间件进行尝试。当然,为了保证系统出错以后能够及时解决,也做了很多定制的监控。

事实证明,高可用不一定真的高可用,单机也未必不能高可用。当然,也不能以偏概全地说高可用设计没有必要,那就因噎废食了,这种状况毕竟只是特例。而且,项目组也随时准备着改造这个中间件,增加灾备能力。不管怎么样,项目组最终解决了服务之间数据依赖的问题。接下来,就要直接面对服务之间逻辑或流程上依赖的问题了。

本文给大家讲解的内容是微服务进阶场景实战:基于Bifrost的数据同步方案下篇文章给大家讲解的内容是微服务进阶场景实战:BFF觉得文章不错的朋友可以转发此文关注小编;感谢大家的支持!!
取消
扫码支持 支付码