[{"data":1,"prerenderedAt":229},["ShallowReactive",2],{"blog:\u002Fblog\u002F2020\u002F09\u002F14\u002Fload-balancing-in-grpc\u002F":3},{"id":4,"title":5,"body":6,"categories":186,"comments":188,"date":189,"description":190,"draft":191,"extension":192,"legacySlug":193,"meta":194,"navigation":188,"path":222,"seo":223,"stem":224,"tags":225,"updated":227,"__hash__":228},"blog\u002Fblog\u002F2020\u002F09\u002F14\u002FLoad-Balancing-in-gRPC.md","【译】gRPC负载均衡",{"type":7,"value":8,"toc":168},"minimark",[9,32,36,39,42,46,49,52,55,59,62,65,68,71,74,77,80,83,86,89,92,95,98,101,104,107,110,113,116,123,126,129,136,139,160,163],[10,11,12,13,20,21,26,27,31],"p",{},"原文:",[14,15,19],"a",{"href":16,"rel":17},"https:\u002F\u002Fgithub.com\u002Fgrpc\u002Fgrpc\u002Fblob\u002Fmaster\u002Fdoc\u002Fload-balancing.md#load-balancing-in-grpc",[18],"nofollow","Load Balancing in gRPC","\n翻译整理: ",[14,22,25],{"href":23,"rel":24},"https:\u002F\u002Fzhizhi123.com",[18],"本站"," 译文链接:",[14,28,5],{"href":29,"rel":30},"https:\u002F\u002Fwww.zhizhi123.com\u002Fblog\u002F2020\u002F09\u002F11\u002Fload-balancing-in-grpc\u002F",[18],"。 转载请保留原文出处和译文译者和出处。",[33,34,35],"h2",{"id":35},"范围",[10,37,38],{},"这篇文档解释了gRPC中的负载均衡设计",[33,40,41],{"id":41},"背景",[43,44,45],"h3",{"id":45},"基于每次调用的负载均衡",[10,47,48],{},"值得注意的是，gRPC中的负载平衡是基于每个调用，而不是基于每个连接。换句话说，即使所有请求都来自一个客户端，我们仍然希望它们在所有服务器上实现负载平衡。",[43,50,51],{"id":51},"负载均衡方法",[10,53,54],{},"在讨论gRPC细节之前，我们先探讨一些实现负载平衡的常用方法。",[56,57,58],"h4",{"id":58},"代理模型",[10,60,61],{},"使用代理提供了可靠可信赖的客户端，可以向负载平衡系统报告负载。代理通常需要更多的资源来操作，因为它们有RPC请求和响应的临时副本。此模型还增加了rpc调用的延迟。",[10,63,64],{},"代理模式被认为是低效的，当请求像存储这样的“重”服务",[56,66,67],{"id":67},"平衡自感知客户端",[10,69,70],{},"这种“胖”客户端在自身放置了许多负载均衡逻辑。例如，客户端可以包含许多负载均衡策略（Round Robin轮询、随机等等）, 通过使用这些策略，客户端从一个列表中选择服务端（servers）。在这种模型中，servers列表要么可以静态配置到客户端，要么可以由名称解析服务提供，或者由外部负载均衡器提供，等等。在任何情况下，由客户端负责从列表中选择首选服务器。",[10,72,73],{},"这种方法的其中一个缺点是为多种语言和或版本的客户端编写和维护负载均衡策略。这些策略可能相当复杂。一些算法同时需要客户端和服务端的通信，所以客户端需要变得更“胖”以支持用户rpc请求之外的rpc请求来获得健康和负载的信息。",[10,75,76],{},"它还会显著地使客户机的代码复杂化:新的设计隐藏了多层负载平衡的复杂性，并将其作为一个简单的服务器列表呈现给客户机。",[56,78,79],{"id":79},"外部负载均衡服务",[10,81,82],{},"客户端负载平衡代码保持简单和轻便，实现了用于服务器选择的众所周知的算法(例如，轮询调度)。复杂的负载平衡算法由负载平衡器提供。客户端依赖于负载平衡器来提供负载平衡配置，以及客户端应该向其发送请求的服务器列表。负载均衡器根据需要更新服务器列表，以平衡负载并处理服务器不可用或运行状况问题。负载均衡器将做出任何必要的复杂决策并通知客户端。负载平衡器可以与后端服务器通信，以收集负载和运行状况信息。",[33,84,85],{"id":85},"需求",[43,87,88],{"id":88},"简单的接口和客户端",[10,90,91],{},"gRPC客户端负载平衡代码必须简单轻便。客户端应该只包含用于服务器选择的简单算法(例如，轮询调度)。对于复杂的算法，客户端应该依赖于一个负载均衡器来提供负载平衡配置，以及客户端应该向其发送请求的服务器列表。平衡器将根据需要更新服务器列表，以平衡负载并处理服务器不可用或运行状况问题。负载均衡器将做出任何必要的复杂决策并通知客户端。负载平衡器可以与后端服务器通信，以收集负载和运行状况信息。",[43,93,94],{"id":94},"安全",[10,96,97],{},"负载均衡器可能与实际的服务器后端分离，负载均衡器的破坏只会导致负载均衡功能的破坏。换句话说，与没有负载平衡的可比情况相比，一个损坏的负载均衡器不应该使客户机更信任(潜在恶意的)后端服务器。",[33,99,100],{"id":100},"架构",[43,102,103],{"id":103},"一览",[10,105,106],{},"gRPC中负载平衡的主要机制是外部负载平衡，其中外部负载平衡器为简单的客户端提供服务器的最新列表。",[10,108,109],{},"gRPC客户端确实支持用于内置负载平衡策略的API。 但是，其中只有少数（其中一个是grpclb策略，该策略实现了外部负载平衡），并且不鼓励用户尝试通过添加更多策略来扩展gRPC。 相反，应在外部负载均衡器中实施新的负载均衡策略。",[43,111,112],{"id":112},"工作流",[10,114,115],{},"适合于gRPC客户端工作流的负载均衡策略，运行在名称解析和与服务器的连接之间。运作方式如下：",[10,117,118],{},[119,120],"img",{"alt":121,"src":122},"image-20200914145440850","\u002Fblog-assets\u002FLoad-Balancing-in-gRPC\u002Fimage-20200914145440850.png",[10,124,125],{},"1.启动时，gRPC客户端发出服务器名称的名称解析请求。 该名称将解析为一个或多个IP地址，每个IP地址将指示它是服务器地址还是负载平衡器地址，以及一个服务配置，该服务配置指示要使用哪种客户端负载平衡策略（例如，round_robin或grpclb ）。",[10,127,128],{},"2.客户端实例化负载平衡策略。",[130,131,132],"ul",{},[133,134,135],"li",{},"注意：如果解析程序返回的任何地址之一是平衡器地址，则客户端将使用grpclb策略，而不管服务配置请求哪种负载平衡策略。 否则，客户端将使用服务配置请求的负载平衡策略。 如果服务配置未请求任何负载平衡策略，则客户端将默认为选择第一个可用服务器地址的策略。",[10,137,138],{},"3.负载平衡策略创建到每个服务器地址的子通道",[130,140,141,144],{},[133,142,143],{},"对于除grpclb以外的所有策略，这意味着解析程序返回的每个地址都有一个子通道。 请注意，这些策略会忽略解析器返回的任何平衡器地址。",[133,145,146,147,150,151,153,154,156,157,159],{},"对于grpclb策略，工作流程如下：",[148,149],"br",{},"​\t\ta. 该策略打开一个流，指向名称解析器返回的其中一个均衡器地址。它向均衡器请求最初由客户端请求的服务器名称对应的服务器地址（即，最初传递给名称解析器的相同名称）",[148,152],{},"​\t\t注意：在grpclb策略中，名称解析器返回的非负载均衡器地址用于在启动LB策略后无法连接到均衡器时的回退措施。",[148,155],{},"​\t\tb. 如果负载均衡器需要这些信息，那么负载均衡器导向到客户端的gRPC服务器可以将负载上报到负载均衡器。",[148,158],{},"​\t\tc. 负载平衡器将服务器列表返回给gRPC客户端的grpclb策略。然后grpclb策略将创建到列表中每个服务器的子通道。",[10,161,162],{},"4.对于每一个RPC请求，负载均衡器策略决定RPC应该被发送到哪一个子通道（即：哪一个服务器）",[130,164,165],{},[133,166,167],{},"在grpclb策略的情况下，客户端将按照负载均衡器返回请求的顺序向服务器发送请求。如果服务器列表为空，调用将阻塞，直到收到一个非空列表。",{"title":169,"searchDepth":170,"depth":170,"links":171},"",2,[172,173,178,182],{"id":35,"depth":170,"text":35},{"id":41,"depth":170,"text":41,"children":174},[175,177],{"id":45,"depth":176,"text":45},3,{"id":51,"depth":176,"text":51},{"id":85,"depth":170,"text":85,"children":179},[180,181],{"id":88,"depth":176,"text":88},{"id":94,"depth":176,"text":94},{"id":100,"depth":170,"text":100,"children":183},[184,185],{"id":103,"depth":176,"text":103},{"id":112,"depth":176,"text":112},[187],"微服务",true,"2020-09-14","原文:Load Balancing in gRPC 翻译整理: 本站 译文链接:【译】gRPC负载均衡。 转载请保留原文出处和译文译者和出处。 范围 这篇文档解释了gRPC中的负载均衡设计 背景 基于每次调用的负载均衡 值得注意的是，gRPC中的负载平衡是基于每个调用，而不是基于每个连接。换句话说",false,"md","Load-Balancing-in-gRPC",{"excerpt":195},{"type":7,"value":196},[197,208,210,212,214,216,218,220],[10,198,12,199,20,202,26,205,31],{},[14,200,19],{"href":16,"rel":201},[18],[14,203,25],{"href":23,"rel":204},[18],[14,206,5],{"href":29,"rel":207},[18],[33,209,35],{"id":35},[10,211,38],{},[33,213,41],{"id":41},[43,215,45],{"id":45},[10,217,48],{},[43,219,51],{"id":51},[10,221,54],{},"\u002Fblog\u002F2020\u002F09\u002F14\u002Fload-balancing-in-grpc",{"title":5,"description":190},"blog\u002F2020\u002F09\u002F14\u002FLoad-Balancing-in-gRPC",[226,187],"gRPC",null,"Fg_kg2mQ49vAHvvgL4wqET_kH0DJtaQnZWAiZpS1A3Q",1783807996125]