マイクロサービス用のデータベース接続プール戦略

Question

私たちは、モノリシックアプリケーションをマイクロサービスベースのアーキテクチャに変換しようとしています。私たちは、接続プーリング用のBoneCPを備えたモノリシックアプリケーションで、Postgresqlをデータベースの1つとして使用しています。このモノリスは、別のJVMで実行されているそれらのそれぞれで独立したマイクロサービスの数に分割され

、私は

1. BoneCPまたはそれぞれのまともな接続プールをプールの接続のために約2のオプションを考えることができますマイクロサービス - 私の最初の研究は、これが主要な選択であることを示しています。しかし、サービスの数が増えるにつれて、接続プールの数も増加し、最終的に各接続の最小接続数を仮定するとアイドル接続が多すぎることになりますPGBouncerのようなデータベース固有の拡張機能に依存する - このアプローチは、接続プールが各マイクロサービス用のプールではなく中央のソースによって管理されるため、アイドル接続の数を減らすことができるという利点があります。それはまた、言語/技術に依存しない。下側は、これらの拡張がデータベース固有であり、JDBCの機能のいくつかが機能しない可能性があるということです。例：Preparedステートメントは、Transaction_PoolingモードでPGBouncerで動作しないことがあります。

データベースが異なる場合でも、ほとんどのマイクロサービス（50以上）は同じPostgresサーバーに接続します。したがって、オプション1を使用すると、あまりにも多くのアイドル接続を作成する可能性が高くなります。ほとんどのサービスへのトラフィックは非常に緩やかで、マイクロサービスへの移行の根拠は導入やスケーリングなどのためです。

誰もマイクロサービスアーキテクチャを採用しているときに同様の問題に直面しましたか？マイクロサービスの世界でこの問題を解決する良い方法はありますか？

Answer 1

pgbouncerが最初のアプローチでどのような問題を解決するかはわかりません。 pgbouncerを使用する理由はたくさんありますが、実際にはここでは適用できないと思います。

また、私の経験では、アイドル状態の接続が問題になる可能性がありますが、あなたが話している規模にはないと考えられます。私は何百もの遊んでいる接続を話しているわけではないのですか？

さらに重要なことは、マイクロサービスのアプローチがもたらす重要なことの1つは、dbsを他のサーバーに移動できることです。これを行うと、接続プールを一元的に管理することによって、これをより困難にすることができます。

サービス単位のプールは一般に柔軟性が高く、インフラストラクチャもかなり柔軟になります。