Hystrix 应该替换现有的 JDBC/HTTP 连接池，还是委托给它们？

Question

许多应用程序将连接池用于 HTTP 和 JDBC 调用以实现弹性。但是使用和配置这两种类型的池是非常不同的。这重复了实现两者共有的弹性模式的复杂性 - 例如超时、重试、缓存/警报回退、断路和监控。

在我看来，Hystrix 提供了为 HTTP 和 JDBC 调用配置和实现这些相同弹性模式的通用方法。

我的问题是：

1. Hystrix 理论上可以替代现有的 HTTP 和 JDBC 完全连接池？
2. 如果是这样，这样做的利弊是什么？

完全替换它们可以减少围绕这些连接池的复杂性 - 以及它们伴随的超时和验证查询属性等。但是我对 Hystrix 如何“保持活动” JDBC / HTTP 连接感到模糊 - 从而避免昂贵的连接设置成本 - 无需委派给专门用于这些任务的现有库。

对于上下文，我有一个 DropWizard 应用程序，它使用 Tomcat DBCP 作为其 JDBC 连接池，并使用 Apache HttpClient 作为其 HTTP 连接池。

Answer 1

不，Hystrix 不能替换你的连接池。

Hystrix 的主要特点是：

1. 通过使用有限的线程池或信号量来限制对服务的调用次数。
2. 可以使对服务的调用超时，以避免应用程序线程被锁定以等待慢速/挂起的服务。
3. 添加隔板，以便将一项缓慢的服务对应用程序的其余部分的影响降至最低。
4. 断路缓慢/挂起的服务。

不支持池连接。

我想你可以说第一点与连接池有些相关，因为 Hystrix 和连接池都可以限制对其他系统的负载。但是，拥有连接池的主要原因是池化连接的性能增益。这种负载限制行为基本上是连接池的一个好处。

但是，Hystrix 可以通过提供快速失败超时行为和隔板来补充连接池，如果添加在连接池前面，如您在问题中所建议的那样。