腾讯云虚拟网络架构揭秘

本次内容根据2017年11月5日腾讯云网络技术沙龙北京站腾讯云网络产品中心专家工程师王营的演讲内容整理而来，主要分享腾讯云虚拟网络背后的技术架构，以及如何来实现虚拟网络技术架构中的高可用、高性能、可扩展性等。

我是腾讯云网络产品中心的工程师我叫王营。今天主要介绍腾讯云整个技术架构，将从虚拟网络数据平面、控制平面，包括VPC网络监控等各方面，来给大家做一个全面的介绍，让大家对腾讯云网络整体的技术架构有一定了解。

首先我们先从宏观方面来看一看，腾讯云网络的基本介绍，包括网络产品，以及我们在实现云计算这种技术架构面临的一些问题。我们主要介绍两种网络类型，一个是基础网络，还有一个VPC网络，这也是腾讯云提供的两种主要的网络类型。

基础网络，这个网络是所有用户共享的资源池。这个资源池里面所有的用户都可以在这个资源池里面创建资源。基础网络中的IP是由腾讯云统一分配管理的。用户不需要做特殊的配置就可以来使用。但是在这个资源池里面我们会做一些安全隔离策略。保证租户A不能去访问租户B的资源。

第二种网络类型就是VPC网络。它是在我们腾讯云网络上面，划分出来了一块逻辑隔离的空间。每一个VPC是完全独立隔离开的。用户可以在VPC网络里面自定义网段和IP地址，还有各种路由策略。从下面的图里面，我们可以看出，其实使用VPC网络，有更丰富的功能，也更加灵活。所以我们的产品开发，未来包括目前也是围绕着VPC网络来做。

所以可以知道，腾讯云目前已经提供了非常多、非常丰富的网络产品，包括像安全组、ACL，还有各种各样的网关。用户可以基于单个产品或者多个产品组合，根据需求灵活定制私有网络，可以通过我们EIP和公网负载均衡发布或者访问internet上的这些服务。VPC网络它并不是说一个完全的孤岛，它可以通过我们的专线、V**，或者对等连接，可以和它的IDC或者不同地域VPC网络打通。

另外我们也提供了全方位的安全防护。包括像防DDOS攻击、WAF等各种公网的安全防护产品。在VPC内，我们提供了安全组和网络ACL来提供实例级别和子网级别的安全防护。

云计算网络，需要提供各种各样的网络功能和产品。也要面对海量的用户需求。所以在云计算网络里面，有很多问题需要解决，但是传统网络中网络配置，可能是一次性配置好，后面就不会有更多的变化。但是在云计算网络里面，要考虑到VPC、多租户和各种混合云的需求，这在传统网络里面是没有办法满足的。

另外云上的资源，它的创建和释放会非常频繁。如果宿主机有故障或者需要维护，需要迁移宿主机上的虚拟机。我们要保证这种迁移，对用户是无感的、透明的，不能影响客户的业务。

另外因为要面对海量的用户和需求。我们如何来避免，把云计算变成人计算？因为如果所有需求你都是通过人来支持，或者来解决的话，这个是没有办法做到的。另外我们还要考虑像安全，SLA、性能等等各种各样的需求，保证我们服务质量稳定和高质量。

最后一个问题是选择开源还是自主研发来实现云计算网络。腾讯云是2010年开始做云计算的。在当时来看，一方面是说我们本身，腾讯云内部有很多云计算相关的技术都有积累，也都有检验。另外可能开源组件也不是太成熟。所以我们选择的是自主研发。把我们自己内部的一些技术积累，再结合开源的技术，最终形成了我们目前腾讯云网络整体技术架构。

但是我们这个基础架构，也不是说一开始就达到现在的这种状态，而是中间有了不同阶段的演进。中间也走了一些弯路。首先第一个阶段，我们叫实体网络。这种网络类型里面，我们可以看到，虚拟机它所在的网络和物理网络是在同一个网络层面上面，虚拟机它IP段，它的网关也是在接入交换机这一层。这个交换机下面的网段，都是提前需要规划好。每一个接入交换机其实就是单独的二层网络。

这种模式下，单个虚拟机它是没有办法做跨交换机迁移的。因为跨交换机迁移之后，在网络里面，它没办法找到自己的网关，没法做路由。这种好处就是静态、简单。但这种模式显然也不是最优的。

第二个阶段是VLAN网络。我们把网关从接入交换机移到了内网核心交换机。相当于把多个接入交换机变成一个大的二层网络。虚拟机可以在二层网络里面去做迁移，但是需要在每个交换机下面去做网段规划。并且每个交换机，都得有整个二层网络转发表项。这样对交换机转发表项需要的数量是比较多的。而且这个转发表项的生成是依靠广播报文来生成的，所以这样会造成很多广播报文的泛洪。

