前言
当他睡眼惺忪、手拿红牛、嘴刁香烟迈着沉重的步伐从某网络核心机房走出来的时候，除了看门大爷简短问候之外，也只有刚刚过去的这个黑夜才真正懂得刚刚发生了什么，在外人眼里，这个夜晚再正常不过，和往常一样，刷刷微博、看看抖音，逛逛购物网站，即便是前一晚上有某些人觉得打开购物网站的页面有点卡慢，他们也可能不会放在心上，然而正是因为这样一个不一样的网络体验，网络工程师们已经是废寝忘食，鏖战了整整一夜，来修复引发这个网络卡慢的bug，在外人眼里一觉醒来，看似波澜不惊，但有时实则是暗流涌动；
腾讯云基于遍布全球的基础设施，借助统一化的云管理平台管理着数十万的云服务器和网络设备，并在上面搭建了覆盖全球的网络，藉此为世界各地的人们提供着不间断的服务，然而看似平静的网络，告警系统在每个告警周期处理的各类网络告警就有成千上万，告警产生的时候，你可能在吃饭、可能在睡觉、也有可能坐在公园的长椅上凝望着远方的夕阳感慨着“岁月静好”；
孙悟空在护送唐僧取经路上披荆斩棘，离不开其扎实过硬的业务素质，七十二变、精斗云、火眼金睛、金刚之躯，个个拿出来都是响当当，面对突如其来、种类繁杂的网络故障，腾讯云的网络产品又是怎么攻坚克难、打造不坏之身的呢？
1 机房内的高可用网络
1.1 蜘蛛网上的蜘蛛
术业有专攻，但是太过于“专攻”，往往忽视与其相关联的其他领域，网络也是一样，如果太过着眼于网络本身就会缺乏了对业务感知的敏感性，网络就像蜘蛛网，你可以接受蜘蛛网上没有蜘蛛吗？即便你可以接受，蜘蛛自己想必也不会接受，事实上，一旦网络上面没有了实际的业务，网络优化的再好也是成本浪费，业务是承载在云服务器上的，云服务器做为网络的末端节点，他的网络稳定可靠对业务本身至关重要
1.2 如何让蜘蛛正常行走
l 首先腾讯云物理服务器都分布在T3及以上级别的机房，平均一年的宕机时间小于1.6小时，就好比一个人一年只休息少于1.6小时的时间，其余时间都在集中精力上班工作，其难度可想而知，除非发生不可抗力的灾害，否则风火水电任意一个或一套组件发生故障，都不会造成业务受损，抛开风火水电等基础设施不谈，那么从网络上来看，是如何保证服务器上联网络的可靠稳定呢？
l 网络上的“三头六臂”：三头六臂体现在两个方面，一方面，业务服务器采用双上联甚至多上联的方式接入到上联网络设备，然后通过逻辑链路捆绑协议，把物理上的多条链路捆绑成逻辑上的一条，更有甚者在多条捆绑好的逻辑链路上利用OSPF或者BGP实现ECMP，这种情况下一条链路中断，流量自动收敛到其余的链路上；另一方面，考虑到如果单台业务服务器即便是双上联到网络设备，如果网络设备仅仅是单台，那么还是存在单点故障，因此三头六臂还体现在服务器上联到多台网络设备上，规避单点风险
l 网络上的“身外身”：单台服务器的网络既然已经这么可靠，但是如果把业务放在一台虚拟机上那也是不够明智的，极端情况下如果单台服务器发生某种逻辑上的错误或者上联的两台或者多台网络设备同一时间不可用，那么此时业务上的单机部署是致命的，“鸡蛋永远不能放在一个篮子里”道理会告诉你最好把业务部署在不同的物理服务器上，当然你可能要问：腾讯云上，我作为租户，腾讯云物理服务器对于我来讲是透明的，我并不清楚的虚拟机生产后的具体物理位置，我该如何部署我的业务呢？针对这种场景，腾讯云提供了【置放群组】的技术帮助您尽可能将CVM分散的部署在不同的物理服务器上，实现业务上的“身外身”具体实现请参考：https://cloud.tencent.com/document/product/213/15486，另外腾讯云服务器如果感知到网络异常，利用HA技术可以自动将存在故障的服务器上的实例迁移到其他空闲的可用服务器上，在此过程中不会改变虚拟机子网及IP地址，但不论是【置放群组】还是HA技术，这一切都要依赖于构建在服务器之上的跨物理机、跨三层的overlay网络，腾讯云通过自研的overlay网络技术实现了同地域下同一VPC网络的自由互通，支持租户的单台服务器的虚拟机实例自由的进行跨服务器、跨机柜的迁移以及业务层面上的横向扩展，轻松的实现虚拟机的“身外身”；
当然了，整个机房内部网络都采用多级CLOS组网架构，不同层级间采用了大带宽、高冗余的设备和链路构建容错能力强、故障切换快的网络，保证机房内部的服务器可靠稳定的交互流量
2 跨AZ业务的高可用网络
2.1 置放群组适合跨机房容灾吗
如果你细细品读上面推荐给你的【置放群组】的官方文档或者加以实践，你就会知道【置放群组】是支持跨AZ的，但是腾讯云【置放群组】虽然是支持跨地域的，但是租户的云服务器最终要归属于VPC下某个子网，腾讯云子网可是不能跨AZ的，如果你暂时不十分理解AZ的概念也可以理解为子网是不能跨机房的，当你在控制台购买一台云服务器过程中，你必须选择这台CVM是哪个VPC,哪个子网，换句话讲同一子网网段内的服务器在出生前就决定了她要么在机房1,要么在机房2，即便你可以把分属于不同子网不同机房的两台服务器放在相同的【置放群组】下也不能改变这一点，所以从腾讯云子网角度分析，【置放群组】常常被用作同机房内不同CVM在底层资源上的离散才显得顺其自然，正因为如此，跨机房的容灾采用【置放群组】显得不合时宜
2.2 装鸡蛋的篮子也不要放在一个厨房里
【置放群组】借助腾讯云自研的overlay技术实现了“鸡蛋不放在同一个篮子里”保证了业务的高可靠，那么个人建议您的承载核心业务的这个“鸡蛋篮子”也不要放在同一个厨房里，腾讯云子网具有AZ属性，从侧面隐含的意义来分析，这一规则也是建议您采用多子网网络规划，不同的子网划分到不同的AZ，实现跨CVM的跨机房容灾，默认情况下，同一VPC下不同子网是互通的，所以大可不必担心网络上的连通性，关于子网使用，可以参考如下官方文档：https://cloud.tencent.com/document/product/215/30313
2.3 厨房与厨房之间不要往来频繁
我们通过跨AZ子网规划将同一业务分散在了不同的AZ，用以满足我们在“子网1所在的AZ1全部故障时，子网2所在的AZ2还能承接业务”的这一良好的期许，但是我们在业务实际部署的时候，要为以下的情况做好心理准备：厨房1 有勺子但没有筷子，厨房2 有筷子但是没有勺子，不论你在哪里吃饭，总会看到不是把厨房1的勺子拿到厨房2就是把厨房2筷子拿到厨房1的情况发生，在此期间，如果某个厨房着火了，那么剩下的另外一个厨房就陷入了缺筷短勺的窘境；
子网跨机房虽好，也要尽可能的避免同一业务跨机房后，仍然在不同AZ之间存在着相互彼此的调用关系即子网间业务的强耦合，这种情况即使业务是跨AZ的，但由于AZ间业务上的依赖性，也无法做到很好的AZ级容灾，建议您如果对业务AZ级容灾有严格的要求，AZ间的业务则最好进行解耦；
2.4 开小灶还是大锅饭
抛开筷子和勺子的话题，谈谈厨房中的篮子，腾讯云提供了各种篮筐，而我们需要做仅仅是把鸡蛋放进篮子里吗？当然不是，如果你要吃炒鸡蛋，你至少还需要一套炉灶，当然如果你要吃烤羊肉串，你肯定需要一个烤炉，你常常听人讲不要重复造轮子，没错，腾讯云站在客户的角度，不断跟踪着客户口味上的喜好，推出了一系列的老少皆宜的“炉灶”即公共服务，公共的就是具有大众普遍会使用的服务，当然也会有人喜欢在锅盖上炒鸡蛋，这种情况就不适合将“锅盖”作为一种公共服务上线，因为一方面大家普遍不会用锅盖炒鸡蛋，另一方面不太好给锅盖进行市场定位，他到底是用来盖的还是用来炒的；
公共服务作为会被业务普遍使用的服务使得业务上不必另起炉灶，重复造轮子，同时也侧面反映了公共服务有如下两个特征：①用户量大，诸如DNS/NTP等；②流量大，诸如对象存储等，正因为用户量大、流量大所以公共服务必须具备高可用、强容灾的特性，那么，腾讯云网络是如何保证公共服务组件实现高可用的呢？
2.5 打造铜墙铁壁
以DNS服务为例，如果你登录到你购买的腾讯云服务器，看看dns的配置文件-resolv.conf,一定会看到里面默认的两个dns server，业务在访问每个dns server进行域名解析时，流量会先经过腾讯云内部的负载均衡网关，依据负载均衡算法策略把请求负载到后端多个真实的dns server，实现公共DNS服务的高可用，即便如此，在这个场景下，也有两个问题呼之欲出：
1) 如果负载均衡网关异常，公共服务是否就不可用了呢？这个问题大可不必担心，负载均衡网关采用多集群部署，而且每个集群内部都采用多活的冗余架构；
2) 上文中提到，业务最好分别部署在隶属于AZ的不同子网中，而且相同业务在不同的AZ之间尽量的解耦以实现AZ级别高容灾，你可能会问：AZ1服务器访问DNS的流量会不会转发给AZ2的负载均衡网关或者即便时转发给了AZ1本AZ内的负载均衡网关，负载均衡又会不会将请求跨AZ转发到AZ2的真实dns server呢？，这种情况会不会造成AZ2故障时，AZ1的业务也受损呢？如果你能有这样的疑问，至少说明你已认真阅读了以上的全部内容并开始了自己对于AZ级高容灾的思考
针对上面的两个疑问，第一，访问公共服务的流量会就近转发到本AZ的负载均衡集群，第二本AZ的负载均衡集群依据策略会也会首选本AZ的真实DNS server就近低时延转发
综上所述，腾讯云公共服务组件大都采用“集群内多活 多集群部署 公共业务服务器跨AZ部署 就近转发”的理念保证客户业务的高可用，为客户建设AZ级的高容灾的“厨房”添砖加瓦，拾柴添薪，打造铜墙铁壁
2.6 既然要追求刺激那就要贯彻到底
诸如DNS这样的公共服务为业务的稳定运行提供了最基础的保障，除此之外，腾讯云很多的SAAS/PAAS服务产品他们本身会作为腾讯云的特殊使用者为租户提供服务，即提供产品服务所用到的计算资源本身就属于某个特殊的VPC，他们既是腾讯云的使用者，又是腾讯云的服务者，前文也提到了，子网是和AZ或者机房绑定的，例如，你购买SCF跟购买云服务器一样是需要指定该SCF服务是属于哪VPC下哪个子网，购买SCF之后，实际上就决定了这个函数服务的AZ或机房属性了，关于函数服务的详细使用，请参考：https://cloud.tencent.com/document/product/583；
但是还有一种情况，虽然不见得提供服务的资源在某个VPC子网内，但是你购买时也需要指定服务资源所属的AZ，诸如关系数据库服务产品等等
或许你逛了一圈腾讯云官网，也很难找出一款你在购买时不用指定所属AZ的云产品，因为不论你购买什么，买的资源肯定是要具体落在某个AZ的，，既然你的业务已经分了子网、分了机房，与此同时你的业务也要和购买的云产品发生业务往来，那么这种情况下，为了实现跨AZ级高可用，那么还是建议你要买就买两份，每个AZ各一份，让每个AZ的业务在本AZ进行闭环，尽可能的不发生跨AZ关联，既然要追求刺激何不贯彻到底呢
从以上的说法来看，好像腾讯云的产品是以AZ为最小单位售卖的，如果你这么想，我一时半会儿也找不出反驳这个说法的理由，然而实则不然，腾讯云产品既有地域级例如CLB，又有AZ级，只是这里建议你在购买AZ级产品时，业务部署上线前需要仔细斟酌跨AZ高可用设计的合理性
这样的方式势必会带来成本的增加，随之而来也会带来你的抱怨，“站着说话不腰疼/你掏钱吗！”，没错，接下来介绍的跨地域的高可用网络恐怕会更加深你的抱怨
3 跨地域业务的高可用网络
3.1 你在北京有两套房，豪华别墅都在三环
你在北京的北三环买了一套豪华别墅，不过你担心可能某一天北三环太堵车回不去家，只能“在二环的里面想着她，而她只能在二环的外面为你唱花香自来”，为了避免堵车带来的困扰，你又在南三环买了一套豪华别墅，这个就是人们口口相传的同城灾备；突然有一天当你从外地出差回来，因为疫情的原因连北京城也进不去了，这个时候你又决定在上海买一套别墅，在紧急特殊的情况下，你还可以享受下异地他乡的春风十里，这个就是异地容灾，北京的两套房加上上海的一套，总体上就叫做两地三中心；
另外如果你一直住在北三环的房子里，仅仅堵车的时候才会搬到南三环去住，在大部分的时间里面南三环的房子一直闲置，这个叫做同城单活，如果你周一、三、五在南三环、周二、四、六在北三环，利用率得到提升，这个叫同城双活，同样两地三中心中的异地，也存在异地多活的情况
腾讯云上的地域好比北京城，地域内部不同地理位置的AZ好比北三环、南三环的豪华别墅，根据之前的内容你了解到了AZ内部不同机房的网络规划基本的原则用以实现同城的灾备或者多活，接下来谈下腾讯云网络在异地灾备场景下的一些基本原则
3.2 云联网不是万能的
同一VPC下不同子网不论你怎么分配地址，由于存在冲突检测的机制，永远不会出现同VPC不同子网具有相同网络地址的情况，但是当你在另外一个地域部署容灾业务时，意味着你要在另外一个地域开疆拓土，创建新的网络空间即VPC，因为VPC虽然同地域是可以跨AZ的，但是VPC不能跨地域，新的VPC与原有的VPC是完全隔离的，也就意味着不同的VPC虽然是同一账户下的，他们的网络地址规划也是相互独立，正因为这样的独立性，可能会出现核心业务地域VPC和异地灾备地域VPC中存在相同或者包含被包含的网络地址，一旦核心业务地域VPC和灾备VPC二者数据交互，就会发生无法联通的情况，因为地址相同的两个VPC相互通信只会从本地VPC转发，不会把访问本VPC地址的流量转发给其他VPC，其实不管跨不跨地域，也不管跨不跨账户，如果是同一业务体系下的不同VPC，则强烈建议进行统一的地址规划，保证不同VPC网络地址的唯一性，如图，同一个业务体系下，由于在同一个互通的网络体系下， 存在两个翠花儿，可惜造化弄人，让你仅仅可以得到离你最近的那一个
前文提到不同VPC之间网络完全隔离，那么如何把核心VPC的业务复制一份给灾备VPC以实现异地灾备呢？前提肯定是要把不同VPC网络打通，腾讯云提供了云联网产品满足不同VPC之间同地域或者跨地域打通，详细请参考官网文档：https://cloud.tencent.com/document/product/877/38801，但是即便如此，也无法解决地址冲突带来通信阻断的问题
3.3 避免跨地域业务交叉
如果是异地灾备业务，从一开始你就决定把他放在那里，除了定期的一些容灾演练和一些数据同步外，正常情况下也不会激活她，一般情况下下也不会发生跨地域的频繁业务交互，但是如果你的部署模式是多活，那么从业务层面来讲，跨地域资源共享、业务交互也时有发生，这种情况下，最好还是遵循同地域不同AZ的网络设计原则，尽量将业务逻辑在本地闭环，避免交叉，跨地域交叉相比于同地域交叉带来的另外一个痛点就是延时的问题，对于延时敏感的业务跨地域调用也更不是一个好的选择，当然本文是介绍一些基本原则，如果业务上不可避免的有跨地域的需求，那么基于腾讯云自建的低延时、高带宽的全球一体化full-mesh内网为底座的云联网产品提供了白金、金、银等不同的服务等级来为跨地域通信提供保障：https://cloud.tencent.com/document/product/877/18761。当然云联网作为网络基础服务网关，采用的网络架构仍然是上文提到的“单集群多活 多集群部署 本地转发”，进而保证了云联网网关的稳定，不以赘述
4 腾讯云网络产品的高可用
前面介绍了腾讯云网络在不同场景下的一些基本性的原则，既然是原则那么就肯定存在具体落地过程中各种各样的原因导致的不尽如人意的地方，另外没有哪项原则是放之四海而皆准的，任何事物随着空间和时间的变化很难是一成不变的，在此仅仅提供的是个人思考的方向
4.1 公网CLB高可用
当你的业务部署到不同AZ的子网后并准备对外提供服务时，按照之前AZ内部闭环的原则，你也许同样希望访问请求既可以从AZ1进来，又可以从AZ2进来，当AZ1中断，AZ2不受影响，之前AZ1进来的请求可以尽快收敛到AZ2;
腾讯云上，租户业务对外提供服务最常用的产品，也是1对多访问场景中最经典的应用，非公网CLB莫属，针对客户上述高可用的诉求，早在几年前就提出了过可用区高可用的解决方案，详细请参考: https://cloud.tencent.com/document/product/214/8093，例如你购买多可用区公网CLB时可以选择主AZ和备份AZ，主AZ和备份AZ发布同样的公网IP，但是主AZ发布的公网IP携带较高的优先级，从而一般情况下将全量的流量引入到主AZ，当主AZ故障时，则通过路由的自动学习，将流量牵引到备份AZ集群，实现多可用的高可用，不过要注意的是并非所有的地域都支持CLB的多可用区高可用，在你打算购买前一定要找服务经理确认清楚;
遗憾的是，单个多可用区CLB实例 对应的公网地址仅仅只有一个，当对应的公网网段在互联网上出现异常时，可能大部分的外部请求在进入腾讯云之前已经被阻断了，这个时候是否考虑创建多个CLB实例，这样对外提供服务的公网IP就会有多个，具备了一定程度上的高可用，但是回头头来再想，如果不同的公网地址对应的底层集群都部署在一个AZ可用区，当这个AZ不可用时，即便你有再多的公网IP因为你都放在了一个厨房里的一个篮子里，那么也是徒劳的，这个时候你可能会想到，我是不是可以在不同的可用区申请不同的CLB实例来保证公网IP不同的情况下所在的AZ也不同呢？没错， CLB产品以客户需求为驱动，支持基于AZ创建公网CLB实例，然后可以通过DNS解析到不同IP，再从不同IP所属的相应AZ进去访问，在某个AZ故障的时候，通过人工或者自动探测感知并切换，将全量的流量收敛到正常AZ的CLB实例上（CLB是region级服务，具体购买时能否支持基于AZ购买，请咨询官网客户经理）
4.1.1 公网CLB 1 1=2？
现实不仅是残酷的而且是奇怪的，当你信心满满的按照上面的建议部署好业务对外提供服务时，你可能有一天发现AZ1的公网CLB实例不可用了，好在你认为还可以把业务切换到AZ2 CLB实例上，所以你此时还是选择继续喝完手里的茶再说，然后你发现AZ2的CLB实例虽然时正常的，有人却告诉你AZ2 VPC子网中的业务不明原因的同时发生异常了，也就是说两个AZ没有全宕机，但是每个AZ各自坏了一部分核心组件……两个AZ加起来算是等于了0，没有实现1 1=2甚至大于2的超预期；
应对这种场景，常常的做法是本AZ的CLB实例除了关联绑定本AZ内VPC子网下的云服务器之外，同时也要关联其他AZ的VPC子网下的云服务器，但是之前一直强调避免交叉访问，这是不是业务上的交叉呢？上文一直说的交叉指的是相同业务跨AZ或跨地域间调用的彼此依赖关系，一旦这种彼此依赖关系断裂则会影响调用链条两端的子业务，因此CLB跨AZ交叉绑定与上文一直说的交叉是不同的；
4.2 NATGW的高可用
腾讯云提供VPC子网中云服务器主动访问外网的产品常见的有EIP和NATGW，当你的VPC子网中大部分云主机需要主动访问公网时，NATGW网关是不二之选，一方面成本可控，另一方面满足隐藏内网IP的安全需求，像其他的腾讯云产品一样，你购买NAT网关时也可以自由的选择该NAT实例具体落地的AZ是什么，按照流量在本AZ尽可能收敛的原则，你可能要购买两个NAT实例，一个在AZ1叫做AZ1_NAT01，另一个在AZ2叫做AZ2_NAT01，AZ1的子网1通过关联路由表1通过AZ1_NAT01 访问公网，AZ2的子网2通过关联路由表2通过AZ2_NAT01 访问公网，这样看起来是perfect的。
忽然在某一天你被告知AZ1_NAT01上面绑定的SNAT公网地址在运营商侧发生了异常，子网1中大量主动访问公网的云服务器丢失了公网连接，这个时候你瞬间感觉除了静候运营商的消息，也别无他发，其实不然，腾讯云在国内有着强大的公网流量调度能力，面对较大的本地公网出口故障，可以迅速的完成公网调度，选择最合适的正常出口转发流量。
4.2.1 没有什么不是一顿火锅不能解决的
但是在根因不明确或者粒度较小的公网故障，如果你作为租户，是否还有其他双管齐下的手段来主动保护自身的资产呢？没有什么不是一顿火锅不能解决的，如果有那就两顿呗，VPC中的子网路由表提供了一项高级功能，她支持绑定多个nat实例，我们可以在子网路由表中分别绑定两个AZ的nat实例，正常情况下你可以选择使用其中一个而关闭另外一个，也可以选择两个都开启，但注意的是这个高级功能受白名单控制，需要联系客户经理技术评估后开通，另外还要指出的是每个VPC中创建nat实例的数量都是有限制的，这个限制也称为VPC资源配额，详细了解可参见：https://cloud.tencent.com/document/product/552/12955，其实除了NAT网关有配额限制，绝大部分产品都会有这样的限制
就算是你不用这样的高级功能，如果业务较重要，你也可以事先创建冗余的NATGW绑定好另外的出口IP留作备用，也是一种谨慎的选择
4.3 VPNGW的高可用
如果你能读到现在，那么你也肯定懂得，一旦你使用了VPN产品，你一定是做好了“不是很稳定”的打算，倒不是是腾讯云的VPNGW架构设计和底座的不稳定，主要是因为VPN产品基于公网建立IPSEC VPN隧道，干扰这条隧道的健康的因素常常来自公网，不过反过来想，正是因为有这样的不稳定，我们是不是才更应该考虑下如何降低公网异常带来的影响呢？
首先，你应该关注下VPN通道界面下的监控视图，来查看通道两端之间的公网时延和丢包率，并尝试找出规律，如果你有幸找到了网络质量较差的时间段，那么核心业务使用VPN通道的时间段应尽量避开这个时间区间，如果你觉得一个高可用的网络不应该这样“投机取巧”，那么业务上的分流是一个不错的选择：
1) 腾讯云一个VPNGW 以点到多点的方式与对端的两个公网IP建立两条不同的通道，腾讯云AZ1 子网1的业务访问IDC引入到通道1，腾讯云AZ2 子网2的业务访问IDC引入到通道2
2) 腾讯云2个VPNGW以多点到多点的方式与对端一个或两个公网IP建立两条不同的通道，腾讯云AZ1 子网1的业务访问IDC引入到通道1，腾讯云AZ2 子网2的业务访问IDC引入到通道2
除了VPN分流，腾讯云也在孵化“VPN通道主 VPN通道备”的方案产品，正常情况下，将流量全量引入主，当检测到主通道异常时，再切换到VPN备，同时也提出了“VPN通道 专线”的方案，不过这个场景下，需要变化下实体对象，应该说专线加VPN，而不是VPN加专线，因为有专线的条件下，备份链路自然就是VPN了，到底是否成功孵化最好还是实时关注下VPN产品的最新动态：https://cloud.tencent.com/document/product/554/18983。
那么，为什么这里不提VPN的ECMP等价负载均衡呢？一方面在同一台VPNGW在技术上无法ECMP，另一方面，在不同的VPNGW上进行负载分担，即便是在传统的网络环境下，也常常受限于防火墙上的安全管控机制，也常常因为路径的不一致性带来运维的复杂程度，更何况是在云网络的环境中，因此VPN产品的ECMP个人不是非常的推荐，不过人们常常对别人的推荐觉得无所谓
在不断的网络实践过程中，专线 VPN的方案也逐步受人青睐，接下来我们讨论下专线 VPN的场景，来看看专线是如何实现高可用的？
4.4 腾讯云专线的高可用1）
在资金充裕的情况下，你买了一条专线接入到腾讯云访问VPC中的子网1和子网2，同时为了防止专线中断，聪明的你，又利用IDC的存量防火墙设备，构建了一条去往腾讯云VPC的IPSEC VPN，作为IDC的管理员，你可以自由的配置路由策略，正常情况下，把流量通过专线运送到腾讯云，专线异常的时候，你再通过优先级切换的方式，把流量导入到VPN隧道中去；
但是你有没有考虑过，站在腾讯云的角度，你又该如何在控制台操作然后去选择去往你的IDC路径呢？正常来讲，你可能需要VPC子网关联的路由表里面配置两条规则，一条规则下一跳指向VPNGW，一条规则下一跳指向专线网关，通过启用规则或者关闭来决定选择VPN还是选择专线，这种情况下，路径的选择权 是属于VPC路由表的，这种实现也是可行的，但是开启或关闭都是人来操作的，缺乏一定的灵活性，故障切换时间因为加入了人的因素而增加了不确定性；
面对上述困局，腾讯云网络把自动学习、动态感知租户线下IDC路由的重任交给了云联网，云联网通过同时绑定专线和云联网的方式，将专线和VPN在逻辑上合二为一，用户只需要在VPC子网路由表中设置好访问IDC走云联网即可，流量到了云联网之后，便可以依据动态学或者手工指定的策略优选专线，专线检测到异常之后再有由云联网自己做出决策选择走VPN，不再需要人工去操作路由表了
4.5 腾讯云专线的高可用2）
如果你的业务很重要，重要到连备份的链路也要很稳定，甚至连备份的备份的也很高的要求……那么你可以考虑下多条专线接入腾讯云的解决方案，在腾讯云上通过专线访问VPC时，流量必须先经过专线通道的包装，然后才能进入到腾讯云的VPC，一条专线可以创建多条通道，每条通道关联一个VPC，如果有多条不同物理专线的专线通道接入到相同的VPC，那么这个VPC访问专线对端的IDC时，就有多条路径可供选择，默认情况下是负载均衡的，但是也可以按需调整成主备的方式；
正是因为专线通道与VPC一一捆绑，一条物理上的多条专线通道可以自由的选择接入到不同的VPC，但是如果VPC过多，同样VPC关联的专线通道也较多，业务随着时间在改变，时间随着业务在流转，VPC和专线通道越来越多的情况会更加严重，给网络规划及运维带来严重的问题隐患
如果在复杂的网络之上我们去讨论高可用，这常常会是适得其反，反而会加剧网络的复杂度，让你深陷泥潭，网络的高可用的前提是网络一定是简洁的、清晰化的，这种情况下，你可以腾讯云云联网产品来简化你的混合云部署，你可以通过创建云联网类型的专线网关，一个专线网关相当于一个客户IDC，专线通道不再关联VPC，而是直接关联专线网关，然后再把“客户IDC”即云联网类型专线网关绑定到云联网上，如果你想让VPC-1VPC-2VPC-3与IDC1互通，不用再像从前一样，建3条专线通道分别关联VPC1VPC2VPC3,只需建立一条专线通道关联云联网专线网关，再把其他的3个VPC也同时关联云联网即可，将过去组网结构从full-mesh简化成了星型结构，关于云联网详细的帮助文档，请参考：https://cloud.tencent.com/document/product/877。
5 武功再高也怕菜刀
武功再高的人，如果丧失了视觉和听觉，就丧失了预知风险的能力，一套完整的高可用的网络系统如果看不见，听不到那是及其危险的，腾讯云网络产品提供了丰富的监控及告警策略，对于影响关键业务的诸如出入带宽、丢包率、时延等监控和告警 定期的巡检和实时的订阅肯定是必不可少的，当然如果你觉得不好用，选来选去感觉都不适合自己，想找一个颜值更高的监控或者听起来跟牛的告警机制，那么腾讯云也提供了丰富的API供你获取基础数据来支撑你自定义的千里眼、顺风耳
6 写在最后
本文主要讨论了在你使用腾讯云网络产品构建支撑业务过程中的一些个人的方法和思路，既然是思路那就会涉及一些个人对网络理解的原则，所以文中的一些观点难免会以偏概全，有失偏颇，如果你通读全文，不论是将业务分散部署在不同的AZ不同的子网，还是将使用的公共服务器在本AZ闭环避免交叉，亦或是最后提到的专线、VPN的备份，其实总结来看，无一例外都是组件冗余和故障隔离，但是有时选择多了也不是一件好事，例如如果你的业务较多，冗余要求很高，如果你将业务部署到了同地域下5个AZ可用区，5个可用区实现很难完全的隔离闭环，这个时候你可能开始认为完全的隔离和闭环有必要吗？收益究竟有多大呢？……在众多的冗余选择中将各个网络模块、组件协调统一起来，是你我应该持续思索的问题……
