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

业界资讯 来源:聊聊架构 发布:2016-10-12 浏览:331

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

在过去的一年中,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谈到他们计划如何平滑地发布这个新负载均衡系统,并预计在近期开源该项目。

原    文:聊聊架构
作    者: 周元昊 译

「GitHub」都使用了那些技术和工具?他又是怎样从0到1发展起来的?
点击查看「GitHub」-- 技术栈

免责声明:

  1. SDK.cn遵循行业规范,所有转载文章均征得作者同意授权并明确标注来源和链接。
  2. 我们十分尊重原创作者的付出,本站禁止二次转载如需转载请与原作者取得联系。
  3. 转载SDK.cn的原创文章需注明文章作者、链接和"来源:SDK.cn"并保留文章及标题完整性未经作者同意不得擅自修改。
  4. 作者投稿可能会经SDK.cn适当编辑修改或补充。

评论 (100)

推荐工具 意见反馈