我正在使用
spring boot
spring cloud spring JDBC开发用于单片应用程序的微服务.
目前,应用程序通过tomcat JNDI连接池连接到单个数据库.
我们这里有一个瓶颈,不是因为各种原因(例如大量的数据库对象,与其他系统的紧密依赖等)而在此时更改数据库体系结构.
因此,我们基于应用程序功能隔离了微服务.我担心的是,如果我们开发微服务,每个微服务都有自己的连接池,那么与数据库的连接数量会呈指数级增长.
目前,我正在考虑两种解决方案
>计算每个应用程序功能当前使用的连接数,并达到每个服务的最大/最小连接数 – 这是一个非常繁琐的过程,我们没有任何机制来获取每个应用程序功能的连接数.
>要开发具有单个连接池的数据微服务,该连接池从其他MS获取查询对象,触发对数据库的查询并将结果集对象返回给调用者.
不确定第二种方法是否是微服务架构中的最佳实践.
你能否建议任何其他有用的标准方法
现在的情况?
最佳答案 这都是关于权衡的问题.
>计算每个应用程序功能当前使用的连接数,并达到每个服务的最大/最小连接数.
缺点:正如你所说,一些分析和猜测需要达到每个应用程序功能的甜蜜连接数.
优点:与第二种方法不同,您可以避免性能开销
>要开发具有单个连接池的数据微服务,该连接池从其他MS获取查询对象,触发对数据库的查询并将结果集对象返回给调用者.
优点:前期工作量极少
缺点:再多一层,又一个故障点.由于必须处理序列化,性能会降低 – > Http(s)网络延迟 – >反序列化 – >(jdbc有趣的东西,这是任何一种方法的一部分) – >序列化 – > Http(s)网络延迟 – >反序列化. (在您的情况下,此性能成本可能可以忽略不计.但如果您的服务中每毫秒都是重要的,那么这是一个巨大的决定因素)
在我看来,在分析我的域和数据存储之前,我不会单独拆分应用程序层.