微服务 - 连接到单个遗留数据库时的连接池

dhi*_*489 7 connection-pooling spring-jdbc spring-boot spring-cloud-netflix

我正在使用 spring boot + spring cloud + spring JDBC 为单体应用程序开发微服务。目前,该应用程序通过 tomcat JNDI 连接池连接到单个数据库。

我们这里有一个瓶颈,此时不能因为数据库对象数量大、与其他系统的依赖关系等各种原因而改变数据库架构。

所以我们根据应用特性隔离了微服务。我担心的是,如果我们开发的微服务每个都有自己的连接池,那么与数据库的连接数量会呈指数级增长。

目前,我正在考虑两种解决方案

  1. 计算每个应用程序功能当前正在使用的连接数并达到每个服务的最大/最小连接参数 - 这是一个非常乏味的过程,我们没有任何机制来获取每个应用程序功能的连接数。

  2. 开发具有单个连接池的数据微服务,从其他 MS 获取查询对象,触发对数据库的查询并将结果集对象返回给调用者。

不确定第二种方法是否是微服务架构中的最佳实践。

您能否建议任何其他在当前情况下有用的标准方法?

so-*_*ude 2

这都是关于权衡的。

  1. 计算每个应用程序功能当前正在使用的连接数以及每个服务的最大/最小连接参数。

缺点:正如您所说,需要进行一些分析和猜测才能达到每个应用程序功能的最佳连接数量。

优点:与第二种方法不同,您可以避免性能开销

  1. 开发具有单个连接池的数据微服务,该连接池从其他 MS 获取查询对象,触发对数据库的查询并将结果集对象返回给调用者。

优点:前期工作最少

缺点:多了一层,也就多了一个故障点。当您必须处理时,性能会下降serialization -> Http(s) network latency -> deserialization->(jdbc fun stuff which is part of either approach) -> serialization -> Http(s) network latency -> deserialization。(在您的情况下,这种性能成本可能可以忽略不计。但如果您的服务中每一毫秒都很重要,那么这是一个巨大的决定因素)

在我看来,在分析我的域和数据存储之前,我不会单独拆分应用程序层。

这是一本好书:http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data/