我正在设计一个微服务架构的评论分析平台。
申请表如下;
我有3个微服务。
问题在某些时候，验证服务需要获取site-a的所有评论，应用验证规则并生成错误（如果有的话）。我知道共享数据库模式和实体打破了微服务架构。
一种可能的解决方案是
这种方法的两个可能的缺点是
那么在没有
的情况下在微服务之间共享大量数据的最佳实践是什么？我阅读了很多关于使用消息传递队列的内容，但我认为在我的情况下使用消息队列来共享千兆字节的数据并不好。
编辑1：使用带有rest API的数据存储可以解决问题，而不是共享实体吗？假设我使用mongodb，而不是在微服务之间共享我的实体对象，我可以使用mongo（http://restheart.org/）的rest接口并尽可能地查询数据。
答案 0 :(得分：5)
这里的问题不是＆＃34;共享大量数据＆＃34;，而是您选择基于的微服务分离的边界。
我可以从您的要求中看出，您选择分离的3个微服务（评论，验证，导入/导出）实际上是在相同的上下文和业务领域运行..这就是评论。
我建议您重新考虑您的设计决策，并将评论视为一项微服务，将所有评论操作和逻辑作为黑匣子处理。
答案 1 :(得分：0)
我认为评论是相互独立的，因此验证评论只需要审核，而不需要其他评论。
您不希望共享实体，这些实体排除了共享数据库，Hadoop集群或Redis等数据存储之类的内容。您也不想复制数据，从而在数据库级别上排除普通文件副本或基于触发器的复制。
总之，我会说你的目标应该是一个流。让Validator从关于站点A的评论请求所有内容，但不是在一个批量中，而是在单个或小型评论包的流中。
验证器现在可以在恒定的内存和处理器消耗下一个接一个地处理评论。为了获得性能，您可以创建Validator的多个实例，这些实例同时提取流的不同的，不相关的部分。同样，你可以创建评论微服务的多个实例，如果单独一个人无法足够快地回答这个问题。
Validator不会保留此流，它只生成错误并将其存储或发送到某处;这应该满足您的不共享无重复要求。