微服务-连接到单个旧数据库时的连接池 [英] Microservices - Connection Pooling when connecting to a single legacy database
问题描述
我正在使用Spring Boot + Spring Cloud + Spring JDBC为单片应用程序开发微服务。
当前，应用程序正在通过tomcat JNDI连接池连接到单个数据库。
I am working on developing micro services for a monolithic application using spring boot + spring cloud + spring JDBC. Currently, the application is connecting to a single database through tomcat JNDI connection pool.
我们这里有一个瓶颈，不要更改此点的数据库体系结构。由于各种原因（例如大量的db对象，与其他系统的紧密依赖关系等）而导致时间变化。
We have a bottleneck here, not to change the database architecture at this point of time because of various reasons like large number of db objects,tight dependencies with other systems,etc.
因此，我们根据应用程序功能隔离了微服务。我担心的是，如果我们开发每个都有自己的连接池的微服务，那么与数据库的连接数会成倍增加。
So we have isolated the micro services based on application features. My concern is if we develop microservices with each having its own connection pool, then the number of connections to the database can increase exponentially.
目前，我正在考虑两种解决方案
Currently, I am thinking of two solutions
-
计算每个应用程序功能当前正在使用的连接数，并得出每个服务的最大/最小连接参数-这是一个非常繁琐的过程，我们没有任何机制来获取每个应用程序功能的连接数。
To calculate the number of connections that is being used currently by each application feature and arriving at max/min connection params per service- which is a very tedious process and we don't have any mechanism to get the connection count per app feature.
要开发具有以下功能的数据微服务：单个连接池从其他MS获取查询对象，将查询触发到数据库，然后将结果集对象返回给调用方。
To develop a data-microservice with a single connection pool which gets the query object from other MS, triggers the query to the database and returns the resultset object to the caller.
不确定第二种方法在微服务体系结构中是否是最佳实践。
Not sure whether the second approach is a best practice in the microservices architechture.
请问您可以提出其他对$ b有帮助的标准方法吗？ $ b当前情况？
Can you please suggest any other standard approaches that can be helpful in the current situation?
推荐答案
与权衡有关。
- 计算每个应用程序当前正在使用的连接数功能，并确定每种服务的最大/最小连接参数。
缺点：如您所说，有些配置文件
Cons: As you said, some profiling and guesswork needed to reach the sweet number of connection per app feature.
优点：与第二种方法不同，您可以避免性能开销
Pros: Unlike the second approach, you can avoid performance overhead
- 要开发一个具有单个连接池的数据微服务，该连接池会从其他MS获取查询对象，从而触发对数据库并返回结果集对象给调用者。
优点：最少的前期工作
缺点：再增加一层，然后再增加一个故障点。由于必须处理序列化->，性能会下降。 Http网络延迟->反序列化->（jdbc有趣的东西，这是任何一种方法的一部分）->序列化-> Http网络延迟->反序列化。 （就您而言，这种性能成本可以忽略不计。但是，如果每毫秒都对您的服务至关重要，那么这是一个巨大的决定因素）
Cons: one more layer, in turn one more failure point. Performance will degrade as you have to deal with serialization -> Http(s) network latency -> deserialization->(jdbc fun stuff which is part of either approach) -> serialization -> Http(s) network latency -> deserialization. (In your case this performance cost may be negligible. But if every millisecond counts in your service, then this is a huge deciding factor)
我认为，我不会
这是一本不错的文章：> http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data/
This is a good read: http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data/
这篇关于微服务-连接到单个旧数据库时的连接池的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
