使用 HTTPClient 进行异步调用与使用 Tasks 异步直接调用方法进行同步服务答案

【问题标题】：Async calls using HTTPClient vs Direct calling methods asynchronously using Tasks for a synchronous service使用 HTTPClient 进行异步调用与使用 Tasks 异步直接调用方法进行同步服务
【发布时间】：2015-06-03 08:23:14
【问题描述】：

我在现有应用程序中有一个场景，单击“保存”按钮会调用 Javascript 函数。这个 javascript 函数在内部对 web 服务进行 4-5 次异步调用。由于某些原因，我们现在有很大的 javascript 文件，其中包含很多业务逻辑。我们还面临应用程序中的性能问题。为了减少我们对服务器进行的 XHR 调用的数量，我们考虑在服务器端整合这些调用，然后从我们的 Javascript 中进行一次调用。在服务器端，我们使用 Async Await 使此调用异步。因此，我们创建了一个包装服务，其中一个方法现在使用 HTTPClient 公开的 SendAsync 方法调用不同的服务方法。我们的底层服务都是同步的，为了实现异步功能，我们使用了 HTTPClient。我们测量了性能，它显示出可观的收益。但是，我们的一位同事指出，我们实际上会有序列化和反序列化的开销，而且我们现在从服务器发起其他 Web 服务调用，这些调用最终将同步运行。所以为什么不直接调用这些方法而不是新的 HTTP 调用。现在我们的方法都是同步的，为了使它们异步，我们将不得不使用任务，这又是开销。这两种方法都会产生开销，但我们看到使用 async await 发出新的 HTTP 请求更符合微服务概念。有一场辩论，我想知道其他想法。

【问题讨论】：

没有争议：衡量。尽管除非您创建数百个 Tasks，否则开销可能会微不足道。

标签： asynchronous async-await task-parallel-library dotnet-httpclient

【解决方案1】：

我的两分钱：

在服务器端聚合信息的方法很好。从我的角度来看，仅当您想连接到遗留服务并且您没有能力直接集成它时，在服务器端内部使用 HTTPClient 才是一种解决方案。 HTTPClient 使用简单且健壮，但从技术上讲，它比使用 Task 开销更大（想想错误处理、序列化、测试、网络/套接字资源）。

Task 也不错，因为它允许适当的取消，这是 HTTPClient 无法实现的（HTTPClient 只能关闭套接字，另一端仍然可以阻塞资源）。

在一般资源方面，Futures 的使用使 Task 完美匹配： https://msdn.microsoft.com/en-us/library/ff963556.aspx

【讨论】：