我们正在尝试将我们的单片应用程序转换为基于微服务的架构.我们使用
Postgresql作为我们在使用BoneCP进行连接池的单一应用程序中的数据库之一.
当这个monolith被拆分成许多独立的微服务,每个微服务在不同的JVM中运行时,我可以考虑两个连接池选项
> BoneCP或每个微服务的任何合适的连接池 – 我的初步研究表明这是首选.可以对每个服务进行细粒度的连接要求控制.但是,不利的一面是随着服务数量的增加,连接池的数量也会增加,最终会有太多的空闲连接,假设每个服务的连接数最少.池大于0.
>依靠像PGBouncer这样的数据库特定扩展 – 这种方法的优点是连接池由每个微服务的中央源而不是池管理,因此可以降低空闲连接的数量.它也是语言/技术无关的.缺点是这些扩展是特定于数据库的,JDBC中的某些功能可能不起作用.例如：在Transaction_Pooling模式下,准备好的语句可能无法与PGBouncer一起使用.
在我们的例子中,大多数微服务(至少50个)将连接到同一个Postgres服务器,即使数据库可能不同.因此,如果我们选择选项1,则创建太多空闲连接的可能性更高.我们大多数服务的流量都非常适中,转向微服务背后的理由是更容易部署,扩展等.
