Open NeoZephyr opened 2 years ago
gRPC 是基于 HTTP/2 构建的，HTTP/2 被设计为单个长连接。所有的请求是能够被多路复用的，同一时刻的多个请求能够使用同一个连接。通常情况下，这是非常有用的，能够减少连接管理的消耗。但是，一旦建立连接，就不会再进行平衡操作，所有的请求会被指向同一个目的端 pod
HTTP/1.1 也是具有长连接。但是 HTTP/1.1 具有连接循环的特点。因此。对于HTTP/1.1应用连接的负载平衡已经足够，不需要再进行其他额外的操作。
与 HTTP/2 相比，HTTP/1.1 无法复用请求。在同一时刻同个 TCP 连接中，只有一个 HTTP 能够被处理。当客户端发起请求后，它会一直等待到服务端的返回。在发起请求-响应周期时，不能在该连接上发出其他请求
为了实现 HTTP/1.1 下的并发请求，需要建立多个 HTTP/1.1 连接，并在所有这些连接中发出请求。此外，长时间的 HTTP/1.1 连接通常会在一段时间后过期，并被客户端（服务端）销毁。这两个因素相结合意味着 HTTP/1.1 请求通常在多个 TCP 连接之间循环，因此连接级别平衡起作用
应用程序代码自己管理维护目标负载平衡池。但由于 pod 可能发生迁移，应用程序必须监控 Kubernetes API 来保证相关数据的同步
以 headless services 形式部署应用。在这种情况下，Kubernetes 将在服务的 DNS 条目中创建多个 A 记录
NameResolver + load balancing policy + Headless-Service
gRPC 是基于 HTTP/2 构建的，HTTP/2 被设计为单个长连接。所有的请求是能够被多路复用的，同一时刻的多个请求能够使用同一个连接。通常情况下，这是非常有用的，能够减少连接管理的消耗。但是，一旦建立连接，就不会再进行平衡操作，所有的请求会被指向同一个目的端 pod
HTTP/1.1 也是具有长连接。但是 HTTP/1.1 具有连接循环的特点。因此。对于HTTP/1.1应用连接的负载平衡已经足够，不需要再进行其他额外的操作。
与 HTTP/2 相比，HTTP/1.1 无法复用请求。在同一时刻同个 TCP 连接中，只有一个 HTTP 能够被处理。当客户端发起请求后，它会一直等待到服务端的返回。在发起请求-响应周期时，不能在该连接上发出其他请求
为了实现 HTTP/1.1 下的并发请求，需要建立多个 HTTP/1.1 连接，并在所有这些连接中发出请求。此外，长时间的 HTTP/1.1 连接通常会在一段时间后过期，并被客户端（服务端）销毁。这两个因素相结合意味着 HTTP/1.1 请求通常在多个 TCP 连接之间循环，因此连接级别平衡起作用
应用程序代码自己管理维护目标负载平衡池。但由于 pod 可能发生迁移，应用程序必须监控 Kubernetes API 来保证相关数据的同步
以 headless services 形式部署应用。在这种情况下，Kubernetes 将在服务的 DNS 条目中创建多个 A 记录
NameResolver + load balancing policy + Headless-Service