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

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

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

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

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

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

解决方法

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

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

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

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

原文地址：https://www.jb51.cc/mssql/78640.html