什么是BGP AnyCast？
BGP anycast就是
利用一个（多个） as号码在不同的地区广播相同的一个ip段。
利用bgp的寻路原则，短的as path 会选成最优路径（bgp寻路原则之n），从而优化了访问速度。
其实bgp anycast是不同服务器用了相同的ip地址。
阿里的DNS 就是使用了BGP AnyCast
“其实bgp anycast是不同服务器用了相同的ip地址。” 言简意赅啊！
根据这个网页资料，我对BGP anycast 的理解是IP anycast + bgp, ip anycast（ip任播）
本身就是多个主机使用同一个IP地址（该地址即这一组主机的共享单播地址）的一种技术，当发送方发送报文给这个共享单播地址时，报文会根据路由协议路由到这一组主机中离发送方最近的一台，所以这个技术也可以用来做负载均衡。
Anycast技术特点
Anycast
允许源结点向一组目标结点中的一个结点发送数据报，而这个结点由路由系统选择，对源结点透明；同时，路由系统选择“最近”的结点为源结点提供服务，从而在一定程度上为源结点提供了更好的服务也减轻了网络负载。正是Anycast
这一通信模式的特点，使它在IP网络中具有了应用前景。首先，分布的服务共享相同的IP地址，同时在IP层进行透明的服务定位，这使得各种网络服务特别是应用层服务具有更强的透明性，比如DNS（Domain Name System，域名系统），在IPv6网络中它可以共享一个熟知的IP地址，用户不需要特殊配置也不用关心访问的是哪一台DNS服务器；其次，路由系统选择了“最近”的服务，缩短了服务响应的时间，同时减轻了网络负载；最后，相同的服务在网络上冗余分布，路由系统可以提供机制选择负载相对轻的带宽相对高的路径来转发报文，这样就给用户带来了两个方面的好处：
DNSPod Public DNS+的架构是怎么样的？
Multicast
Unicast
如何借助Anycast技术拯救运维工程师的睡眠？
半夜十二点，小王正在酣睡。
突然一阵清脆的手机铃声响起，把小王从睡梦中拉扯回现实。
“喂，谁啊？”
“王工，我是监控中心的，公司的xxx服务器挂了，你赶紧看一下吧。”
小王揉了揉眼睛，起身打开笔记本电脑，开始了一宿的不眠夜。
作为一名运维工程师，以上桥段经常发生在大家身边。白天繁重的工作已经让人筋疲力尽，而夜间作为电话值班工程师，仍不得不面对时刻突发的网络或系统故障。生活黑白颠倒，日夜不分。
试问，拿什么来拯救运维工程上的睡眠？
再给大家说一个故事。
我有一个朋友，他是Cloudflare的网络工程师，咱姑且叫他“钱哥”。
我和钱哥闲聊之余，问了问他们的夜间电话值班任务是否繁重辛苦。他淡淡的回答如下：
“我们全世界范围内如果有某个站点（PoP）挂了，完全不担心也不用着急。工程师该睡觉睡觉，该休息休息。”
我十分不解，你要知道Cloudflare是一家全球CDN服务提供商，据说全世界10%的互联网流量都运行在他们家网络上。
常识性来说，拥有如此体量的公司，其中某一个区域性站点down掉是一件极其严重的事情。而钱哥的回答却让我百思不得其解，完全颠覆了我的认知。
都是工程师，差距如此之大，别人夜晚睡觉，我们机房干耗！
在我的一番追问之后，总算明白他们其中的奥秘，原来一切都归功于他们使用了Anycast这技术。
那我们是否也能像钱哥一样，借助于Anycast技术，还工程师们一个宁静的睡眠之夜？
科普科普，什么是Anycast技术？
在IP地址的世界里，大家熟知的IP地址类型大致有如下几种：
Unicast IP
单播IP，IP地址和主机是一一对应关系。
如下图，红色为数据包发送端，而绿色节点为数据包接收端。
当数据包发送给某一个特定IP地址时，全局下仅有一个数据包接收主机。此为Unicast。
Multicast IP
组播IP，组播IP拥有特定的IP地址段，当数据包发送给此组播IP地址后，组内成员都能收到此数据包的一份拷贝。
如下图，红色为数据包发送端，而绿色节点为数据包接收端。
当数据包发送给某一个特定组播IP地址时，同时存在多个数据包接收端。
Broadcast IP
广播IP，任意Unicast单播网段中最后一个IP地址。数据包发送给此地址会扩散给全广播域的成员。
如下图，红色为数据包发送端，而绿色节点为数据包接收端。
当数据包发送给广播IP地址时，所有成员均为数据包接收端。
而Anycast IP，则是集Multicast和Unicast特性于一身的特殊IP地址类型
Anycast中文称为任意播。
从宏观上来说，Anycast类似于Multicast，同一种类型的数据流同时存在多个接收者。
而从微观上来说，Anycast又有着Unicast的唯一性。每一个单独的IP会话都能够找到唯一的源主机和目标主机。
咋看之下很矛盾，其实不然.
以DNS请求为例，假设全国人民同一时间发送1百万个DNS请求，他们都是发送给1.1.1.1的Anycast DNS服务器地址。
宏观上来说，所有数据包都送达给了分布在全国各地的DNS服务器。处于各地的DNS服务器分别接收到了一定数量的DNS请求，并作出回复。这体现了Multicast的特性。
微观上，某一个特定的DNS请求数据包，一定是发送给了某一台DNS主机，而不是同时又多台DNS主机接收到了此数据包。此为Unicast特性。
如下图，红色为数据包发送端，而绿色节点为数据包接收端。
在Anycast 环境下，总的来说，同时存在多个有效的数据包接收端，但是就某一个特定IP数据包而言，仅有一个接收端主机收到了此数据包。
Anycast 到底牛掰在哪里？
在企业网络环境中，Anycast不太常见，其主要应用于大范围的DNS部署，CDN数据缓存，数据中心等。
自然而然，很多做企业网络维护的朋友会有疑问。怎么能让互联网的多个主机用同一个IP，这岂不是IP地址冲突了？
回答：
首先，每一个服务器主机处在不同的地理位置，他们之间不在同一个广播域内。所以把所有主机配置成相同的IP地址并不会引起我们日常所见的IP地址冲突。
其次，光靠配置相同的IP地址时不够的，我们还需要借助强大的BGP帮忙。
通过BGP，各个站点向Internet宣告相同的Anycast IP地址。
自然而然，Internet 就会接收到不同目标路径，但是具有相同IP地址段的prefix。那数据包是如何在这种环境下路由的呢？
别急，往下看。
为了让大家有更深刻的理解和认识，下面将详细描述Anycast的主要优势和用途
：
用途一：Load-balancing 负载均衡以及系统冗余性
不讲理论了，直接上例子，方便理解。
为了阐明使用Anycast和负载均衡，以及冗余性的关系，特举例如下：
假设我们现在有三个DNS服务器站点，地点分别在北京，上海，广州。他们服务了全国的DNS解析服务。
按照一般的解决方案，为了实现三个DNS服务器负载均衡，可能有人会考虑到使用硬件负载均衡设备，例如常见的F5负载均衡设备等。
但若使用硬件负载均衡，随之带来的问题有：
1. 网络流量瓶颈，所有有流量都需要先通过负载均衡设备，而硬件设备本身的吞吐量决定了整个网络环境的吞吐量。
2. 高昂的硬件成本，为了实现全国的流量负载均衡，试想需要多大吞吐量的硬件设备。硬件吞吐量越大，购买成本就越高。
而通过Anycast技术，无需要借助任何第三方负载均衡器，就可以轻松达到负载均衡的效果，同时还提供了冗余和高可靠性。
实施方案如下：
通过配置三个DNS站点的服务器IP为相同IP，例如1.1.1.1/32。然后通过各个站点的BGP对互联网宣告1.1.1.0/24的网段。
（注：为什么要宣告/24，而不是/32? 。因为在Internet里面，为了减小全球Internet路由表尺寸，默认情况下运营商只接受小于等于/8，而大于等于/24的网段宣告进入互联网。）
以上步骤完成以后，互联网路由表针对1.1.1.1/24会有三个不同的出口路由器，分别是北京，上海，广州。
重点来了，因为所有用户都使用1.1.1.1作为他们的DNS服务器。
以东北的用户来说，哪一台DNS服务器会给东北的用户提供解析呢？
答案就是：就近原则！
让我们来看看数据包在网络中的路由细节：
当用户的DNS请求到达运营商的宽带路由器以后，运营商的路由器会根据BGP的选路原则选择到达1.1.1.1的最优路径。
例如，在用户宽带运营商和DNS服务器Internet运营商相同的情况下，最终会以IGP metric为关键因素来决定哪个DNS服务器给用户提供服务。
而IGP的 Metric某种程度上就是物理距离的代表。
如上图，四川的宽带路由器通过查看BGP路由，发现1.1.1.1出口最优路由是在广州。那么四川用户的DNS数据包将被发送给广州的DNS服务器。
同理，东北的用户DNS解析将会被发往北京的DNS服务器，而江南一带的则是上海DNS服务器负责。
万一出现故障怎么办？
如果三台DNS服务器中某一台出现故障，例如广东DNS服务宕机。BGP协议会立即停止通告此1.1.1.0/24的网段。Internet 路由表将会只有北京和上海的DNS可供选择。
此时原广东DNS服务的用户将再次根据“就近原则”选择其他DNS服务器，例如上海DNS。
从而达到业务的平滑迁移和服务的高可用性。
基于以上的分析，我们很容易就得出如下结论：
全国用户最终会根据距离DNS服务器的远近来判断使用哪个DNS服务器做域名解析。
从DNS角度来说，正因为不同的地理位置用户会根据就近路由判断，从而选择不同的DNS服务器，最终会使三台DNS服务器达到负载均衡的效果。
若其中某一个节点出现故障以后，业务会立即迁移到其他可用的节点上，从而避免网路服务故障。完全不需要人工干预。
以上就是Anycast在负载均衡中的用途说明。
用途二：防范DDOS攻击
相信很多在运营商工作的朋友都非常讨厌DDOS攻击。
当DDOS发生时，10G或100Gbps的流量突然蜂拥而来，占用运营商核心MPLS网路带宽不说，这种洪泛攻击会给客户网络造成短时间的瘫痪。造成的损失极大。
在阐述Anycast防范DDOS攻击细节之前，让我们先来看看DDOS是如何产生的。
以NTP协议为例，NTP协议是client-server模式，客户发起NTP时间查询申请，服务器响应NTP查询。看似正常的NTP数据流量有时候及其容易被玩坏。
假设某个黑客控制了成千上万的僵尸主机，这些僵尸主机纷纷伪造如下数据包并发送给全球NTP服务器：
源地址：1.2.3.4 （伪造源地址为 被攻击者的IP地址）
目标地址：全球各个NTP服务器地址。（越多越好）
当全世界各地的NTP服务器收到此查询以后，它会把查询结果发送回给真正的受害者1.2.3.4。
这时IP地址为1.2.3.4 的受害者收到全世界的NTP服务器发过来的数据包时，其有限的带宽链路就很容易产生拥塞并造成服务中断。
假设这些僵尸不只是发送一次虚假数据包，而是上万次。
那么受害者接收到的NTP回复数据包量将如下：
虚假数据包发送数量 x 全世界NTP服务器的数量= 最终DDOS攻击的流量。
Anycast如何防范DDOS攻击？
好了，铺垫完成以后，回到正题。Anycast如何防范DDOS攻击？
DDOS攻击最关键一点，是需要把所有地理位置分散的小流量最终汇集到一个点。从而形成涛涛洪水。
正所谓以彼之道，还施彼身。
在Anycast环境下，由于多个地理位置不同的主机同时使用同一个IP地址。正因为如此，DDOS流量在穿越运营商路由器时，路由器会根据地理位置远近把数据包路由到距离源地址最近的受害者主机站点。从而分散掉整个DDOS流量。
还是以上述NTP协议DDOS为例。
假设IP为1.2.3.4的受害者恰巧布局了Anycast协议。其服务器分布在全国各地。
当DDOS来临时，不同的NTP服务器根据路由选择，把流量发送到距离NTP服务器最近的受害者服务器上。
最终，原本10Gbps-100Gbps的汇总流量被各个目标服务器以1Gbps不足的DDOS攻击消化掉。
如上图所示，DDOS流量最终被每一个Anycast 主机分散掉了。
大型企业使用案例
既然Anycast好处多多，有多少企业部署了呢？
据我了解，包括Microsoft，Cloudflare，LinkedIn以及其他企业都在全球范围内使用了Anycast技术。
下面我就以Cloudflare和LinkedIn为例给大家简单介绍下，他们是如何部署的。
Cloudflare
Cloudflare作为CDN网络佼佼者，其主要采用了Anycast技术为用户提供距离用户最近的Cache服务器。从而大大提高了用户的服务体验满意度。
Cloudflare全球建设了118个数据中心，凭借于Anycast的高冗余性，正如本文开头提到的，任何一个数据中心出现网络、系统故障。均不会影响客户体验度，所有当地的客户流量会自动路由到其他就近的数据中心。
上图为Cloudflare的全球数据中心分布图
借助于Anycast的优势，相比传统企业网络面对网络节点故障的脆弱性，Cloudflare这方便就显得非常游刃有余了。
下面这张图为Cloudflare的部分数据中心Pop节点，请重点关注红框部分。
红框部分是美国-费城的一个数据中心节点，尾随其后有一个关键字“Re-routed”。
其含义为，此数据中心因为故障或者其他原因不能正常工作，所有费城的Cloudflare用户流量将会被自动路由到离费城最近的数据中心，无需人工干预。
看到这里，有些老鸟就禁不住想问。
Anycast是挺不错，但是看起来都是例如DNS，或者CDN在使用。
而且，无论是DNS服务提供商还是CDN服务提供商，他们最大的特点在于：每个Pop站点的服务器内容完全一样，所以客户无论访问站点A或者站点B，均能获取到相同的内容。
那让我们来看一个不一样的例子，如下。
LinkedIn大家最熟悉不过了，找工作攀人脉LinkedIn是经常去的地方。
但是你可知道LinkedIn同样使用了Anycast技术。可是LinkedIn是纯粹的网页内容服务提供商。他与CDN，DNS提供商等性质不太相同。
而且大家需要注意的是，LinkedIn的流量可全是HTTPS，TCP流量。并非一般大家部署的DNS UDP流量。
那为什么LinkedIn也对Anycast如此感兴趣呢？
故事要从几年前说起。
话说当LinkedIn业务急速扩展以后，出现了用户体验度差的问题，原因在于“时延”两个字。
因为数据中心地理位置固定，而用户位置可能是全世界各地。很自然，地理位置遥远的用户访问LinkedIn时会产生高时延问题。加上HTTP，HTTPS协议采用了话痨型的TCP协议。
这TCP几次握手来回以后，加上后续HTTP数据流。本来时延就高的链接加上TCP信令数据包一来二去。用户体验度非常糟糕。
为了解决以上问题，LinkedIn引入小型数据中心站点(Pops)。在全世界有业务的地方构架小型DC。同时小型DC与美国总部的数据中心之间长期维持着稳定的TCP会话链接。
当远端用户访问LinkedIn后，TCP链接其实是发送给了当地的小型DC，小型DC再通过已有的TCP链接访问总部DC。从而大大减少了中间TCP信令会话的数量，变相降低了访问延时，提高了用户体验度。
上图为，在没有小型数据中心的情况下，人机交互的流程以及时延。
下图为在用户所在地部署小型数据中心以后，时延的变化。
哎哎哎，别扯远了，这和Anycast有半点关系么？
当LinkedIn在全世界范围内大批量部署小型DC以后，摆在他们面前的问题是，如何让用户能够就近访问当地的小型DC，而不是选择远端的数据中心总部？
这不就是Anycast擅长的么？
对，LinkedIn也是这么想的，于是乎他们把整个美国的小型DC的IP地址修改为相同的IP，并通过BGP发布到Internet。
当用户访问LinkedIn时，DNS解析会返回此小型DC 的IP，然后用户运营商会根据就近原则路由用户数据到最近的小型DC。从而达到了上面所述的优化延迟的目的。
如下图所示，通过使用Anycast技术以后，LinkedIn小型DC访问命中率大大提高。
总结
今天我们一起研究了什么是Anycast，以及Anycast的妙用。
正如开头所说，Anycast并不是一个新技术，可谓是旧瓶装新酒。
但是通过结合BGP协议，变相提高了Anycast的使用广度和深度。
最后，针对Anycast 做如下总结：
优点：
Anycast可以零成本实现负载均衡，无视流量大小。
Anycast是天然的DDOS防御措施，体现了大事化小，小事化了的解决方法。
部署Anycast可以获得设备的高冗余性和可用性。
Anycast适用于无连接的UDP，以及有连接的TCP协议。
缺点：
Anycast严重依赖于BGP的选路原则，在整个Internet网络拓扑复杂的情况下，会导致次优路由选择。
当然，就篇幅有限，不可能把所有内容一一介绍，大家有兴趣的话，可以继续深入研究Anycast的其他妙用。谢谢大家。