在服务中构建连接池并在其他服务中使用它们

Question

在使用 Spring-Boot 和 Eureka 服务发现构建的微服务架构中，我正在为单独的单个服务中的许多应用程序构建 C3P0 连接池。但是，当我尝试将创建的连接池作为对象返回到它们的各个应用程序并使用来自该对象的连接时，它不起作用。例如 - 当我们直接使用 C3P0 创建 DataSource 时，我们编写 -ComboPooledDataSource dataSource = new ComboPooledDataSource(); dataSource.setDriverClass(...);但是当我们想让dataSource使用不同微服务中创建的Connection Pool时，有没有example/Github可以获取呢？

Answer 1

DB 连接本质上是一个 TCP 连接，它由参与主机中的一对套接字唯一标识。这里的套接字意味着网络地址（IP）和主机地址（端口）的组合。

当建立 TCP 连接时，所有这些详细信息都存储在称为 TCB 的数据结构中的任一端点上。因此，您不能只将 TCP 连接从一台主机迁移到另一台主机。

有一些像这样的关于 TCP 连接迁移的研究。但是，这里的主要目标不是性能（如在连接池中通过节省连接建立期间 TCP 3 次握手的时间），而是允许现有连接继续，并且不会由于移动性或故障转移导致的 IP 更改而中断.

如果您参考上面的链接文件，核心概念是再次进行 3 次握手以创建与新 IP 的新连接。唯一的区别是在握手过程中，一些额外的控制数据将被传递以用新的主机数据更新 TCB，这样正在进行的数据传输可以继续进行，而不会因 IP 更改而中断。

因此，您不能仅仅将数据库连接从一台主机转移到另一台主机，因为这些主机具有不同的 IP。我链接的上述论文是草稿版本。即使实现了它，它也无助于您的事业，因为正如我所说，迁移将再次需要握手，这是您在连接池中要避免的。

如果您以某种方式将数据源从一台主机传输到另一台主机，然后尝试从中借用连接，则数据源在返回连接之前所做的连接测试将失败，这将一直持续到所有连接都用尽，然后是新连接将创建该特定主机。所以，最终你不会从中得到任何东西。

最后，在单个微服务中托管所有连接池的想法（尽管由于上述事实而本质上是错误的）似乎与基于微服务的架构背道而驰。这会造成瓶颈，并且此微服务的任何问题都会导致您的整个基础架构瘫痪。在微服务架构中，我们希望将问题本地化而不是传播。您的个人微服务应该尽可能地自治，并且像隔板和断路器这样的模式可以实现这一目标。

Answer 2

不可能在服务之间传递填充的连接池，因为它们需要存在（并从中加载类）该 Java 应用程序的地址空间，并且物理连接也需要来自该 Java 应用程序。你需要以不同的方式解决这个问题。

可以在服务之间传递配置的数据源。这实际上将序列化或外部化数据源配置，并使用相同的配置构建一个新配置。请注意，并非所有数据源实现都支持这一点。

这在 Java 中已经存在多年，例如 JNDI 服务器如何用于查找分布式应用程序的配置数据，或者 JavaEE 应用程序如何与 Java 客户端应用程序共享配置数据。根据我的经验，这种做法越来越不常见，有利于使用 Spring Cloud Config 等。