GitHub 新负载均衡系统的设计历程

在过去的一年中，GitHub 一直在开发一个新的负载均衡系统——GitHub Load Balancer（GLB）。这个系统想要通过扩展使用普通的硬件来应对每天数十亿的连接。GitHub 工程师 Joe Williams 和 Theo Julienne讲解了GLB 的设计历程。

GitHub 根本的设计目标之一是希望能“扩展”IP，即，将单个公网 IP 的数据流量通过多个等价的连接分发到不同的目标机器。这通常是通过等价多路径路由（ECMP）来实现的，从而扩大带宽。然而，ECMP 在各个ECMP 节点发生变化，比如在节点失效或因维护需求而被移除时，表现不是很好。对GitHub 来说这是使用ECMP 最大的缺陷。

因此，GitHub 工程师考虑使用L4/L7 分离策略，将负载均衡节点分为两层， L4 和 L7 ，OSI 层据此来提供各个节点分发请求时需要的信息。L4 使用来源及目标 IP 地址和 TCP 端口号进行路由，而 L7 使用应用层信息来路由，这通常使用 HTTP 协议。在 L4/L7 分离的设计中，L4 节点通过 ECMP 拆分流量到 L7 节点，我们称前者为“director”节点，后者为“proxy”节点。Williams 和 Julienne 解释到，通常 ipvs/LVS 被应用于 L4 节点，而 L7 节点使用 haproxy 或类似工具。

L4/L7 分离带来最大的好处是，只要简单地将 L7 节点从服务 _ 新 _ 连接的节点池中移除，并服务到节点上现有连接全部结束，就可以在不影响正常运行的情况下移除一个 L7 节点。但另一方面，在 L4 节点失效或被移除时会导致访问中断。由于 git 无法进行重试或恢复已断开的连接，解决这个问题对 GitHub 来说尤为关键。

GitHub 通过使用 Rendezvous 哈希算法解决了这个最终问题，这个算法使 director 节点间协定应该由哪个 proxy 节点来处理某个请求。GLB 结合使用 Rendezvous 哈希算法与服务器直接返回模式，后者使返回报文直接从proxy 节点返回给客户端，从而绕过了原来分配请求到proxy 的director 节点。在GLB 中，使用Rendezvous 哈希的基本思想是要将请求转发表在各个director 节点间共享并保持同步。这大体上能保证即使一个director 节点失效或被移除，其他director 节点可以代替并将现存连接分配到正确的proxy 节点。

最后Williams 和Julienne 谈到他们计划如何平滑地发布这个新负载均衡系统，并预计在近期开源该项目。

查看英文原文： How GitHub Designed its New Load Balancer

感谢宋秉金对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。