如何解决高效的特使代理
让我们进行一个非常常见的设置
带有 istio 的 K8s
入口代理(envoy 或 nginx)
以及服务 A 在每个 Pod 级别具有服务 A 的特使代理。
现在让我们举一个例子,我们有一个想要与服务 A 通信的外部客户端。客户端通信的协议是不可知的(http rest/grpc/... 无关紧要)。虽然在协议级别,我们可以决定一些在代理和客户端之间进行对话的比较有效的东西,但我们如何使代理服务 A 的 pod 的 Envoy sidecar 通信更高效。
req/rep 模型的一般范例是根据请求打开和关闭套接字。每次这需要 tcp 握手时,http 撕裂/关闭当然如果大规模完成可能会导致非平凡的 cpu 峰值超过对于此类任务来说非常普通的事情。在内部,在服务之间,我们可以使用类似 grpc 之类的东西,它在 http2 上运行,它可以保持该层的连接打开;从而减少 req/rep 的 CPU 需求。在我所说的场景中,我们指的是从客户端到路由器/代理到前端服务的流程。路由器/代理将终止并处理 ssl 加密/解密,然后再循环到服务 A 中的相应 pod(通过 sidecar 特使代理)。由于此代理终止,我们如何使入口路由器/代理与服务 A 中的 pod 之间的连接更具可扩展性。是否有某种模式可以像 grpc 一样运行?也许我在 istio 和 envoy 上读错了文档,但是如果我们使用 grpcweb 之类的东西,那仍然会在代理级别终止,并且入口代理之间的切换为特使边车提供服务将是更传统的代表/ req per request 模型(在每个请求的基础上断开连接)?我错过了什么?或者有没有办法解决这个问题。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。