我们后面对这个架构做了继续的优化。到了我们现在目前整体架构----VPC网络。在虚拟网络和物理网络之间，通过Overlay技术，做了一层隧道的封装。这样把虚拟网络和物理网络完全隔离开。这样对物理网络依赖小，这种网络部署对物理网络的要求比较少，物理网络部署和实体网络类型的部署一致。因为它中间做了隔离，所以用户VPC网络中的网段可以完全根据他自己的需要定制，不是说像实体网络里面，需要提前规划好，用户没法去编辑。

Overlay网络下，不可能所有的网络通信都在Overlay网络内部，肯定要涉及到和物理网络包括公网通信。所以涉及到各种路由转发，还有各种网关，这种路由我们是在宿主机上面实现的，实现分布式路由，可以减少到对中心节点流量压力。并不是所有的流量都不经过中心节点。

接下来我们说一下目前我们数据平面整体架构。首先最上面是外网统一接入。实现外网统一接入的是TGW集群，这个网关集群主要实现了四/七层的负载均衡和EIP等功能。像EIP的话它肯定和公网进行通信，涉及到和运营商的接入。目前我们主要提供两种接入方式：BGP和静态接入。外网流量接入之后，TGW需要转发到对应的虚拟机，或者第二层虚拟网关。所以在TGW集群也有隧道管理，还有路由管理，当然还有DDOS攻击防护。但并不是说所有的这种攻击或者防护，或者安全策略，都是在TGW集群做的，我们是有专门的防护集群。

第二层VPC虚拟网关。我们可以看到有很多虚拟网关来提供像V**、专线、对等连接、共享EIP等功能。每一种类型的网关都是单独部署，一个网关故障不会影响另一个网关，这样故障域会小一些。这里像NAT网关、VP网关、专线网关这种，可能通过名字就能知道是做什么的。这里面有一个PVGW网关，在基础网络虚机之间通信或者基础网络虚机和物理网络通信的时候会用到。

这里面对等连接网关，对等连接是把两个VPC内网直接打通。但是这里面的对等连接网关，只在建立跨地域对等时才会用到。比如说我们腾讯云上面有不同的region，只有不同region之间的VPC互通时，才会走到这个网关。如果是同region VPC互通，我们通过母机之间的隧道就可以直接打通，不需要经过中心节点的网关。

再下一层主要在宿主机上面。我们通过自己开发VPC KO组件，加上virtual switch来完成宿主机上虚拟网络流量的转发。出入虚拟机的所有流量都需要VPC KO模块封装或者拆解隧道来做转发。当然还有一些网络上的功能，比如说像安全组、ACL，还有QoS等，这些功能也是在宿主机上来完成的。

像下面的VPC Link，其实就是刚才说的同地域VPC互通，其实就是通过这个模块来完成的。像Classic Link，其实就是基础网络的虚拟机和VPC的虚拟打通。但是这种打通它只会有一个基础网络虚机和VPC打通。并不是说你打通了之后，你所有的基础网络虚拟机，都和VPC互通，不是这样的。

再下一层可能涉及到物理网络，物理网络通常情况下是有两块网卡，接入到我们整个IDC业务网络里面。因为是要对外提供产品，所以我们要保证网络的稳定性。这个其实也就是我们在软件工程里面，经常需要讨论的一个问题，我们怎么来做到高可用，保证你的服务是7×24小时在线的。

这里面我们通过三个层次来介绍，首先是公网接入接出。第二个虚拟网关集群。第三个是宿主机。

公网接入这一块，我们TGW集群是通过ECMP来实现多主，可以做到平行扩展。当它达到我们设置的容量阈值时，我们会增加节点来提升集群的服务能力。我们现在的BGP线路接入了很多家运营商，目前是20+ BGP线路。当某个地域的运营商故障时，我们内部有专门的系统来做这种跨地域切换。比如说如果北京电信有故障之后，我们可以通过其他地域来接入，目前这个接入故障切换时间是在分钟级，我们也在不断优化，目标是做到秒级切换。

另外在接入单个运营商时，我们考虑到运营商IDC机房也有可能会有故障，所以一般情况下会至少接入运营商的两个IDC机房。虚拟网关集群，其实我们刚才有很多虚拟网关，所以不同的虚拟网关可能高可用策略是不一样的。主要分成两种类型，一种是有状态，一种是无状态。有状态的一般情况下，可能大家通用的做法通过主备的方式。我们之前也是通过主备的方式，目前我们已经在把这种主备的方式，向多主的方式迁移。但是我们集群内部会划分不同的集群池，每个集群内部也是多主的。无状态集群的实现和TGW是一样的。通过ECMP来实现多主。这个也是业内比较通用的做法。

