微服务架构中的大文件/数据传输

22

我的公司目前正在努力采用微服务架构，但是在此过程中我们遇到了一些麻烦（令人震惊）。我们面临的主要争论点之一是如何在我们的不同服务之间传递大量数据。

作为背景知识，我们有一个文档存储，可作为我们可能需要在公司范围内处理的任何文档的存储库。与所述商店的交互是通过服务完成的，该服务为客户提供了唯一的ID和流文档的位置。以后可以通过使用提供的ID进行查找来访问文档的位置。

问题是-对于我们所有的微服务而言，是否为了与文档进行交互而接受此唯一ID作为其API的一部分有意义吗？在我看来，这本质上是错误的-服务不再是独立的，而是依赖于文档存储的服务。尽管我确实承认这可能会简化API设计，甚至可能会带来一些性能提升，但所产生的耦合效果远不止于此。

有谁知道彩虹独角兽（Netflix，亚马逊，谷歌等）如何处理服务之间的大文件/数据交换？

design rest xml microservices

— 高级层
source

您在高可用性文档/文件存储中使用什么？

— 特伦斯·约翰逊

@TerenceJohnson我们现在正在使用自家解决方案。我们正在向使用RESTful Api的解决方案迁移，该解决方案仅保留唯一的文档ID及其位置（提供给客户端而不是流，以防止不必要的内部网络负担）。实际的持久性将通过AWS完成。

— PremiumTier

7

有谁知道彩虹独角兽（Netflix，亚马逊，谷歌等）如何处理服务之间的大文件/数据交换？

不幸的是，我不知道他们如何处理此类问题。

问题是-对于我们所有的微服务而言，是否为了与文档进行交互而接受此唯一ID作为其API的一部分有意义吗？

它违反了单一职责原则，该原则应在微服务的体系结构中固有。一个微服务- 逻辑上一个，实际上代表一个的许多实例-应该处理一个主题。

就您的文档存储而言，只有一点，所有对文档的查询都将到达（当然，您可以将此逻辑单元拆分为多个文档存储，以存储多种文档）。

我们面临的主要争论点之一是如何在我们的不同服务之间传递大量数据。

这是一个体系结构问题：

减少传输大量数据的需求

理想情况下，每个服务都具有所有数据，无需传输即可简单地为请求提供服务。作为此想法的扩展-如果您需要传输数据，请考虑冗余（*以积极的方式_）：在很多地方（需要它们的地方）使数据冗余有意义吗？考虑一下不一致可能如何损害您的流程。没有更快的传输，实际上没有。
减少数据本身的大小

想想如何压缩数据：从实际的压缩算法到智能数据结构。越少越过电线，您就越快。

— 托马斯·容克
source

2

如果您的文档存储返回的ID是在整个系统中引用文档的方式，那么当服务需要知道需要使用哪个文档时，所有服务都应在其API上接受该“文档ID”。

这不一定会导致服务之间的耦合比需要的更紧密。需要访问文档的服务无论如何都需要访问文档存储服务，并且他们需要该ID来告知商店要访问哪个文档。
不直接访问文档的服务可能需要传递文档ID，但是对于那些服务，这只是一个不创建依赖关系的任意字符串。

— 巴特·范·恩根·舍瑙
source

谢谢您的回复。我还要补充一点，将微服务提供给可能不希望利用我们内部文档存储的外部消费者也可能从中受益。考虑到这一点，您仍然觉得这是最好的方法吗？

— PremiumTier

@PremiumTier：是的。但是这些外部客户将必须提供自己的商店，该商店与内部商店支持相同的API，以便您的服务可以与其合作。

— Bart van Ingen Schenau，2015年

这是有道理的，但与让服务接受流，字节数组或json blob（而不是文档引用）相比，它仍然感到更加麻烦。在这种情况下，如果需要，可以在调用任何后续服务之前轻松地先调用“适配器”服务以获取文件流。我并不是想通过这种方式来辩论，而只是想了解这种方法的优点：）

— PremiumTier

2

就个人而言，我不希望使用单独的文档存储服务和文档ID，而是使用URL来访问文档（具有正确的标头身份验证）。通过这种方法，您将不需要其他服务来依赖文档服务，而是可以使用完整的URL来访问文档，并且在扩展方面也很有意义，您可以使用多个文档存储当存储空间增加并提供URL时。

但是，您可能需要服务才能上载文档并获取其URL。

— 低飞鹈鹕
source

1

有谁知道彩虹独角兽（Netflix，亚马逊，谷歌等）如何处理服务之间的大文件/数据交换？

签出Amazon S3 REST API规范，看似它们以字节为单位返回完整对象。如果要设计微服务，似乎没有太多选择。 Amazon S3响应格式链接

— 肯定的
source