云计算产业的发展带来了丰富的用户网络需求，传统的网络设备架构无法满足云计算的需求。早期阿里云用户主要以互联网行业及关联行业为主，主要的需求是能自主规划，安全隔离，转换成云网络的功能简化为大规模、多租户网络隔离的网络（VPC），这个阶段阿里云网络是从经典网络设备架构的大二层网络升级为租户自主规划的专有VPC网络。伴随着大型和超大型企业陆续上云，更丰富行业场景和更多样的服务运行在阿里云上，对云网络的规模、性能、弹性提出了更极致的要求，也驱使云网络不断持续优化，在这个阶段阿里云云网络全线开始进入网络优化持久战，走上一条“螺旋”上升的路线。

1. 从经典网络到专有网络

阿里云是在2009年开始做云计算的，那个时期经典网络技术比VPC技术更加成熟也更加简单，因此那个时候阿里云最初也是选择经典网络技术，经典网络最明显的特征是大二层，所谓的大二层指的是经典网络在二层是完全互通的，整个经典网络通过邻居表来转发报文，虚拟网络和物理网络之间强耦合，用户购买经典网络服务器后，服务器的IP地址都是分配好的，客户无法自助规划网络，同时由于服务器之间网络完全可达，需要客户配置好安全规则来保证自身的安全。抽象点比喻在经典网络内的服务器就好比在住在一栋房子里面的不同房间住户，IP地址就相当于门牌号，在租房间的时候就已经分配好了，安全组就相当于门锁，住户需要设置好门锁来防止串门。

伴随着云上用户增多，和越来越多的客户开始拥抱公共云，对弹性、安全提出了更多的要求，经典网络方案的弊端开始暴露，例如

●安全隔离不足：由于是大二层的网络，虽然默认配置下安全组的策略是禁止互访，但会出现客户自主配置的安全策略范围较大导致的非预期的安全事件。

●物理网络强耦合：经典网络机器的ARP（Address Resolution Protocol）信息的获取需要依赖物理交换机，灵活性较差。

●地址空间不足：阿里云经典消耗大量私网IP地址，因为经典网络服务器均分配在一个地址空间内，当虚拟机呈规模增长时，会出现地址耗尽无法扩容的问题。

●虚拟机迁移域受限问题：云服务弹性可伸缩是衡量云厂商产品和服务优劣的重要指标，这一切都依赖于热迁移。迁移域指的是虚拟机在私网、公网IP地址不变的前提下可以迁移的范围，而经典网络中由于和物理网络强耦合，私网和公网的配置依赖物理网络设备的配置，导致虚拟机无法灵活跨集群迁移和故障快速恢复。

●自主规划：经典网络场景下由于IP地址是购买时候已经分配好，客户无法自主选择，客户无法按照自身的实际业务规划和需求进行网络规划，无法有效支持大型企业上云。

经典网络正是因为上述的这些不足，促使阿里云云网络全面进入VPC网络研发，并在2014年发布阿里云VPC专有网络产品。专有网络是基于VXLAN等技术构造的隔离的Overlay网络环境，专有网络之间的逻辑上彻底隔离，并实现了与物理网络之间的解耦。抽象点比喻在专有网络中，每住户都独立的购买了一个独栋的别墅，在购买的时候只需要选好地基（专有网络的网段），然后住户可以自定义对每个房间进行装修，划分不同的房间（VSW虚拟交换机），每栋别墅之间都是完全独立的互不影响。

全面拥抱专有网络，第一个阶段是让现有经典网络用户能够享受专有网络的红利，于是从阿里云从2014年到2018之间一直在推动经典网络迁移专有网络方案的落地，期间在2016年7月开始为新用户默认推荐专有网络VPC，2017年8月阿里云发布Classiclink标志着经典网络迁移专有网络方案成熟。

Classiclink是用于迁移过程中暂态下经典ECS和VPC网络互通的一种解决方案，经典网络和VPC网络是两个网络平面，ClassicLink将这两个网络平面拉齐，让其具备互通的条件。使用ClassicLink后，经典ECS可以访问VPC内的资源。同时VPC内的ECS只能访问已链接到该VPC的经典网络ECS，不能访问尚未链接的经典ECS，也不能访问经典网络内的其他云资源。技术方案上，是经典网络ECS和VPC之间建立VXLAN隧道，让经典网络的转发面和VPC的网关流表中拥有对方的信息，从而实现互通。