我们知道网关集群同时服务多个用户，如果某个用户使用资源量比较大，可能会影响其他用户。所以我们通过服务分级的方式，把这种集群资源池划分，这样把一些可能规模比较大的用户移到单独的集群上面。这样当大用户的业务流量突增时，不会影响其他用户。当然我们也会有过载保护，并不是说把它移到单个集群，只是固定的资源。我们会有监控阈值，当达到阈值之后我们会提前扩容。但是在扩容之前我们会有，集群实现有过载保护机制，避免在扩容期间，导致影响其用户，或者说这个集群崩溃。另外我们现在故障切换，不管是主备还是多主，都可以做到秒级。当然无状态就不涉及到session同步问题。有状态集群，我们也能够保证已有连接session不会中断的。

第三层宿主机这一层。宿主机这边主要一个是涉及到物理网卡，还有一个迁移。迁移我们现在能做到热迁移的时候，虚拟机已有的连接是不会中断，这样它的业务完全无感知。物理网卡这一块是双网卡做bonding、双上联。这样单个交换机或者网卡故障，它的网络通信依然不会受到影响。

除了高可用，高性能也是需要考虑的关键点。在这里面我们使用了很多技术来提升我们虚拟机和网关极限性能。主要通过Overlay GRO/GSO，包括像智能网卡这种硬件设备，包括DBDK，还有这种高带宽的网卡。以及像通过RDMA来进行内存的拷贝。这些高性能策略，其实后面我们同事会做更详细介绍。这里我给大家展示一个数字。我们现在单CVM可以达到450万的PPS，单网关节点PPS可以达到2100万。当然带宽可能是可以达到目前这些网卡极限带宽。

很多厂商都在做云，大家功能也在趋同。但是网络产品功能上，我们也有一些独家功能。主要是广播/组播、ECMP路由、专线NAT和网关IP。广播/组播这个是在证券/银行等金融客户中使用的比较多，这些金融用户，他们的业务系统在传统IDC网络里面，以前可能依赖于组播方式来实现，所以它希望在迁移的时候，也能够可能平滑的迁移，所以我们开发了广播/组播的功能。ECMP路由是我们可以支持同一个目的网段的下一跳是多个云主机。这样类似于模拟物理网络，可以通过路由实现流量负载均衡。专线NAT这个是解决专线混合云中IP冲突的问题。我们知道用户他的IDC网络可能在建设的时候，或者他在云上规划VPC网段的时候可能没有规划好，或者后面又增加了机房接入，比较容易出现IP断冲突的问题。所以通过专线NAT的功能，即使两边的网段有重叠，也是可以通过专线打通。

最后一个是网关IP粒度流控。我们以NAT网关来举例子，NAT网关它其实是一个共享EIP的功能，多个虚拟机可以使用同样的EIP出去，这样用户比如说他NAT网关容量达到它的限制的时候，它想知道是哪一个虚拟机把这个流量打的比较多的话，可以通过我们这个功能，通过监控视图可以看到。另外它还可以通过这个功能，限制单个虚拟机可以发送带宽阈值。避免它的流量太大，影响了其他虚拟机的使用。

以上就是我们数据平面的介绍。接下来我们看一看控制平面。数据平面是数据流的转发，相应的转发路由和网关配置信息，需要有配套的控制平面来完成。我们从用户请求接入一直到我们宿主机上的配置实现来介绍吧。

腾讯云上面控制台，用户通过我们控制台去配置，或者通过我们云API来发送请求的时候，进到我们内部，首先到我们叫云API框架，这个云API框架分成两层，一层主要是攻击防护和签名认证。下面一层是不同网络资源云API模块。攻击防护主要是防止用户，当然也不一定是用户，也有可能是网络上来的恶意的攻击或者说频繁的，对多个API频繁的发起请求。当然还有一些像sql注入的防护。签名认证，对它签名做校验，确保是合法的，是有效的请求。

当拿到这些请求之后，如果通过安全防护做了校验通过之后，根据它URL里面请求真正网络资源，我们会调度到不同的云云API模块里面。云API模块，它做的主要事情，是把云API的参数转化成内部网关接口参数。当然也会加一些，我们内部一些特殊的参数，标识它是来自于云API。这些请求具体操作是由我们API网关来做的，API网关它会调用我们内部，各个不同的系统，包括像VPC的，像DFW或者像TGW这些服务。它请求的资源能不能操作，能不能访问，是通过CAM来做验证的。API网关会把请求，用户的信息，包括它请求资源信息，去做一个校验，如果它没有权限，这个请求就会拒绝。

