微服务-数据聚合CQRS

微服务常常是按业务维度划分多个服务(固然还有其余各类考虑维度), 划分为多个维度后, 好处天然不少, 其中也会有一些问题, 好比咱们讲的数据依赖问题html

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

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

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

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

咱们看下面两种预聚合的方式:后端

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

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

上面咱们提到了一下 CQRS, 简单描述的话能够理解为资源的读写分离, 其实在工做中这种模式是很是常见的.异步

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

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