在微服务之间共享大量数据

时间:2016-04-21 16:42:08

标签: microservices

我正在设计一个微服务架构的评论分析平台。

申请表如下;

  • 从ecommerce-site-a(site-a)检索的所有产品评论为excel文件
  • 评论上传到使用excel的系统
  • 分析代理可以列出所有评论,编辑部分评论,删除或批准
  • 分析代理可以导出site-a的所有评论
  • 自动基于正则表达式的检查适用于每次上传和编辑审核。

我有3个微服务。

  • 评论:负责审核Crud操作以及类似于批准/拒绝的操作..
  • 验证:负责在审核时定义和应用验证规则。
  • 导出/导入:导出服务导出给定站点名称的巨大文件(如site-a)

问题在某些时候,验证服务需要获取site-a的所有评论,应用验证规则并生成错误(如果有的话)。我知道共享数据库模式和实体打破了微服务架构。

一种可能的解决方案是

  • 每当验证服务要求对网站进行审核时,它都会请求网关,网关将请求重定向到评论服务并采取响应。

这种方法的两个可能的缺点

  • 验证服务知道关于网关?它会带来依赖吗?
  • 如果我有一个网站的1b评论,通过休息请求获得所有评论可能是一个问题。 (或者,我可以从验证服务到网关进行分页请求。)

那么在没有

的情况下在微服务之间共享大量数据的最佳实践是什么?
  • 分享实体
  • 和出版数据

我阅读了很多关于使用消息传递队列的内容,但我认为在我的情况下使用消息队列来共享千兆字节的数据并不好。

编辑1:使用带有rest API的数据存储可以解决问题,而不是共享实体吗?假设我使用mongodb,而不是在微服务之间共享我的实体对象,我可以使用mongo(http://restheart.org/)的rest接口并尽可能地查询数据。

2 个答案:

答案 0 :(得分:5)

这里的问题不是"共享大量数据",而是您选择基于的微服务分离的边界。

我可以从您的要求中看出,您选择分离的3个微服务(评论,验证,导入/导出)实际上是在相同的上下文和业务领域运行..这就是评论。

我建议您重新考虑您的设计决策,并将评论视为一项微服务,将所有评论操作和逻辑作为黑匣子处理。

答案 1 :(得分:0)

我认为评论是相互独立的,因此验证评论只需要审核,而不需要其他评论。

您不希望共享实体,这些实体排除了共享数据库,Hadoop集群或Redis等数据存储之类的内容。您也不想复制数据,从而在数据库级别上排除普通文件副本或基于触发器的复制。

总之,我会说你的目标应该是一个流。让Validator从关于站点A的评论请求所有内容,但不是在一个批量中,而是在单个或小型评论包的流中。

验证器现在可以在恒定的内存和处理器消耗下一个接一个地处理评论。为了获得性能,您可以创建Validator的多个实例,这些实例同时提取流的不同的,不相关的部分。同样,你可以创建评论微服务的多个实例,如果单独一个人无法足够快地回答这个问题。

Validator不会保留此流,它只生成错误并将其存储或发送到某处;这应该满足您的不共享无重复要求。