另外API网关除了访问我们底层服务集群之外，我们还有一个流程系统。把一些耗时比较长的操作放在流程系统里面。然后底下就是各种提供VPC相关功能的Server，像VPC，像TGW，像V**等等。这些集群基本上都是有Server和Agent两部分来组成，Server的压力我们通过读写分离，还有就是在Server和Agent之间增加缓存，来保证我们这些Server集群它能够支持大规模的物理机和资源。目前我们控制平面整体的架构，单集群可以支持百万级的VPC。单机群可以支持数十万的宿主机。另外整体架构包括一些关键的技术实现点，在我们多个产品线都有实际检验。前面我也说了，其实我们云计算很多的技术输出，都是从公司以前技术积累迁移过来的。

接下来我们来看一看VPC网络监控。其实不管是控制平面还是数据平面，软件工程里面永远不可能没有BAG，永远不可能没有故障。我们有一整套完善的监控，不管是说这种人为的误操作，或者像系统的缺陷导致的问题，都能够及时发现。首先我们有一个VPC对账系统，可以时时把VPC网络所有的配置信息做对帐，和数据库包括我们缓存都会做对帐。如果发现有问题的话，可以自动的完成配置修复。我们现在对帐系统，目前正在开发的一个，也是做了服务分级，就是把一些对延时比较敏感，对SLA要求比较高。或者是规模比较大的用户，我们会把和普通用户的对帐分开。这样保证用更多的资源来实现重要客户，或者敏感度比较高的用户，实现秒级的对帐。目前的对帐系统对账一次的时间是在分钟级。

第二块就是VPC Monitor，这一块主要监控各个节点的配置信息。即做配置对帐，也做网络流量的监控。包括CVM和各个网关的。包括像刚才我们介绍的，IP粒度的流量监控，都是通过它来采集数据、上报数据，然后再有专门的分析集群来做分析。

第三块网络流量可视化。这一块也是我们目前正在做，也是未来重点去投入的一个方向。因为云上面的网络结构，当它规模比较大的话，比较复杂。用户他期望我所有的流量，包括像不同的IP流，可能会去做一些归类的分析这些。它能够很直观的看到它现在网络运行状况是什么样的。目前主要是分为四块，一个是VPC流日志，VPC流日志，是用户他可以看到，经过他虚拟机的所有IP流，IP流量镜像就是把流量可以镜像给它。公网流量分析，就是对用户公网流量包括他的地域、来源做各种各样的分析，做汇总展示给他。VPC流量精细化展示，我们未来的目标是要做到这种 IP粒度的监控，包括它网络，包括两个虚拟机之间，或者虚拟机和网关之间的延迟，还有实时流量，都能展示给用户。

最后一个就是全链路监控。把VPC网络和物理网络，所有的这种网络状态都监控起来，一方面是说可以给我们内部做快速的网络定位发现和修复，另外我们也可以，未来可能包装，在我们的控制台上面可以直接用。这样的话减少用户故障处理的时间。除了我们目前的工作之外，我们也在不断的关注社区，不断的关注竞品，不断的关注整个网络的发展前沿方向。我们目标是做到更安全，更大带宽和性能，更加卓越的服务质量，能够更好服务我们客户。当然不是说只是他现在的这种需求，可能就是未来的需求，我们也能够满足。能够保证我们技术是和这种技术的前沿和技术的发展趋势，能够保持一致。

提问：顶层用的是KVM还是Xen？

王营：我们现在是KVM。但是我们是做了很多开发，也会把一些patch回馈给社区。

提问：还有我刚刚听到，session迁移？

王营：就是在迁移过程中，我们相当于，不是直接把，比如说把它的数据拷贝过去之后，直接把流量切换过去。我们会在它的会话同步完成之后，才做真正的流量切换。

提问：是不是放到agent里面？

王营：这个同步的话，不是通过Agent来做的，是我们有专门的组件来完成。因为这些Session我们也是有自己的定制和开发，可能跟Linux内核的那个还不太一样。

提问2：我想问问网关的地方。你讲到里面很多网关。里面的逻辑是什么关系呢？是一个什么逻辑关系？

王营：网关之间吗？

提问2：就这些网关，你都划到一块了，我其实分不清它们之间怎么交互的？

王营：这些网关它们之间，功能是独立的，并不是之间有交互。

提问2：它们是完全独立的？

王营：对，比如说你像V**网关，可能它就不会用到，这个流量就不会走到专线网关。

