在我走得太远之前，我想向您保证，我已经做了尽职调查，并在网上搜索建议/答案。特别是，我查看了以下帖子：
Calling Different Webservices in parallel from Webapp
在上面的帖子中，您将看到user1669664必须“通过一种方法进行大约15次不同的webserivce调用。”
我已经阅读了由matt b提供的最佳答案。这个答案基本上需要为每个不同的Webservice调用编写一个Callable。
事情是......
我在更大规模上遇到了类似问题 - 我需要进行大约230次网络服务调用。
我很高兴听到意见/建议。我不想写230 Callables ......！
谢谢。
答案 0 :(得分：1)
@Kayaman说的话:)
有什么时间要求？你需要在X秒内成功执行所有230吗？你如何控制网络服务器的默认超时？是否所有请求都需要200？如果单个请求失败会发生什么？你必须重试才能成功吗？如果某些百分比失败，您是否必须使所有其他请求无效？退路怎么样？
如果您无法按顺序执行请求，则需要使用某种并发代码。并发代码比同步代码更难。还有许多代码路径变体需要推理，同步内存访问或w / e。
如果您必须在Web请求的上下文中执行请求，那么将并发（线程池）限制为设定量通常是一个好主意。
如果硬编码230是设定数量，但仍然可能过大。如果这是一个公开可用的端点，那么没有什么可以阻止某人针对您的服务器启动10,000个并发请求，并且如果您可以针对您的230个URL提供所有这些请求，即2,300,000个并发请求!!!!!!!!因此，所有资源都应该有某种理智的约束。如果您从数据库中提取网址，并且任意用户可能会添加无限且不好的网址。
一种简单的方法是使用线程池限制并发。
这种架构可能包含一个有界线程池和一个队列。当每个Web请求进入时，它会将URL排队，并且线程池可以处理它们。如果需要返回值，则可以返回值Queue。我喜欢的是生产者（Web请求处理程序）和使用者（线程池）都是以同步方式编写的，并且运行时通过在线程池上执行提取程序来实现并发。
Kayaman提到了一种常用的解决方法：将长时间运行的流程从Web请求的上下文中移除。这种体系结构看起来很像内部线程池和队列，但是会进行进程间处理。队列将是一个外部进程作业/消息队列，消费者将从中拉出。然后，Web请求将触发230条消息并返回给客户端。并且异步消费者将不断从队列中提取并提出请求：）