Classiclink解决迁移过程中经典网络和专有网络之间服务器内网互通的中间态问题，但是客户在迁移过程中对于保留公网存在强需求，比如更换ICP备案，域名和IP地址绑定，外部接口对IP白名单的强绑定关系，采购的商业软件授权失效等问题，为了做到公网IP不变，需要将经典网络物理下与物理设备强关联的公网IP，整体上移到Overlay的虚拟网关，公网上移后IP地址由SDN控制器控制面集中管理，而未上移前IP地址与物理设备集群关联性较长，无法跨集群分配，也因为由Overlay网关集中管理，公网上移同时提升公网IP地址的利用率，在IPv4地址逐渐耗尽的时代意义非凡，2018年3月公网上移完成，也从2018年开始阿里云全面进入专有网络时代。

2. 业务模型带动专有网络底层持续演进

专有网络的底层组成主要由VPC控制器（Controller）、虚拟网络网关(Gateway)、虚拟交换机（vswitch）而这三个部分的演进路线因为角色和承载的流量大小不通，各自演进的路线各有不同。

VPC控制器是阿里云VPC网络的控制引擎，向上承接着用户控制台的管控接口，客户在控制台的创建和路由变配等通过一层管控能下发到VPC控制器，向下控制着虚拟网关和虚拟交换机等数据面单元。

在超大规模的云网络中，虚拟网络控制面主要有三个挑战：

●更大的表项：更大分为两个方面：

○1. 云网络一个虚拟网关集群上面通常会承载上百万的流表信息，流表包含路由表、虚拟机与物理机对应关系表，转发表，地址映射表，QOS限速表等，假如1个VPC对应最基础的三个表，每个表项内有三条信息，那么上百万个VPC就至少包含了300万个表，900万条信息，而通常一台大型物理路由设备的路由表项在几十万，云网络的控制面流表信息已经远远大于基础的物理网络。

○2. 伴随着客户自身业务的增长一个虚拟网络VPC中往往会有持续的虚拟机增长，一个VPC里面甚至会超过5000台VM的规格，这样需要一个流表中能支持更多的表项。

●更广的流表：相应的云网络的控制面不仅仅只存在与网关设备上，每一台虚拟机都存在相应的流表信息在物理机上，那么假如一台物理机上有10个虚拟机，一个计算集群有5千台设备的话，一个数据中心内可能存在6个集群那么对应的控制面板需要管理在10*5000*6个单元

●更快的生效：云网络中虚拟网络控制面需要支持超过10W VM的虚拟网络，批量变更生效时间的200ms内(一次RTO)。一个用户操作自身的VPC变更，不会对其他虚拟网络造成影响，对于云网络而言客户层面的操作是无序的且不可预预期。

起初阿里云VPC控制器1.0需要处理的业务比较简单，同时数据量也比较小，控制的设备数量也比较少，架构相对简单，烟筒式处理，收到上游业务方请求，将请求中的参数转换为系统内需要的对象模型，每个请求对应一个处理流程，校验参数合法性，生成对应的配置下发流表，数据面单元响应，确认请求结束。这个架构简单、高效，但是并发能力差、可扩展性差、无法有效管理大量转发设备。随着业务量的增加，尤其是虚拟交换机的数量指数级别的增长，给虚拟交换机下发配置的压力越来越大，控制器2.0引入中间层服务，形成异步化处理，从而节约整个接口的耗时。

全面进入VPC时代后，云上的虚拟机数量开始爆发式的增长，VPC控制器管理的机器数量也开始呈现几何数量增长，更胜者阿里集团提出单一VPC百万级虚拟机的需求，数十万设备要求秒级完成配置下发。为了满足这样的业务模型变化，VPC控制器3.0进行了横向划分，分成四层，API处理层、业务逻辑编排层，task处理层，配置下发层，并针对虚拟交换机数量多、单机配置较少和虚拟网关数量少、单机配置很多特点，分别设计虚拟交换机下发引擎和虚拟网关下发引擎，这样的架构将系统水平分割、不同层次之间相互独立，进一步演进的方向也已经明确，将每个业务单元独立微服务化，进一步向微服务化发展。

