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

Question

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

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

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

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

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

Answer 1

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

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

更重要的是，微服务方法为您提供的一项关键功能是将数据库移至其他服务器的能力。如果您这样做，那么集中管理连接池会使这变得更难。

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