微服務的數據庫連接池策略

Question

我們正在嘗試將我們的單體應用程序轉換為基於微服務的架構。 我們在單片應用程序中使用 Postgresql 作為我們的數據庫之一，使用 BoneCP 進行連接池。

當這個單體被拆分為多個獨立的微服務，每個微服務都在不同的 JVM 中運行時，我可以考慮兩種連接池的選擇

1. BoneCP 或每個微服務的任何像樣的連接池 - 我的初步研究表明這是主要選擇。 可以對每個服務的連接需求進行細粒度控制。但是，缺點是隨着服務數量的增加，連接池的數量也會增加，假設每個服務中的最小連接數，最終會有太多空閑連接池大於 0。
2. 依賴於數據庫特定的擴展，如 PGBouncer - 這種方法的優點是連接池由中央源管理，而不是每個微服務的池，因此可以減少空閑連接的數量。 它也是語言/技術不可知的。 不利的一面是這些擴展是特定於數據庫的，JDBC 中的某些功能可能不起作用。 例如：准備好的語句可能無法在 Transaction_Pooling 模式下與 PGBouncer 一起使用。

在我們的例子中，大多數微服務（至少 50 個）將連接到同一個 Postgres 服務器，即使數據庫可能不同。 因此，如果我們選擇選項 1，則更有可能創建過多的空閑連接。我們大多數服務的流量非常適中，遷移到微服務的基本原理是為了更容易部署、擴展等。

有沒有人在采用微服務架構時遇到過類似的問題？ 在微服務世界有沒有更好的方法來解決這個問題？

Answer 1

我不知道pgbouncer將如何解決您在第一種方法中遇到的任何問題。 使用pgbouncer的原因有很多，但我認為它們並不適用於此。

另外，根據我的經驗，雖然空閑連接可能是一個問題，但它們可能不會達到你所說的規模。 我的意思是我們不是在談論數百個閑置連接嗎？

更重要的是，微服務方法給你的一個關鍵是能夠將dbs移到其他服務器上。 如果這樣做，那么集中管理連接池會使這更難做到。

每服務池通常更靈活，它使您的基礎架構也更加靈活。

Answer 2

我在這里回答了類似的問題：微服務- 連接到單個遺留數據庫時的連接池

“我的工作面臨着類似的兩難困境，我可以分享迄今為止所得出的結論。

目前沒有銀彈，所以：

1 - 如果您的微服務不需要具有極大的彈性比例，那么計算微服務實例所需的總連接數的連接數將很有效。

2 - 根本沒有游泳池，可以按需打開連接。 這就是函數式編程中使用的東西（如亞馬遜lambdas）。 它將減少打開連接的總數，但缺點是你失去了性能，因為開啟的連接是昂貴的。

您可以實現某種主題，讓您的服務知道在偵聽器中更改實例的數量並更新總連接數，但這是一個復雜的解決方案，違反微服務原則，您不應更改服務的配置它開始運行后。

結論：如果微服務傾向於沒有規模增長而沒有池，如果它確實需要彈性地和指數地增長，我將計算數量，在最后一種情況下確保重試已到位，以防它沒有得到連接在第一次嘗試。

這里有一個有趣的灰色區域，等待更好的方法來控制微服務中的連接池。

及時，為了使問題更加有趣，我建議閱讀HikariCP上關於池大小的文章： https ： //github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing數據庫中理想的並發連接是實際上比大多數人想象的要小。“

Answer 3

假設您有限制要求 - 只有10個數據庫連接。 您可以運行10個微服務實例，連接池最多只能連接1個連接。 或者，您可以使用pool max = 3運行3個實例。 集中式連接池可以為雲中的多個服務提供服務，聽起來很糟糕（典型的單點故障）。

Answer 4

也許將一些較少數量的微服務分組到模塊中，並使用 karaf 或其他 osgi 容器作為它們的運行時。 然后，您可以創建代表數據庫連接池的包，以便其他包——微服務可以使用它。 但我不確定它是否會解決您的架構問題。