01#

背景

在爱奇艺基础架构的早期规划中，业务应用主要依托公司自建IDC模式(私有云)进行私有化部署。随着业务的不断发展变化，自建IDC模式在成本控制、弹性扩展以及区域覆盖等方面逐渐暴露出很多局限性。与此同时，随着公有云技术的日益成熟，我们开始逐步引入公有云资源，形成了自建IDC与多家公有云并存的业务部署模式，即混合云网络架构。

02#

名词介绍 

Anycast（任播） 是一种网络通信技术，多个服务器共享同一个 IP 地址，用户请求会自动路由到距离最近、负载最低的节点，实现高效分发。

03#

混合云场景下我们遇到的问题

自建IDC的服务模式下，爱奇艺内网DNS架构 ，从最早的各IDC独立部署，IDC内独自服务；逐步过渡到Anycast DNS，实现了DNS服务IP统一、服务配置统一、全局化服务统一的目标。

当引入公有云后，自建IDC与公有云分别隶属于不同的服务体系，业务部署在云厂商的Overlay网络（虚拟网络）上，底层Underlay网络（物理网络）对于我们并不直接可见，因此很难通过直接调整公有云网络实现Anycast DNS，DNS在部署维护等方面再次出现差异化。

为了解决这一问题，实现混合云场景下的DNS服务大统一，爱奇艺联合公有云厂商共同设计了新的网络方案，成功将Anycast DNS扩展至公有云，把云下的Anycast DNS搬到了云上，本文即介绍这一方案的实现。

04#

自建IDC场景下的DNS架构介绍

自建IDC场景下，我们采用了融合Anycast技术的多层DNS架构，以确保DNS服务的可靠性、可扩展性和高效性。这种架构不仅增强了DNS服务的整体性能，提升了系统的稳定性和响应速度，还使DNS架构具备了弹性伸缩的能力，降低了故障率与维护成本，增强了基础架构服务的稳定性。

Anycast DNS方案架构如下图所示，多个IDC均部署DNS服务，通过动态BGP网络协议将Anycast IP通告到内网全网，实现1个DNS入口 IP服务全网的目的。

当本地机房的DNS服务器发布Anycast IP地址后，本地业务服务器能够访问到最近的DNS服务器，最大化提升通信效率和响应速度。以IDC-A和IDC-B为例，IDC-A中的业务服务器会优先访问本机房内部的DNS服务器。一旦IDC-A机房内的DNS服务器整体故障，通过BGP网络路由的自动收敛，业务DNS请求会被自动转发到距离IDC-A机房最近的IDC-B或IDC-C机房内的DNS服务器进行处理，从而有效降低IDC-A机房内DNS服务异常时，对业务访问的影响。

05#

混合云场景下LB+DNS架构方案

引入公有云后，为了对业务提供统一、稳定、高效、安全的DNS服务，理想的情况是将私有云Anycast DNS架构扩展到公有云上，在整个混合云架构中需要实现如下目标：

• 标准配置：所有业务主机使用统一Anycast IP作为唯一服务地址；

• 统一管理：所有DNS服务器和自建IDC保持一致，均平台化管理、自动化配置，做到DNS服务一键部署、一键上下线；

• 全局服务：自建IDC和公有云使用统一的 DNS 服务IP，既能解析私有云域名，又可解析公有云域名，同时可实现跨公有云解析;

但是在公有云场景下，业务均部署在云厂商的Overlay网络（虚拟网络）上，底层Underlay网络（物理网络）对于我们并不直接可见，因此很难通过直接调整公有云网络实现Anycast DNS。为了解决这一问题，我们提出了公有云环境下基于LB负载均衡的DNS架构方案。

如上图所示，将云下的Anycast DNS IP绑定到LB上，统一内网全网的DNS 服务IP，LB后端挂载真正的DNS服务器，这样模拟实现类似于Anycast的架构，具备统一服务IP，容灾、切换、高可用等部分Anycast能力特征。

虽然通过LB的方式在公有云实现了类似于Anycast DNS部署方案，但是此方案相比真正的Anycast方案仍存在缺陷。在Anycast场景下可以通过控制DNS服务器上Anycast IP的发布和撤销，灵活的上线和摘除单个节点的DNS服务，并且单个节点故障后网络会自动收敛切换到其他节点。

但在LB方案中，因Anycast IP所在网段，在公有云平台是以子网段的方式存在于VPC内。当LB后端DNS服务设备全部故障，或LB自身服务发生故障，是无法快速摘除LB上Anycast DNS服务IP的，可能造成长时间的故障。简而言之，LB方案无法灵活控制Anycast IP的生效和撤销。

06#

混合云场景下ER+DNS架构方案

为了解决上述场景中存在的设计缺陷，我们与公有云基础架构团队合作探讨，设计了基于公有云企业路由器（Enterprise Router, ER）的Anycast DNS方案，以实现真正意义上的混合云DNS统一。

前文提到的公有云实现Anycast DNS最大的挑战在于，公有云的Underlay网络对于我们并不可见，无法将DNS和网络便捷的联动结合。

而公有云ER提供了强大的网络能力，支持BGP路由协议，为Anycast IP动态发布提供了解决方案；支持GRE VPN tunnel，为Anycast DNS和Overlay网络结合提供了交互方法；同时ER支持旁挂方式，这样在不影响现有网络的情况也可以完成部署上线。

• 爱奇艺自建IDC和公有云通过专线互联，公有云ER具备连通公有云和私有云的能力，为保证当前业务稳定性，不影响现有业务转发，采用ER旁挂的方式，ER旁挂到新加坡公有云现有的VPC上

• 云上DNS服务器和公有云ER通过GRE VPN实现Overlay互联

• 云上DNS服务器部署Bird路由软件，通过GRE VPN tunnel和公有云ER建立BGP连接

• 云上DNS服务器配置Anycast DNS IP，通过BGP路由协议通告Anycast DNS IP到公有云ER

• 公有云ER通过BGP学习到Anycast DNS IP路由后，通告给新加坡公有云VPC

业务服务器DNS请求转发路径：

1. VPC内服务器访问 Anycast DNS IP，查看VPC路由表，路由下一跳指向公有云ER
2. DNS查询请求报文转发到公有云ER，ER设备查询路由表，发现通过BGP协议学习到了Anycast DNS IP路由，下一跳指向GRE VPN tunnel
3. ER将请求报文通过GRE VPN tunnel转发至对端的DNS服务器
4. DNS服务器均配置有Anycast DNS IP，可以响应客户端的DNS查询请求

相比于公有云上LB的DNS方案，该方案真正实现了Anycast DNS，做到公有云和私有云的完全统一。云上云下DNS服务器均部署Bird路由软件，统一采用BGP路由协议，平台可以无差别的统一管理DNS服务器，可灵活控制单节点Anycast DNS IP的上下线。

通过新的方案，私有云与公有云之间真正实现了DNS服务集群互备，当私有云内DNS服务集群故障时，通过操作Anycast DNS IP的取消和发布，可以快速将服务切换到公有云集群。当公有云内DNS服务集群故障时，亦可以快速将服务切换到私有云集群或其他公有云集群，最大限度的降低底层基础服务异常时对上层业务的影响。

07#

总结与展望

也许你还想看

助力用户增长数据可视化分析：天玑个性化数据大盘

实时数仓2.0：更低的成本获取更及时的数据

服务性能防腐体系：基于自动化压测的熔断机制

原文始发于微信公众号（爱奇艺技术产品团队）：混合云场景下基于Anycast网络建设内网DNS服务