面向微服务的数据库连接池策略

Question

我们正在尝试将我们的单片应用程序转换为基于微服务的体系结构。我们使用Postgresql作为单一应用程序中的数据库之一，并使用BoneCP进行连接池。

当这个整体被拆分为多个独立的微服务，每个服务都运行在不同的JVM中时，我可以考虑两种连接池选项

1. BoneCP或任何适合每个微服务的连接池-我的初步研究表明，这是主要选择。可以对每个服务的连接需求进行细粒度控制。但是，不利的一面是，随着服务数量的增加，连接池的数量也会增加，最终会有太多的空闲连接，假设每个池中的最小连接数大于0
2. 依赖于特定于数据库的扩展，如PGBouncer，这种方法的优点是连接池由中央源管理，而不是每个微服务的池，因此可以减少空闲连接的数量。它也是语言/技术不可知论。缺点是这些扩展是特定于数据库的，JDBC中的一些功能可能无法工作。例如：在Transaction\u Pooling模式下，Prepared Stations可能无法与PGBouncer一起使用

在我们的案例中，大多数微服务（至少50个）将连接到同一个Postgres服务器，即使数据库可能不同。因此，如果使用选项1，则创建太多空闲连接的可能性更大。我们大多数服务的流量都非常适中，转向微服务的理由是为了更容易部署、扩展等。

有没有人在采用微服务体系结构时遇到过类似的问题？在微服务领域，有没有更好的方法来解决这个问题？

Answer 1

我在这里回答了一个类似的问题：微服务-连接到单个遗留数据库时的连接池

“我在工作中面临着类似的困境，我可以分享我们迄今为止得出的结论。

目前没有银弹，因此：

1-计算连接数除以微服务实例所需的总连接数，如果您的微服务不需要大幅弹性扩展，则可以很好地工作。

2-根本没有池，让连接按需打开。这就是函数式编程（如Amazon lambdas）中使用的内容。它将减少打开连接的总数，但缺点是，您会失去性能，因为动态打开连接的成本很高。

您可以实现某种主题，让您的服务知道侦听器中的实例数已更改，并更新总连接数，但这是一个复杂的解决方案，违背了微服务原则，即在服务开始运行后不应更改其配置。

结论：如果微服务的规模没有增长，并且没有池，如果它确实需要以弹性和指数方式增长，我会计算这个数字，在最后一种情况下，确保在第一次尝试时没有连接的情况下进行重试。

这里有一个有趣的灰色区域，等待更好的方法来控制微服务中的连接池。

随着时间的推移，为了让这个问题更加有趣，我建议阅读HikariCP中的关于池大小的文章：https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing数据库中理想的并发连接实际上比大多数人想象的要小。”

Answer 2

也许可以将少量的微服务分组到Moduleith中，并使用karaf或其他osgi容器作为它们的运行时。然后，您可以创建表示数据库连接池的捆绑包，以便其他捆绑包-微服务可以使用它。但我不确定它是否能解决您的架构问题。

Answer 3

我看不出pgbouner将如何解决您在第一种方法中遇到的任何问题。使用pgbouner有很多原因，但我认为它们在这里并不真正适用。

此外，根据我的经验，虽然空闲连接可能是一个问题，但它们可能不会达到您所谈论的规模。我的意思是，我们不是在谈论数百个空闲连接，对吗？

更重要的是，微服务方法将为您提供的一个关键功能是将dbs转移到其他服务器的能力。如果这样做，那么集中管理连接池会使这一点变得更加困难。

每个服务池通常更加灵活，它也使您的基础架构更加灵活。