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

EN

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

可以在服务之间传递配置好的数据源。这将从本质上序列化或外部化数据源配置，并构建具有相同配置的新配置。但是要注意，并不是所有的数据源实现都支持这一点。

这在Java中已经存在多年了，例如如何使用JNDI服务器来查找分布式应用程序的配置数据，或者JavaEE应用程序如何与JavaEE应用程序共享配置数据。在我的经验中，这是一种越来越不常见的做法，它倾向于使用等东西。

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

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

对TCP连接迁移进行了一些研究，如这一个。但是，这里的主要目标不是性能(通过在连接建立过程中节省TCP 3路握手的时间来节省连接池中的性能)，而是允许现有的连接继续存在，而不是由于移动或故障转移导致IP更改而中断。

如果你提到上面的链接文件，核心概念是再次做三次握手，与新IP建立一个新的连接。唯一的区别是，在握手期间，将传递一些额外的控制数据，以便使用新的主机数据更新TCB，这样正在进行的数据传输可以继续进行，而不会由于IP更改而中断。

因此，不能仅仅将DB连接从一个主机传输到另一个主机，因为主机具有不同的IP。我所链接的上述文件是草稿。即使它被实现了，它也无助于您的事业，因为正如我所说的，迁移将再次需要握手，这正是您在连接池中想要避免的。

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

最后，将所有连接池托管在单个微服务中的想法(尽管由于上述事实而本质上是错误的)似乎与基于微服务的体系结构背道而驰。这将造成一个瓶颈，而这个微服务的任何问题都会使您的整个基础设施崩溃。在微服务体系结构中，我们希望将问题本地化，而不是传播。你的个人微型服务应该是尽可能自主的，像舱壁和断路器这样的模式可以很大程度上实现这一点。