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

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

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

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

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

解决方法

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

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

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!