3. 内部服务去网关：业务潮汐，南北向流量下沉东西向

在数据中心物理网络中，通常将网络流量分为两种类型，一种是数据中心外部用户和内部服务器之间交互的流量，这样的流量称作南北向流量或者纵向流量；另外一种就是数据中心内部服务器之间交互的流量，也叫东西向流量或者横向流量。

在专有网络中，上层云网络淡化了底层物理网络的框架和架构，而是通过虚拟交换机和虚拟网关两部分来定义整个转发平面，因此可以简化成所有要和网关进行通信的流量都是南北向的，而无需经过网关直接交互的流量是东西向的，这样的网络转发也带来了新的问题，比如当VM和VM之间需要直接通信，因为在云网络里面所有的VM都是虚拟出来的，在VM的不存在远端真实的MAC地址，而所有的MAC地址都是物理机上面的ARP Proxy代理后直接返回给VM的，所以在云网络中VM之间的之间通信在物理网络中都是封装在三层之上的，这导致了物理机之间几乎没有直接互访的流量，所有的流量都转发到了虚拟路由器所在的网关上进行转发，由虚拟路由器提供中转。

这样带来的新问题是网关的负载很高，伴随着客户云业务的发展，从传统的直接和公网客户端之间互访为主的业务模型转变为在数据中心内有大量的交互和计算型的业务模型，同时伴随着打通不同VPC之间对等连接(VPCPeering)需求，VPC间的互访也需要经过虚拟路由器所载的中心化的网关，VGW成为了云网络扩展的瓶颈。

如上图所示，针对中心化的瓶颈，最优的方案就是去中心化，将VPC间VM互访的流量、VPC内VM互访的流量从图中的红线部分，下沉到绿线的部分，让这部分需要去网关交互的南北向流量下沉到东西向，从而旁路掉中心化网关的瓶颈，进一步扩展云网络的横向能力。

为了使得VM间互访的流量下沉，阿里云将所有的路由表项下沉，在虚拟交换机的层面就下发VM和物理机对应关系表，但通过控制器向所有物理机全量同步所有vm之间的直连路由表项难度大，因此阿里云自研RSP（Route Synchronization Protocol）通过RCM（Remote Control Message）来针对海量VM路由与物理机关系的刷新。

当物理机内的虚拟机创建成功后，开始对VPC内的其他虚拟机进行请求，这里用TCP请求举例，由于第一时间没有表项的存在，TCP报文的SYN报文会转发给VGW(vRouter Gateway)，因为物理机中没有虚拟机远端的表项，这个SYN报文发送的同时会发送一个RCM request请求报文，报文的Payload载体包含源物理机IP、VPC的Tunnel ID、目的VM的IP地址，VGW收到业务的SYN报文后会直接转发给远端的物理机，在收到RCM request报文时候，会将目的物理机的IP地址返回给源物理机，源物流收到后，会将该信息更新到自身的表项中，回程的报文同理，当目的物理机收到源的SYN请求后，目的虚拟机响应的[SYN,ACK]报文会发送到VGW，同时发送RCM request请求来获取对端的信息，当收到VGW的RCM  reply后，会将源端的物理机IP地址保存在自身的表项中，后续的业务交互就无需VGW参与，两侧的物理机直接进行通信，完成流量的下沉。

相关的交互可以参考下图：首包->首包回包->后续业务报文。

4. 边界网关硬件化：硬件破局，二八效应下的大象流难题

云网关的演进和它在云网络中处于的角色以及物理网络的发展息息相关，云网关本身主要是处理网络中南北向相关的流量，主要指的是公网流量、VPC间互通流量、跨数据中心的专线的流量，也因此初期阿里云网关由IGW（Internet gateway，处理公网相关流量）、VGW（vrouter Gateway，处理私网相关流量）、CGW（Customer Gateway，处理专线相关流量）三部分组成。

