云原生环境中的连接池 [英] Connection pooling in cloud native environment
问题描述
在云原生环境中是否仍需要连接池?
Is connection pooling still needed in a cloud native environment?
过去，连接池(例如开放式数据库连接)非常流行.
Connection pools (for example open database connections) were very popular in the past.
我猜(不知道)，在云原生环境中，不再需要它们了.
I guess (don't know) that in a cloud native environment they are not needed any more.
有一个容器/豆荚池.这样就不再需要连接池.
There is a pool of containers/pods. This way connection pooling is hardly needed any more.
这是真的吗?
推荐答案
与往常一样，请进行测量，不要猜测，但是，是的，如果您关心性能，仍然希望以某种方式进行连接池.
As always, measure, don't guess, but yes, if you care about performance you still want connection pooling in some way.
除了上述原因(TCP三向握手)之外，出于以下原因，您还需要连接池:
Besides the aformentioned reason (TCP 3-way handhsake) you also want connection pooling for these reasons:
- 数据库可能需要为每个连接分叉或启动一个新进程，这可能是一项非常昂贵的操作
- 关闭连接后，操作系统可能必须将数据库进程清理到安全内存，文件描述符，套接字等.
- 数据库可能需要验证用户的登录凭据，在某些情况下，该凭据可能是LDAP用户帐户，因此涉及另一个网络往返行程
- 如果您的连接不是普通的TCP连接，但是在最坏的情况下(可能无法恢复会话)使用SSL/TLS，则可能会导致TLS完整握手的开销，包括验证RSA签名和检查状态.证书通过互联网上的CRL或OCSP
我们专业地使用它，并且:
We use this professionally and also:
- 池化httpclient(用于REST/SOAP Web服务)
- 池化与RabbitMQ的连接(RabbitMQ监视器可深入了解它们的名称:流失统计信息，以轻松查看建立新连接的频率)
您可能还想查看其他云架构解决方案"，例如:服务网格，其中服务网格
You may also want to check out other 'cloud architecture solutions' like the: service mesh of which Istio is an implementation that try to decouple this kind of concerns from your application in a microservice architecture. These may use a local proxy server with connection pooling in the so called 'Side car pattern'. For a more complete explanation see: Red Hats explanation of a Service Mesh
这篇关于云原生环境中的连接池的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
