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

Question

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

我们在这里遇到了一个瓶颈，由于各种原因，比如大量的数据库对象、与其他系统的紧密依赖性等，目前无法更改数据库体系结构。

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

目前，我在想两个解决办法

>

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

要开发一个带有单个连接池的数据微服务，该连接池从其他MS获取查询对象，触发对数据库的查询，并将resultset对象返回给调用者。

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

你能建议在目前的情况下有什么其他的标准方法吗？

Answer 1

我在工作中也面临着类似的困境，我可以分享我们迄今为止得出的结论。

目前没有银弹，所以：

1-计算连接数除以微服务实例所需的总连接数，如果你的微服务不需要大规模扩展，那么它将很好地工作。

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

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

结论：如果微服务的规模没有增长，并且没有池，如果它确实需要以弹性和指数形式增长，我会计算这个数字。在最后一种情况下，请确保在第一次尝试时没有连接的情况下进行重试。

这里有一个有趣的灰色地带，在等待一种更好的方法来控制微服务中的连接池。

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

Answer 2

这都是关于权衡的。

1. 计算每个应用程序功能当前使用的连接数，并得出每个服务的最大/最小连接参数。

缺点：如你所说，一些分析和猜测需要达到每个应用功能的甜蜜连接数。

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

优点：前期工作最少

缺点：多了一层，又多了一个故障点。由于必须处理序列化，性能会降低-

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

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