许多人建议组织 IPC (ImicroservicesC) 的好方法是通过 Kafka 和 JMS 等查询进行异步通信。
但是如果我需要在服务之间传递大型数据文件怎么办？
假设我有一个视频微服务和一个发布者微服务。第一个接收来自用户的视频，验证并将其发送到发布者进行转换和发布。它的不经意视频可能是一个非常大的文件，并且可能会使消息系统重载(Kafka根本不适合大消息)。当然，我可以为他们共享一个数据库并通过 Kafka 发送 video_id，但它耦合了这些服务，它不再是真正的微服务架构。
您在实践中是否也遇到过类似的情况？你如何处理？
谢谢
最佳答案
Hohpe/Wolfe 的书中有一个企业集成模式，名为 Claim Check Pattern解决了这些问题。
本质上，大 blob 会从消息中删除，并存储在发送者和接收者都可以访问的位置，无论是公共(public)文件共享、FTP 服务器、Amazon S3 blob，还是其他什么。它留下了一个“声明检查”:某种描述如何找回 blob 的地址。
然后，微小的消息可以通过 Kafka/JMS 或其他一些消息队列系统进行传输，其中大多数系统在处理大型数据 block 方面相当糟糕。
当然，一个非常简单的实现是将文件保留在文件共享上，并且仅通过文件路径引用它们。
当最好将 blob 与消息的其余部分集成时，情况会更加复杂，需要真正的声明检查实现。这可以在基础设施级别进行处理，因此消息发送者和接收者不需要了解数据传输方式背后的任何细节。
我知道你在Java领域，但是在NServiceBus (我为 Particular Software 工作，NServiceBus 的制造商)此模式是通过 Data Bus feature 实现的。在消息管道步骤中。开发人员需要做的就是确定适用于数据总线的消息属性类型，并(在默认文件共享实现中)配置文件存储的位置。开发人员还可以自由提供自己的数据总线实现。
需要记住的一件事是，当 blob 与消息断开连接时，您必须进行清理。如果消息是单向的，您可以在成功处理消息后立即清除它们。使用 Kafka(不太熟悉)，可以多次处理来自流的消息，对吗？如果是这样，您需要等到无法再处理该消息为止。或者，如果使用发布/订阅模式，则在确定所有订阅者都有机会得到处理之前，您不会希望清理文件。为了实现这一点，您需要在消息上设置 SLA(必须在其中处理每条消息的时间跨度)，并在该时间跨度过后清理 Blob 存储。
无论如何，有很多事情需要考虑，这使得在基础设施级别实现比尝试在每个实例中推出自己的版本更有用。
关于java - 如何在微服务环境中通过消息查询处理大文件？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37634349/