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