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

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

当这个monolith被分成许多独立的微服务，每个微服务在不同的JVM中运行时，我可以考虑两个连接池的选项

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

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

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

2
投票

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

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

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

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

0
投票

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

目前没有银弹，所以：

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

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

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

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

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

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

0
投票

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