我们有一个带有多租户系统的微服务堆栈。
目前，我们有 5 个“重度”请求的服务，约有 1000 名客户/租户，每个服务都有一个数据库。
现在我们开始达到连接池限制，因为它设置为 100（我们增加到 200 或 300，但这始终只是临时修复）。
问题是，使用默认设置： https://www.npgsql.org/doc/connection-string-parameters.html#pooling 在一般情况下，汇集起来似乎是一个坏主意 - 是的，我知道为什么汇集在这里，但事实上每个客户都有自己的连接字符串，意味着它自己的连接，意味着 1000 个客户和约 2500 个用户，意味着汇集本身可能是一个“对我们来说“坏事”。
是否有关于如何在微服务多租户应用程序中处理池/数据库连接的概念的一般信息/白皮书/想法？
在考虑多租户以及使用鉴别器（每个数据库多个租户）和每个租户数据库/模式之间的决定时，这取决于您想要如何扩展。每个数据库租户（或每个数据库租户的混合）是关于纯粹的隔离和启用水平可扩展性，支持在达到阈值时启动新的数据库实例。听起来，在 PostgreSQL 中，您正在利用 Schema-per-Tenant，这就像 SQL Server 中的 DB-per-Tenant，问题是单个数据库服务器上有 1000 多个 Schema。考虑限制数据库/架构数量以适应服务器硬件的连接限制，并为另一组架构启动新的数据库实例。
这可能需要一些设计转变来处理初始身份验证。我使用的设计涉及拥有一个中央身份验证服务器（具有故障转移功能），应用程序/服务最初都会与该服务器进行通信。该数据包含有关系统的全局信息，以及有关租户的任何版本控制/许可/配置。然后，每个租户接收与其帐户关联的“数据”连接字符串详细信息，并且他们的应用程序/服务启动与指向其指定服务器实例的数据的连接。该连接信息会被缓存，例如在 Web 服务的会话状态中，以及其他详细信息（例如即将到来的维护窗口等消息传递），因此服务可以通知客户端用户或定期轮询中央身份验证数据库以获取状态更新。这使我能够对租户数据库进行维护，必要时移动它们，并在扩展或服务需求发生变化时更新它们的集中配置以将它们指向新数据库。 （即平衡硬件上的租户，因为某些站点比其他站点是更大的消费者，尤其是在评估期之后）
身份验证数据库上的连接池将正常工作，因为所有租户共享相同的连接字符串，并且对此服务器/架构的访问很简短。租户可以为各自的模式/数据库共享一个数据库服务器，并且每个服务器拥有合理数量的实例，以使服务器能够满足任何池化或并发连接请求。当租户填满服务器时，这些数据库服务器实例仍然可以垂直扩展。一开始，身份验证服务器可以托管租户数据库，因此您最初无需支付专用的额外数据库服务器的费用，但随着您的发展，您可以启动第二个数据库服务器实例并在维护时段或通过如果是 24/7 服务，复制和故障转移模型可减少中断。
希望这能给您一些解决方案的想法。