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

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 数据库中理想的并发连接实际上比大多数人想象的要小。