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

Question

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

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

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

在我们的例子中，大多数微服务（至少 50 个）将连接到同一个 Postgres 服务器，即使数据库可能不同。 因此，如果我们选择选项 1，则更有可能创建过多的空闲连接。我们大多数服务的流量非常适中，迁移到微服务的基本原理是为了更容易部署、扩展等。

有没有人在采用微服务架构时遇到过类似的问题？ 在微服务世界有没有更好的方法来解决这个问题？

Answer 1

我不知道pgbouncer将如何解决您在第一种方法中遇到的任何问题。 使用pgbouncer的原因有很多，但我认为它们并不适用于此。

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

更重要的是，微服务方法给你的一个关键是能够将dbs移到其他服务器上。 如果这样做，那么集中管理连接池会使这更难做到。

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

Answer 2

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

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

目前没有银弹，所以：

1 - 如果您的微服务不需要具有极大的弹性比例，那么计算微服务实例所需的总连接数的连接数将很有效。

2 - 根本没有游泳池，可以按需打开连接。 这就是函数式编程中使用的东西（如亚马逊lambdas）。 它将减少打开连接的总数，但缺点是你失去了性能，因为开启的连接是昂贵的。

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

结论：如果微服务倾向于没有规模增长而没有池，如果它确实需要弹性地和指数地增长，我将计算数量，在最后一种情况下确保重试已到位，以防它没有得到连接在第一次尝试。

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

及时，为了使问题更加有趣，我建议阅读HikariCP上关于池大小的文章： https ： //github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing数据库中理想的并发连接是实际上比大多数人想象的要小。“

Answer 3

假设您有限制要求 - 只有10个数据库连接。 您可以运行10个微服务实例，连接池最多只能连接1个连接。 或者，您可以使用pool max = 3运行3个实例。 集中式连接池可以为云中的多个服务提供服务，听起来很糟糕（典型的单点故障）。

Answer 4

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