我已经阅读了https://github.com/grpc/grpc/blob/master/doc/load-balancing.md上的负载平衡页面，但仍然对后端 GRPC 之间负载平衡的正确方法感到困惑实例。我们正在部署多个 gRPC“微服务”实例，并希望我们的其他 gRPC 客户端能够在它们之间进行路由。我们将这些部署为 Kubernetes（实际上是 Google Container Engine）中的 pod。
谁能解释在 gRPC 服务器之间负载平衡 gRPC 客户端请求的“推荐”方法？客户似乎需要了解端点——难道不能利用 Container Engine 中内置的 LoadBalancer 来提供帮助吗？
不能说kubernetes，但是关于gRPC负载均衡，基本上有两种做法：
grpc::ChannelArguments::SetLoadBalancingPolicyName“round_robin”作为参数（将来也可以通过“服务配置”进行选择，但如何在 DNS 记录中对该配置进行编码的设计尚未最终确定）。如果您有任何问题，请告诉我。
对于 grpc 服务器之间的负载平衡，kubernates 默认负载平衡不会有帮助，因为它是 L4 负载平衡器。您将需要 L7 负载均衡器。
为什么是L7？
grpc 使用 http2，其中连接是持久的，请求将通过同一连接发送。L4 负载平衡器将使用 tcp 连接进行负载平衡，但您需要在请求级别进行负载平衡，因此我们需要 L7 负载平衡器。尤其是在 grpc 服务器之间进行通信时。
有几个选项，您可以使用Linkered/Envoy它们，它们可以很好地与 kubernates 配合使用，并且还提供了良好的服务网格。
要将您的服务公开给外部工作，您可以使用 nghttpx 和 nghttpx Ingress 控制器。
您也可以使用客户端负载平衡，但我认为这没有什么好处。
正如萨马伦德拉所说
您可以查看Envoy，最初是在 Lyft 构建的。
它对传入和传出连接的 HTTP/2 和 gRPC 具有一流的支持。
我们一直在 gojek 为我们的 gRPC 服务使用 envoy，它在相当高的负载下为我们提供了很好的服务。
在 Fulcrum，我们也遇到过类似的情况。
我们还完全在微服务架构上构建了一个产品，并决定使用 gRPC 框架。然后，我们立即面临如何使用 Application Load Balancer（第 7 层）对流量进行负载平衡的问题。事实证明——AWS 还不支持 HTTP 2.0。
正如上面的评论者所指出的，Envoy 是一个很好的选择。它是在 Lyft 开发的，非常棒。与替代方案相比，它非常轻量级，并且很容易整合到微服务架构中。
基本上，我们使用了标准的 Frontend Envoy 负载均衡器。此外，还有称为 Sidecar 的负载均衡器。它们中的每一个都放置在每个服务实例附近。他们专门与附近的服务合作，并且彼此之间也有联系。
因此，前端代理总是有一个连接，或者它可以在需要时创建一个。它使用“循环”模型来发送请求。
以下是我们对 gRPC 负载均衡体验的完整描述 > https://fulcrum.rocks/blog/load-balancer-grpc-aws 我们还创建了一个非常简单的服务，您可以从我们的 GitHub 下载并自行启动Playground机器：https ://github.com/fulcrum-rocks/grpc-load-balancing-playground
static_resources:
listeners:
- address:
socket_address:
address: 0.0.0.0
port_value: $LISTEN_PORT
filter_chains:
- filters:
- name: envoy.http_connection_manager
config:
codec_type: http2
stat_prefix: ingress_grpc
http2_protocol_options: {}
route_config:
name: service_route
virtual_hosts:
- name: service_host
domains:
- "*"
routes:
- match:
prefix: "/"
grpc: {}
route:
cluster: service_cluster
timeout:
seconds: 0
nanos: 0
http_filters:
- name: envoy.router
config: {}
clusters:
- name: service_cluster
connect_timeout: 0.25s
type: strict_dns
lb_policy: round_robin
http2_protocol_options: {}
hosts:
- socket_address:
address: $SERVICE_DISCOVERY_ADDRESS
port_value: $SERVICE_DISCOVERY_PORT
admin:
access_log_path: "/dev/null"
address:
socket_address:
address: 0.0.0.0
port_value: 80您可能想查看nghttpx和nghttpx Ingress 控制器项目。这些项目使得为 HTTP/2 流执行 L7 负载平衡成为可能。
另请查看https://cloud.google.com/endpoints/docs/architecture-overview，了解有关 Google Cloud Platform 中捆绑的端点管理的一些信息。
如果在 AWS/ECS 中https://aws.amazon.com/blogs/aws/new-network-load-balancer-effortless-scaling-to-millions-of-requests-per-second/ 将用于循环连接在您的目标群体之间。
您确实需要做一些事情来收听 NLB 只能在 HTTP1 中执行的运行状况检查。您还可以终止自己的 SSL。