在使用 Spring-Boot 和 Eureka 服務發(fā)現(xiàn)構(gòu)建的微服務架構(gòu)中，我正在為單獨的單個服務中的許多應用程序構(gòu)建 C3P0 連接池。但是，當我嘗試將創(chuàng)建的連接池作為對象返回到它們的各個應用程序并使用來自該對象的連接時，它不起作用。例如 - 當我們直接使用 C3P0 創(chuàng)建 DataSource 時，我們編寫 -ComboPooledDataSource dataSource = new ComboPooledDataSource();
dataSource.setDriverClass(...);但是當我們想讓dataSource使用不同微服務中創(chuàng)建的Connection Pool時，有沒有example/Github可以獲取呢？
2 回答
楊__羊羊
TA貢獻1943條經(jīng)驗 獲得超7個贊
DB 連接本質(zhì)上是一個 TCP 連接，它由參與主機中的一對套接字唯一標識。這里的套接字意味著網(wǎng)絡地址（IP）和主機地址（端口）的組合。
當建立 TCP 連接時，所有這些詳細信息都存儲在稱為 TCB 的數(shù)據(jù)結(jié)構(gòu)中的任一端點上。因此，您不能只將 TCP 連接從一臺主機遷移到另一臺主機。
有一些像這樣的關(guān)于 TCP 連接遷移的研究。但是，這里的主要目標不是性能（如在連接池中通過節(jié)省連接建立期間 TCP 3 次握手的時間），而是允許現(xiàn)有連接繼續(xù)，并且不會由于移動性或故障轉(zhuǎn)移導致的 IP 更改而中斷.
如果您參考上面的鏈接文件，核心概念是再次進行 3 次握手以創(chuàng)建與新 IP 的新連接。唯一的區(qū)別是在握手過程中，一些額外的控制數(shù)據(jù)將被傳遞以用新的主機數(shù)據(jù)更新 TCB，這樣正在進行的數(shù)據(jù)傳輸可以繼續(xù)進行，而不會因 IP 更改而中斷。
因此，您不能僅僅將數(shù)據(jù)庫連接從一臺主機轉(zhuǎn)移到另一臺主機，因為這些主機具有不同的 IP。我鏈接的上述論文是草稿版本。即使實現(xiàn)了它，它也無助于您的事業(yè)，因為正如我所說，遷移將再次需要握手，這是您在連接池中要避免的。
如果您以某種方式將數(shù)據(jù)源從一臺主機傳輸?shù)搅硪慌_主機，然后嘗試從中借用連接，則數(shù)據(jù)源在返回連接之前所做的連接測試將失敗，這將一直持續(xù)到所有連接都用盡，然后是新連接將創(chuàng)建該特定主機。所以，最終你不會從中得到任何東西。
最后，在單個微服務中托管所有連接池的想法（盡管由于上述事實而本質(zhì)上是錯誤的）似乎與基于微服務的架構(gòu)背道而馳。這會造成瓶頸，并且此微服務的任何問題都會導致您的整個基礎(chǔ)架構(gòu)癱瘓。在微服務架構(gòu)中，我們希望將問題本地化而不是傳播。您的個人微服務應該盡可能地自治，并且像隔板和斷路器這樣的模式可以實現(xiàn)這一目標。
智慧大石
TA貢獻1946條經(jīng)驗 獲得超3個贊
不可能在服務之間傳遞填充的連接池，因為它們需要存在（并從中加載類）該 Java 應用程序的地址空間，并且物理連接也需要來自該 Java 應用程序。你需要以不同的方式解決這個問題。
可以在服務之間傳遞配置的數(shù)據(jù)源。這實際上將序列化或外部化數(shù)據(jù)源配置，并使用相同的配置構(gòu)建一個新配置。請注意，并非所有數(shù)據(jù)源實現(xiàn)都支持這一點。
這在 Java 中已經(jīng)存在多年，例如 JNDI 服務器如何用于查找分布式應用程序的配置數(shù)據(jù)，或者 JavaEE 應用程序如何與 Java 客戶端應用程序共享配置數(shù)據(jù)。根據(jù)我的經(jīng)驗，這種做法越來越不常見，有利于使用 Spring Cloud Config 等。
添加回答
舉報
0/150
提交
取消