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

Question

我正在使用Spring Boot + Spring Cloud + Spring JDBC为单片应用程序开发微服务。 当前，该应用程序正在通过tomcat JNDI连接池连接到单个数据库。

我们这里有一个瓶颈，由于各种原因（例如大量的db对象，与其他系统的紧密依赖关系等），此时不更改数据库体系结构。

因此，我们已根据应用程序功能隔离了微服务。我担心的是，如果我们开发的微服务每个都有自己的连接池，那么与数据库的连接数量会成倍增加。

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

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

2. 要开发具有单个连接池的数据微服务，该连接池将从其他MS获取查询对象，将查询触发到数据库，然后将结果集对象返回给调用方。

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

请问您可以提出其他一些对您有所帮助的标准方法吗？ 当前情况？

Answer 1

这与权衡有关。

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/

Answer 2

我在工作中面临着类似的困境，我可以分享到目前为止所得出的结论。

目前没有灵丹妙药，所以：

1-如果您的微服务不需要极大地扩展弹性规模，那么计算连接数除以微服务实例所需的总连接数将很有效。

2-根本没有池，让连接按需打开。这就是函数编程（例如Amazon lambdas）中使用的东西。它将减少打开的连接总数，但缺点是您会失去性能，因为即时打开连接非常昂贵。

您可以实现某种主题，使您的服务知道侦听器中实例的数量已更改并更新总连接数，但这是一个复杂的解决方案，并且违反了微服务原理，即您不应更改配置服务开始运行后的状态。

结论：如果微服务需要弹性和指数增长，如果微服务趋于不按比例增长并且没有池，那么我将计算数字，在最后一种情况下，请确保重试到位，以防万一第一次尝试建立连接。

这里有一个有趣的灰色区域，等待着更好的方法来控制微服务中的连接池。

为了及时使问题变得更加有趣，我建议阅读
有关HikariCP的池大小调整的文章：https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing 数据库中理想的并发连接实际上比大多数人想象的要小。