GitHub是如何改进自身的DNS架构的

语言开发 GitHub

摘要： 据GitHub高级架构工程师Joe Williams撰文介绍，过去数年中，GitHub一直使用的是一个简单的DNS架构。虽然它也能适合工作需求，但现在GitHub已迁移到一个能更好地支持自身规模的新架构。

作者： Sergio De Simone

正文：

据GitHub高级架构工程师Joe Williams撰文介绍，过去数年中，GitHub一直使用的是一个简单的DNS架构。虽然它也能适合工作需求，但现在GitHub已迁移到一个能更好地支持自身规模的新架构。

Williams提及，很多应用对DNS的解析性能或可用性十分敏感，这是GitHub采用新的DNS处理模型的一个原因。DNS会导致用户性能降级，甚至无法提供服务。当使用原有的DNS架构进行配置和代码更改时，这个问题亟待解决。此外，工程师也难以识别一些故障的导致根源，他们唯一能使用的工具是tcpdump。除了对上述问题的改进，GitHub工程师还瞄准于：

• 增加内部域（Zone）和外部域配置的灵活性。除非做特殊的配置，否则内部域对外是不可见的。同时，从内网的内部就可以访问外部域。
• 改进缓存节点（Cache）和授权节点（Authority）间的角色隔离。
• 支持基于部署和基于API的工作流，实现更改的自动化。
• 避免任何外部依赖，改进可靠性。

在GitHub设计的架构中，有三种类型的节点：

• 缓存节点。它部署于各数据中心内，负责向应用提供实时数据，使应用无需跨数据中心。
• 边缘节点（Edge）。它是各数据中心本地的授权节点，行使网关职责，处理来自缓存节点的请求，并负责域传送（Zone Transfer）。
• 授权节点。它是DNS主服务器，管理来自边缘节点的域交换，并提供创建、修改或删除记录的HTTP API。

日志功能是GitHub新DNS架构的另一个改进。GitHub工程师根据自身需求，选择了对缓存节点使用Unbound，边缘节点使用NSD，授权节点使用PowerDNS。

前面提到，外部域（github.com）可从内部域（github.net）访问，不需要与外部DNS提供商通信。这是使用Unbound实现的。此外，Unbound还支持在内部DNS失败时对外部网络的访问。

在Williams的帖子中，还给出了更多的技术细节，值得全面一读。

查看英文原文： How GitHub Revamped its DNS Infrastructure