为了让虚拟网络集中式处理，2013年阿里云开始走上自研基于DPDK高性能转发套件的x86平台，从硬件网关全面转化为基于DPDK通用x86架构设计，独立部署的虚拟网关，并且从将10G的物理网络转换为4*40G的x86服务器网关架构。但伴随着业务的不断增长，云网关多集群的部署导致建设成本、运维成本过高，且由于不同的流量波峰波谷不一，往往存在单一集群空闲另一集群负载不堪重负的情况，因此产生了将云网关合并的需求，将IGW、VGW、CGW合并为XGW，X代表Any。合并后XGW的单机性能得到了很大的提升，CPU核数从16核增加到了32核，单机带宽从40G增长到160G，单机PPS从12M增长到了26M，线上设备的成本降低从原先分拆的3*4变成4台，同时也简化了网关上线的流量，降低了运维的复杂性。

云网关x86集群合并的方式在阿里云线上稳定运行了5年，但是从18年开始伴随着线上业务的高速发展，包括阿里集团的双十一大促，XGW集群的模型遇到全新的挑战，DPDK架构下存在单核PPS性能瓶颈，当一条大象流转发到云网关时，固定的五元组会转发到CPU的单核上处理，导致单核被打满，从而影响所有其他的客户，影响整体的稳定性。另外XGW的单机转发性能也成为瓶颈，18年末有头部客户提出单集群支持1.6T的流量需求，XGW集群单机40G，支持1.6T并且按照50%水位评估，需要至少80台的x86机器支持，这样规模的集群是无法进行有效维护和管理的。

基于这样的背景和业界的方案调查，阿里云云网关选择软硬一体化的方案，先对阿里云线上的业务流量进行分析，可以看到20%的客户业务占据了云上80%的流量，这20%的客户的流量模型基本上都属于大象流，这样的流量是适合用硬件化的网关来进行承载的。20%的客户的流表数量有限，对于硬件化网关，需要用仅5%的表项，承载95%的流量，剩下的表项用软件化的网关辅助，软件化的网关负载95%的表项，承载5%的业务流量。

阿里云新一代的硬件网关，具备超强的计算能力和高带宽的交换能力，对于快速转发业务可以offload到Tofino芯片做转发，对于负载的业务逻辑可以上送CPU进行灵活处理，同时考虑空间和部署的便利性，新一代硬件网关机体升设计为2U的紧凑型机箱。

• 交换能力：3.2T可编程交换芯片，32*100GE QSFP28网络接口
• 计算资源:最大支持2个CPU，26 cores per CPU，128GB DRAM
• 6*PCIE，同时支持FPGA扩展

网关硬件化后，首先解决了DPDK x86架构下集群单核性能问题，和单机群容器的问题，同时有效降低了边界网关部署的成本，在原有1.6T需要部署80台x86机器的情况下，硬件化后仅需1台硬件网关。

5. 能网卡：带宽再提升，从软件卸载到硬件卸载

虚拟网关硬件化，解决了南北向大象流的问题，并且伴随了去网关化，南北向流量的瓶颈短时间内不在成为瓶颈，东西向的流量阿里云也未停止过演进的步伐，东西向的流量溯源看是单台虚拟机的能力，而单台虚拟机的能力由物理机上的虚拟交换机模块决定，从13年初代阿里云虚拟交换机(apsara virtual switch，简称AVS)基于bridge和netfilter，到15年参考快慢转分离重构的AVSv3，再到17年基于用户态实现的DPDKAVS，阿里云从未停止对单机性能的极致追求。伴随着虚拟机规模的不断增大，用户态的DPDKAVS不足之处逐渐凸显。

首先是资源成本，AVS本身作为一个软件运行在物理机上，需要独立的CPU和内存资源，这样导致物理机本身可以对外售卖的资源变少，也就是常说的云资源的公摊成本，第二是虚拟化的开销，虚拟机在接受和发送报文的时候，都需要CPU执行内存拷贝的操作，而在大带宽的场景下，CPU的内存拷贝是十分消耗计算资源的，第三是numa开销，阿里云公共云线上的机器至少是两路CPU的，如果AVS的CPU和虚拟机的vCPU在不同的CPU node上，会导致大量的LLC miss，进而导致转发性能下降。同时由于物理机型号的不通，AVS需要有大量的适配工作，需要适配网卡的型号，物理机的CPU的架构，这样在部署和维护上存在大量的工作。

