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

Question

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

我们这里有一个瓶颈，因为各种原因，比如大量的数据库对象，与其他系统的紧密依赖等等，不会在这个时间点改变数据库体系结构。

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

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

1. 计算每个应用程序功能当前正在使用的连接数，并达到每个服务的最大/最小连接数 - 这是一个非常繁琐的过程，我们没有任何机制来获取每个应用程序功能的连接数。
2. 要使用从其他MS获取查询对象的单个连接池开发数据微服务，请触发对数据库的查询并将结果集对象返回给调用者。

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

你能否建议任何其他标准方法在当前情况下有所帮助？

Answer 1

这都是关于权衡的问题。

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

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

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

2. 要使用从其他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 - 根本没有游泳池，可以按需打开连接。这就是函数式编程中使用的东西（如亚马逊lambdas）。它将减少打开连接的总数，但缺点是你失去了性能，因为开启的连接是昂贵的。

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

结论：如果微服务倾向于没有规模增长而没有池，如果它确实需要弹性地和指数地增长，我将计算数量，在最后一种情况下确保重试已到位，以防它没有得到连接在第一次尝试。

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

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