微服务需要聚合工程吗_微服务数据聚合CQRS

微服务思考

微服务经常是按业务维度划分多个服务(当然还有其他各种考虑维度), 划分为多个维度后, 好处自然很多, 其中也会有一些问题, 比如我们讲的数据依赖问题

比如前端要展示一个商品详情页面, 不仅依赖商品服务、还需要依赖库存服务、评分服务等等, 那么谁来对接这套服务呢?

在我们划分众多微服务的同时, 在这些微服务的上层肯定要有一层专门提供给前端聚合数据, 我们通常称为 BFF(Back-end For Front-end), 服务于前端的后端服务, BFF功能是根据业务需求经常变化调整的

数据 JOIN 问题

普通的用户按这种方式是没有问题的, 每个服务独占一个数据资源, 之间互不影响, 举例如果为运营后台数据查询聚合的时候, 这种在数据资源独立的情况下, 需求实现起来是非常困难的.

通常我们采用数据分发预聚合方式来满足此类需求, 将资源聚合到 mysql、mongo、redis、es提供查询。其实这也是我们常说的 CQRS 模式

我们看下面两种预聚合的方式:

1.事务性发件箱

此模式对业务是有一定的侵入性的, 上图是在插入业务表后, 同时将对应事件记录插入到发件箱表中, Relay任务会定时读取 发件箱表, 推送给对应消费者, 存入对应仓库。

2.变更事件捕获 ( CDC )

是指捕获mysql binlog或mongo oplog等日志变更记录, 此方式对业务没有侵入, 但是业务运维难度较高.

Command Query Responsibility Segregation ( CQRS )

上面我们提到了一下 CQRS, 简单描述的话可以理解为资源的读写分离, 其实在工作中这种模式是非常常见的.

通过各个服务写入->数据聚合到ES、REDIS等->数据中心读取

这种方式写入和读取拆分成了两种数据资源, 带来的好处是更容易和更灵活满足业务需求, 降低对原服务的影响. 当然也扩大了数据不一致性的时间窗口, 需要从上层用户体验设计上去配合支持这种系统(比如异步通知等)

资料分享

https://martinfowler.com/bliki/CQRS.html