我们正在尝试将我们的单片应用程序转换为基于微服务的架构。我们使用Postgresql作为我们在使用BoneCP进行连接池的单片应用程序中的数据库之一。
当这个monolith被拆分为多个独立的微服务时，每个微服务都运行在不同的JVM中，我可以考虑两个连接池选项
在我们的例子中，大多数微服务（至少50个）将连接到同一个Postgres服务器，即使数据库可能不同。因此，如果我们使用选项1，则创建太多空闲连接的可能性更高。我们大多数服务的流量都非常适中，转向微服务背后的理由是更容易部署，扩展等。
在采用微服务架构时，有没有人遇到过类似的问题？在微服务世界中有没有更好的方法来解决这个问题？
答案 0 :(得分：2)
我不知道pgbouncer将如何解决您在第一种方法中遇到的任何问题。使用pgbouncer的原因有很多，但我认为它们并不适用于此。
另外，根据我的经验，虽然空闲连接可能是一个问题，但它们可能不会达到你所说的规模。我的意思是我们不是在谈论数百个空闲连接吗？
更重要的是，微服务方法给你的一个关键是能够将dbs移到其他服务器上。如果这样做，那么集中管理连接池会使这更难做到。
每服务池通常更灵活，它也使您的基础架构更加灵活。
答案 1 :(得分：0)
我在这里回答了类似的问题：Microservices - Connection Pooling when connecting to a single legacy database
“我在工作中面临着类似的困境，我可以分享到目前为止所得出的结论。
目前没有灵丹妙药，所以：
1-如果您的微服务不需要极大地扩展弹性规模，那么计算连接数除以微服务实例所需的总连接数将很有效。
2-根本没有池，让连接按需打开。这就是函数编程（例如Amazon lambdas）中使用的东西。这样会减少打开的连接总数，但缺点是您会失去性能，因为即时打开连接非常昂贵。
您可以实现某种主题，使您的服务知道侦听器中实例的数量已更改并更新总连接数，但这是一个复杂的解决方案，并且违反了微服务原理，即您不应更改配置服务开始运行后的状态。
结论：如果微服务需要弹性和指数增长，如果微服务趋于不按比例增长并且没有池，那么我将计算数字，在最后一种情况下，请确保重试到位，以防万一第一次尝试建立连接。
这里有一个有趣的灰色区域，等待着更好的方法来控制微服务中的连接池。
为了及时使问题变得更加有趣，我建议阅读 来自HikariCP的关于池大小调整的文章：https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing数据库中理想的并发连接实际上比大多数人想象的要小。”
答案 2 :(得分：0)
比方说，您有限制要求-到数据库只有10个连接。 您可以在连接池限制为最多1个连接的情况下运行10个微服务实例。或者，您可以运行3个实例，池max = 3。 可以在云中提供多种服务的集中式连接池听起来很糟糕（典型的单点故障）。