通过 Web 服务交付大数据的理想方式/架构答案

【问题标题】：Ideal way/architecture to deliver large data over Web Services通过 Web 服务交付大数据的理想方式/架构
【发布时间】：2010-04-18 02:10:49
【问题描述】：

我们正在尝试设计 6 个 Web 服务，它们将为另一个客户端组件提供服务。客户端组件需要来自我们正在实施的 Web 服务的数据。

现在的问题是，我们正在实施的不是 1 个 Web 服务，只有一个客户端组件命中的 Web 服务，这会启动一系列（另外 5 个）Web 服务，它们从各自的数据存储中收集数据，并最后将数据提供回原始Web Service，然后将数据传递回客户端组件。

所以，如果请求的数据变得巨大，那么，这对我们内部的沟通渠道来说将是一个严重的问题。

那么，你们有什么建议呢？可以做些什么来避免内部 Web Service 之间的通信通道过载，同时也将数据传递给客户端组件。

更新 1

使用 5 WS，其中，1WS 不知道其他的，除了下一个是业务需求。实际上，正在整合5家公司的“小服务”。

我们使用 Java 和 Axis2

【问题讨论】：

您使用的是什么网络服务框架？如果您使用的是 ASP.NET，则可以选择使用二进制 xml 序列化，这可以显着提高性能。此外，如果您可以避免使用基于 SOAP / xml 的 Web 服务，而是使用纯文本 json，那也将大大减少您的负载。最后，Web 服务旨在将公共 API 暴露给外部世界，如果它们是严格内部的，请认真考虑使用“系列（5 或更多）”Web 服务直接与数据库对话。
您能否缓存您从中提取的 5 个外部 Web 服务的结果（可能具有给定的过期时间间隔）？过去，这对我来说是一个非常有效的解决方案。

【解决方案1】：

我们也遇到过类似的问题。除了试图避免它（例如，内部通信直接到数据库而不是 Web 服务）之外，您可以通过至少不连续执行 5 个左右的任务来缓解它。创建新线程以并行收集它们并在最后处理它们以减少延迟（除非它们可能争夺相同的资源和瓶颈）。

但在我做任何事情之前对其进行负载测试，看看它是否是一个问题，并获得一些基线统计数据，这样你就可以看到每个更改带来了哪些改进。此外，有时您最好调整网络设置或实际网络，而不是尝试优化代码 - 但再次测试并查看。

【讨论】：

【解决方案2】：

将所有数据放在一个临时压缩文件中，并返回文件的ftp url。

客户端获取大数据块解压缩并读取它。（可能是 ftp 服务器的一些身份验证机制）

【讨论】：