提问2：但是它们都和VPC通信？

王营：对，这个流量它比如说有很多虚拟网关，它这个流量是走到哪一个网关，这个其实是靠宿主机上面，每个VPC它都有单独的路由表，这个路由表不只是指的我们控制台能看到的路由表，内部可能还有其他路由表。这个流量发送出来之后，它往哪一个地方去转发，是有宿主机上面路由来控制的，它并不是说这网关之间都需要去做交互，可能不需要的。

比如我通过VPC出去可能根本不需要走到专线。可能如果对等连接这边，也不会走到VPC专线。

提问2：但一般情况来说，你想出去的话，都需要经过VPC网关？

王营：我们现在公网流量也是不需要经过VPC网关的。因为那个TGW集群我刚才介绍的时候说过了，TGW集群也有隧道，我们流量如果是EIP流量，直接封装隧道到TGW集群就可以了。

提问2：VPC网关有什么作用？

王营：VPC网关有一个比较非常典型的场景----Endpoint。因为我们要提供一些基础的服务，比如像NTP，像yum源这些类似的，它可能不是说每个VPC都会去做部署。它在我们的物理网络里面。当然还有很多其他的功能。像NAT网关它这个就是共享EIP，我多个虚拟机可以用同一个EIP出去。共享EIP，一种情况，单独EIP可能每一个虚拟机有一个EIP，但是你有可能，比如说你不需要给每个虚拟机，它只需要单向出，我可能只需要主动访问公网，并不需要公网主动访问我。这种就可以用NAT网关。

提问2：你刚才比如NAT？

王营：你说单独的EIP吗？共享的是吧？共享的话也会TGW，因为我们公网统一接入就是TGW。

提问2：你刚才一个集群有十几万？

王营：那个是我们测试的极限性能。目前我们单个集群最大的，可能还没到10万，可能是几万台吧。

提问2：这个架构普通来说很难做到。

王营：我刚才介绍的时候说了两个关键的点，一个是说通过读写分离。另外我们在Server和Agent之间有一层内存缓存。可能有一些更细节的，那些不太方便在这里说明。

提问3：我想问一下V**网关这一块，是纯粹自研的吗

王营：我们现在V**不是开源的，也不是自研的。它也是用的，用的镜像是厂商的。它这个能够做到V**网关之间，它是主备，但是它之间也是能做Session同步。

提问3：比如说上海天津，机房互联VPC？

王营：我们VPC之间的互联吗？

提问3：你们机房之间的数据传输？

王营：我们机房之间肯定是走专门的，我们运营商专线，就那种类似于直接通过光纤打通那种，肯定不是走V**，V**它质量是没办法保证的，它是直接走的官网。

提问3：网上看到一篇文章。

王营：其实房间这种互通，不会走V**，一般都是有专门的，要么租运营商的，要么自己建设的。

提问3：专线的成本对于腾讯来说不算贵是吧？

王营：这里面的专线，你刚才问的问题是，我们机房内IDC互联。

提问3：我想问一下V**，它两个点之间互联，是不是需要中心服务器？

王营：这个不会。

提问3：两个点就可以互联是吧？

王营：因为现在V**它创建，或者你在某一个region，它就是在这个region使用，基本上这种机房它都是有接入点的，相当于你访问公网的虚拟机，可能是类似的。

提问3：腾讯的V**几层了，是三层还是？

王营：你的意思说V**隧道，拆隧道的拆解和？

提问3：（44：06）。

王营：你是说类似于像openswan这种。它的组建是跑在应用层，还是用户？

提问3：还是SSL？

王营：这个应该是在，这个因为我不是太确定。这个东西我们是厂商提供的一个镜像，它这个应该是在应用层。

提问3：我想问一下，流量跑的过程，网络要加速的话？

王营：公网的是吧？

提问3：对，公网加速。

王营：这一块目前我们已经做了一部分，它的公网接入，我们现在通过any cast的方式，可以做到地域的接近接入。它主动发送过来的话，是可以就近接入的，但是它回包目前我们正在做的是，相当于是以前那个回向的话，可能不是说就近接入的。目前我们正在做的，正在做这个就近接入，到时候可以做到双向的就近接入。比如说它从，比如说可能他买的资源是在北京，他从上海访问的话，可能上海有就近接入点，通过上海接入之后，走我们内部的DCI，他可以到北京来。但是回包，其实相当于说我们也是可以直接走DCI，从上海那边再接收到回向的流量。

提问3：在软件定义网络这一块，有没有自定义wan网络？

王营：我们现在已经在做了。就SD-WAN。

提问3：也有？

王营：对，这个可能今天没有做分享。

提问3：谢谢。