微服务数据库连接池策略

Question

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

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

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

在我们的例子中，大多数微服务(至少50)将连接到相同的Postgres服务器，即使数据库可能是不同的。因此，如果我们使用选项1，创建太多空闲的connections.The流量的可能性更高，因为我们的大多数服务都是非常温和的，而转移到微服务背后的理由是为了更容易地部署、扩展等等。

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

Answer 1

我看不出第一种方法是如何解决任何问题的。使用保镖有很多理由，但我认为它们在这里并不适用。

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

更重要的是，微服务方法将使您具有将dbs转移到其他服务器的能力。如果您这样做，那么让您的连接池集中管理就很难做到这一点。

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

Answer 2

我在这里回答了一个类似的问题：Microservices - Connection Pooling when connecting to a single legacy database

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

目前还没有银弹，所以：

1-计算连接的数量除以微服务实例所需的总连接数，如果您的微服务不需要大幅度弹性的规模，那么它将很好地工作。

2-根本没有游泳池，让连接按需打开。这就是在函数式编程中使用的内容(比如Amazon )。它将减少打开连接的总数，但缺点是，如果每次打开连接的代价很高，则会导致性能下降。

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

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

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

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

Answer 3

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