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节点。