伴随用户业务对性能极致要求，服务器100G网卡的普及，单纯的软件化方案已经无法直面云业务的需求，业界和阿里云都将单台虚拟机的能力提升聚焦到智能网卡（smart network interface Card，SmartNIC）身上，通过将虚拟交换机的功能卸载到网卡上，利用智能网卡独立的CPU和硬件提升网络性能。

什么是智能网卡？网卡（network interface card，NIC）是连接网络和服务器的网络硬件设备，用于网络数据传输和通信，智能网卡是一种灵活可编程的网卡，在网卡的基础上增加板载CPU，与服务器配合使用。智能网卡具备独立的计算资源，从而释放宿主机的CPU算力，智能网卡将负担网络、安全、存储中不适合CPU相关的数据处理功能卸载到可编程硬件芯片执行，在云网络中也将虚拟化hypervisor进行卸载，使得服务器能更有效的运行业务程序，优化业务数据处理整体效力。

C-3 ALBABACOUNS

阿里云MOC卡是一张带有CPU的片上SoC，是一种智能网卡，AVS由原来运行在物理机的host CPU变为运行在网卡上的独立CPU，同时将虚拟化KVM架构下virtio驱动进行替换，AVS从物理网络接受报文后不在通过CPU 内存拷贝的方式将报文拷贝到虚拟机，而是通过硬件DMA方式将报文拷贝到虚拟机，这样的软件卸载架构下首先解决资源问题，物理机可售卖的内存和CPU得到增加，降低物理机成本。通常网卡的CPU成本会比物理机的CPU成本低，同时硬件DMA的方式能更有效的解决CPU，从而使得智能网卡场景能更好的支持大带宽。

快慢转的转发路径

在软件卸载的基础上，AVS借助硬件转发优势，并且参考快慢转分离的模型，在原有的软件卸载模型在更进一步的增加硬件卸载，使得网络转发性能大幅度提升，当前最新一代的MOC 2.5支持200G网络带宽，5000W PPS，并额外增加流量镜像、eRDMA、VPC加解密、jumboframe等特性。

阿里云云网络通过智能网卡，使得阿里云最新一代"网络增强型"实例支持160G网络带宽，3000W PPS，1600W连接数，为业务网元NFV化奠定基石。

6. 业务网元虚拟化：效能与成本，网元全面拥抱云原生

在传统网络中，不论底层的IT基础设施还是上层的应用，都由专属设备来完成。这些设备成本高昂，能力和位置僵化，难以快速响应新业务对网络快速、灵活部署的需求。随着云计算的快速发展，云服务提供商以及互联网企业迭代创新的特征也对网络功能的快速部署、灵活弹性甚至成本，都提出了更高的要求。欧洲电信标准协会（ETSI）首先提出了NFV（Network Functions Virtualization，网络功能虚拟化）的概念，通过使用标准x86的服务器、虚拟化等技术，将网络硬件设备和业务解耦，使网络功能不再依赖于专用硬件。虚拟化资源可以充分灵活共享，实现新业务的快速开发和部署，并基于实际业务需求进行自动部署、弹性伸缩、故障隔离和自愈等。

上图是ETSI发布的一个NFV参考框架，左侧从下到上可以分为三层，最下面是基础设施层，为虚拟化提供物理资源以及虚拟技术的支撑。中间是虚拟功能和对应的EMS系统，网络服务的实际业务处理就在该层中实现，最上面是运营支撑层，也就是运营商的OSS/BSS系统。右侧是NFV中的核心，主要负责编排和管理。可从图中看到这块由三个模块构成：NFVO、VNFM、VIM。NFVO负责NS的编排、VNFM和VIM的管理。VNFM负责管理VNF的生命周期，并对VNF进行监控，VIM负责管理虚拟化的基础设施。

在计算机网络中，网元是联合一个或多个物理设备的可管理的逻辑实体，而在云网络中业务网元指的是NAT网关、负载均衡（Server Load Balancer，SLB）、云企业网（Transit Router）、私网链接（Privatelink）、VPN网关这些提供特定网络逻辑功能的产品底层模块。

在此前的云网络中，用负载均衡举例，采用专用的硬件资源建设LVS（Linux Virtual Server）集群，而一个机房的物理机设备集群往往是提前规划好的，当客户业务出现短时指数级的增长时，基于物理机形态网络设备的问题缺点就被放大，例如，物理机采购和部署周期长，机柜位和上联物理交换机需要重新规划，物理资源扩容困难，同时集群化部署故障域大，云网络功能发布周期长，新功能迭代缓慢等问题，并且由于基于物理机这种功能模块化的网元节点不具备高弹性能力，这个点和云计算的理念是相斥的。

边界网关通过硬件化来解决大象流问题，转发性能是硬件设备擅长的，但是对于负载均衡，SNAT这类有状态的复杂业务，硬件设备就显得有些力不从心了。阿里云软硬件一体的方案，很好的兼容性能和灵活性，同时通过将业务网元的功能部署在虚拟机中，很好的结合虚拟机的弹性能力，从而实现高性能、高度灵活、高度弹性的网络需求，硬件网关负载基础转发能力，将复杂的网络应用逻辑导流到对应的NFV网元，而NFV网元基于虚拟机ECS部署，实现SLB、NAT、CEN TR、VPN等网络功能的业务逻辑，并基于阿里云ECS的能力实现弹性，拥抱云原生，并且阿里云提供统一NFV平台Cyberstar为网元的开发提供统一的底座，网元的开发仅需要专注在逻辑代码层面的开发，弹性和NFV层面架构都用NFV平台提供。

阿里云NFV平台参考ETSI ISG NFV工作组的MANO模型，将NFV管控划分为NFVO、VNFM和VIM三大模块，如图所示：

阿里云NFV平台中，VIM（Virtual Infrastructure Manager）负责南向NFVI层的虚拟存储、网络、计算资源的管理，负责虚拟计算资源的生命周期管理，创建、删除、上线、下线以及灰度升级。VNFM主要为业务网元分配一组/多组逻辑的计算资源，同时满足计算资源组的高可用、弹性、故障隔离和自愈的需求。并且阿里云NFV平台提供shuffle sharding的能力，有效的缩小故障域。

NFVO层根据业务网元注册的网络拓扑，为业务网元编排分布式的快慢速节点，并且阿里云NFVO层设计实现了一套分布式的快慢速转发架构，在实现上用两层ECS组成，Fastpath ECS无状态的转发层，有Slowpath ECS下发offload转发规则，一台流首包miss到Slowpath处理，Slowpath根据逻辑规则下发flow到快转后，后续所有业务流量转发到Fastpath后直接进行业务转发，采用这样的架构业务网元仅需要专注于网络本身的业务逻辑处理，即只需要关注首流的处理，其它复杂逻辑比如分布式的Session同步和后续报文的匹配规则和逻辑转发全部交由NFV平台处理。

Fastpath借助AVS ECMP能力实现无状态化转发层示意图

阿里云的业务网元通过NFV平台的VIM层有效的在大流量业务出现时候水平扩容，并在业务减小时缩容，有效的弹性降低网元成本，并且整体的编排方式与K8S对service的编排类似，NFV网元也将全面拥抱serverless。

7. 小结

●经典网络由于安全隔离不足、与物理网络强耦合、地址空间不足、故障域、不满足客户自足规划的特点，促使阿里云演进到专有网络VPC。

●VPC控制器的演进的核心目标是满足超大规模网络组网，提供极致弹性的网络管理能力。

●内部服务去网元，通过首包查找流表的方式将部分虚拟机之间互访的流量，卸载到东西向，解决了集中化网关的瓶颈。

●20%的客户贡献了80%的流量，并且大多数流量是单一五元组的大象流，促使阿里云云网关演进，从x86 DPDK云网关转向可编程的硬件化网关。

●单台虚拟机的流量通过智能网卡再突破，阿里云智能网卡也采用快慢转分离的模型。

●业务网元NFV化，通过NFV平台的能力实现阿里云业务网元弹性能力，有效节约成本。

●阿里云NFV平台的快慢转分离能力使得业务逻辑的开发简化。

附录

阿里飞天洛神云网络VPC团队与浙江大学合作的学术论文洛神(Achelous)，为云网络贡献了第三篇SIGCOMM论文，是继Azure的VFP（NSDI'17）和GCP的Andromeda（NSDI'19）之后，第三个在顶级会议上分享的头部公有云网络底座平台。