前言
在移动互联网时代，随着短视频、直播、游戏等业务的发展，催生了大量云原生的业务和应用。企业客户通过云下云下组成混合云环境，可以快速进行业务的部署和迭代。在混合云组网中，无论是数据库、分布式缓存、对象存储，还是大数据的存算分离模式，大部分都采用云上云下资源动态分布的系统架构，系统间的调用往往需要毫秒以内的时延。同时因为大数据和AI等业务会产生大量的数据传输，占用大量的网络带宽。因此腾讯云专线面向此场景而产生，提供企业客户大带宽、低时延、高安全上云，实现企业数据中心和腾讯云无感互通。
云专线1.0架构（商用集成）
早期随着腾讯云的发展，大量客户开始利用云上资源和IDC自有的资源组成混合云环境。为了快速支持客户接入，同时又保证客户之间相互独立、质量稳定，我们通过商用设备和腾讯云的控制系统融合，提供了第一代的EGW(Enterprise Gateway)网关系统，EGW并非单指转发网关，而是泛指腾讯提供专线服务的一整套系统，EGW 1.0架构如图1所示。
图1 EGW 1.0架构
在EGW 1.0架构，我们使用了商用的路由器、商用的软转发网关用来做接入、路由控制、隧道封装等能力，得益于商用设备的功能完备性和稳定性，初期的EGW给客户提供了稳定的企业接入服务。但是随着云业务的发展，云上云下的带宽交互越来越大，动辄上Tbps的大带宽需求，业务增长的同时也意味着路由规格的增加，单客户百至千以上的路由要求秒级快速收敛。当然我们最开始想到的是通过基于路由器和软转发网关系统迭代支持，但是商用路由器除了高昂的运营成本外，研发、测试、部署、上线的周期一般都是以年计。此外，在EGW 1.0架构，租户的路由实际上通过L3 VPN技术隔离，租户间网络共享路由器，组网架构本身也无法再进行灵活扩展。
客户数据中心的IPv4地址的枯竭， IPv6 资源覆盖范围的不断扩大，客户对云服务平台支持IPv6的需求越来越强烈。因此基于IPv6普及的大背景下，云专线必须能支持IPv6。但由于EGW 1.0基于L3 VPN技术，意味着接入设备和内网进行大量的升级变更才能支持IPv6，无法快速实现全网覆盖。
简而言之，专线1.0架构受限商用设备能力、L3 VPN架构本身收敛性能，无法灵活的满足专线客户快速迭代的需求。
云专线2.0架构（全面自研）
商用设备是从商业销售的通用性出发，没办法做到完全匹配云的需求，并且很多特性在EGW中并不能够用上，设备的性能和迭代，都会受限商用策略而没办法优化。为此，我们把商用的设备进行了拆解和抽象。
我们把商用设备抽象成三个主要功能模块：转发模块（芯片）、控制模块（处理配置和表项）、路由模块（处理各种的协议生成转发路由）。因为这三个模块是集成在设备的板卡上的，所以会产生一定封闭性。我们把三个功能模块，升级成如图2所示的SDN分布式路由器系统，每个系统是分布式系统，系统和系统间标准接口交互，这样实现EGW网络系统的迭代是可以基于子系统独立、快速迭代，可以系统层面选择实例进行灰度。
图2 SDN分布式路由器系统架构
因此基于商用设备架构和SDN分布式架构的分析，结合专线1.0架构客户大规模上云的需求所面临的大带宽、大规格路由秒级收敛、IPv6等业务需求，EGW 2.0采用全栈自研的分布式路由系统，实现了现网架构的无感知升级，由传统的网络闭环系统，变成和云环境整合的如图3所示的软件系统，包括控制系统、路由系统、转发系统三个关键组成部分。从架构可以看出，专线EGW 2.0架构只是腾讯内部架构的升级迭代，对用户组网完全无感知，相反客户可以从该架构获得更好的上云体验。
图3 EGW 2.0架构
EGW2.0系统实现自研后，好处是显而易见的，这样系统的维护不再是传统的网络脚本配置、网络变更，而是如图4所示，通过云原生的系统实现无感知的平滑升级，同时因为升级过程中客户完全无感知，解决了商用设备版本发布过程中对客户流量的影响问题，可以做到快速迭代、无感知升级。
图4 系统平滑升级示意图
控制系统 ：智能、高效
专线控制系统采用如图5所示的微服务架构，基于云原生部署，通过与路由系统、转发系统交互，充分利用云原生DB、分布式缓存、消息总线等中间件的高性能优势，实现业务配置同步和系统高速交互。
图5 控制系统架构
云原生架构：租户秒级路由收敛、全网亿级路由管理
控制系统完全基于微服务架构，将北向API层、核心业务层、南向驱动层、运维管理微服务化解耦，解耦后的微服务基于云原生的环境构建，可以快速弹性扩缩容，实现租户秒级路由收敛，全网亿级的路由管理，远远突破了商用设备的路由规格限制。
智能调度：亲和降时延，反亲和保稳定
腾讯云专线POP点为了实现对用户更广泛的覆盖，接入点分布每个城市的多个机房，而腾讯的公有云园区一般则会选择相对大型的数据中心，接入点则通过腾讯的四纤三路由标准连接到公有云园区。此外，转发系统也会根据接入点分布、客户接入情况、园区的计算资源分布等情况，采用跨可用区多集群部署。因为现网的实际情况需要综合考虑用户需求、成本、运维等情况，那么集群的分布情况相对会比较复杂。
企业客户通过云专线上云，从组网层面一般至少双POP点接入腾讯云满足组网层面的高考用要求，以如图6所示的组网举例，控制系统基于专线典型的低时延、高可用原则，根据租户、网关实例、POP点位置、集群情况进行调度。
根据低时延原则，进行亲和调度，将客户1的专线网关实例1和2调度到离接入点最近的园区1、2的集群上，客户2的专线网关调度到园区3、4的集群上实现企业客户入云时延最低；根据高可用原则，进行反亲和调度，将同一客户的不同网关实例调度到不同的物理集群，进一步提升业务稳定性。这里提到的组网只是一种举例，实际上基于现网更多的接入点、园区、集群的组合情况，以及客户的组网情况会更复杂，但调度的宗旨主要是基于时延和高可用等因素。
图6 智能调度
智能运营：秒级故障发现、诊断、恢复
根据现网的实际运行情况来看，影响系统运行稳定性的其中一个原因便是系统间配置的一致性问题。EGW1.0 架构因为是商用的闭环系统，无法实现全链路设备的一致性配置核查，效率也相对低效。在EGW2.0，控制系统、路由系统、转发系统都基于开放、灵活的接口调用，输出结构化的配置数据，通过运营微服务实现租户配置秒级一致性核查和自动修复，从配置层面提升现网运维稳定性。
此外，专线端到端链路除了EGW系统外，还会涉及到Underlay网络、云联网网关等环节，因此，专线运营管理服务实现了基于业务流的端到端时延和连通性探测，并结合腾讯AI智能分析平台，实现流级别的路径分析，提前发现问题并实时修复，为问题定界定位提供有效的手段，进一步提升现网稳定性。
路由系统-开放、灵活、高性能、低成本
专线 EGW 1.0架构，客户的路由依赖厂商传统路由器进行路由传递与收敛。路由器将控制、路由、转发都集成在一台单体设备，客户之间会产生资源抢占。此外，商用设备从通用性的角度出发，支持各种复杂的协议，版本迭代开发周期长。因此，综合来看，商用路由器无法灵活的满足专线客户的BGP、BFD等大规格路由快速收敛的需求，无法进行需求的快速迭代。因此，从专线业务的实际场景出发，从零开始进行EGW2.0架构的路由系统设计，以路由快速迭代和收敛为业务目标，针对复杂的路由协议做减法，更聚焦在核心功能和性能提升，最终采用如图7所示的路由系统架构。路由系统基于云原生理念，将配置管理、协议层、路由管理微服务解耦，底层基于容器部署支持灵活的Scale Out能力。
图7 路由系统架构
高性能、高规格-百万租户、亿级路由
基于容器化平台部署，通过控制系统智能调度服务，可支持租户级别独占实例；基于云原生数据库、消息总线，实现高性能的路由迭代与收敛，单租户路由可秒级收敛；基于弹性资源池，充分利用容器快速启停能力，支持快速弹性扩缩，支持百万级租户、亿级别路由处理能力。
高安全-云原生租户隔离
传统的路由器基于VRF粒度进行租户路由隔离，资源会互相抢占，同时也会因为畸形路由等互相影响。专线2.0路由系统基于轻量化容器部署，不同租户的协议运行在不同的容器实现物理层面隔离保障租户的路由安全性。
智能运营-路由安全与分析
专线路由系统支持基于租户、前缀、流等各种维度的策略和BGP安全检查，结合腾讯AI智能分析平台，可以实现租户路由的快速分析、故障诊断、系统自愈，最终实现可视化运维，提升系统稳定性。
转发系统- 高性能、高可用、高安全
专线转发系统是专线业务全链路中最重要的一环，承载了大带宽的实时业务流量转发。转发系统基于NFV平台资源池化部署。这里的NFV不是狭义的硬件虚拟化，而是广义上的通过灵活的可编程平台实现网络转发功能。转发系统的架构如图8所示，从接入交换机到后端的VPC全链路采用隧道封装技术，与underlay网络解耦。
图8 转发系统架构
高安全、高可靠：物理层和软件层双重隔离
NFV转发系统资源池化部署，通过智能调度服务，将客户业务进行分池调度，物理上可以将特定客户调度到单独的资源池达到物理隔离的效果。同时底层通过VRF和VXLAN技术，实现租户的业务隔离，在underlay网络基于隧道技术转发，全链路保证客户业务的安全性。
业务层与驱动层松耦合：大带宽、小型业务灵活部署
转发系统关键业务层与驱动层松耦合，业务层提供VRF隔离、路由转发、隧道封装、路由防环等能力，驱动层可适配虚拟机、物理服务器、可编程交换机等资源，最终根据性能、成本、运营的需求进行灵活部署。
云专线可编程网络进阶
专线转发系统最早期采用厂商基于Linux内核态转发的NFV设备。按照内核态转发原理，网卡驱动接收到数据包后通过中断通知CPU处理，然后由 CPU 拷贝数据并交给内核协议栈，这种CPU中断的方式在大量数据传输量时会导致频繁的线程切换，造成CPU性能极大损耗。此外，由于网络驱动接收到的数据包会经过内核协议栈的处理，然后再拷贝到处于用户态的应用层缓冲区，这种耗时的拷贝方式也是影响内核态转发性能的关键因素之一。后期随着DPDK技术的发展，自研的转发系统采用DPDK技术，基于DPDK的PMD能力，通过内存零拷贝、大页内存、无锁队列等方式极大了提供了服务器的网络处理能力。与此同时，随着CPU和硬件网卡的能力提升，服务器经历了10G、40G、100G迭代，不断提升单设备的转发能力，并结合专线无状态路由转发的特点，通过横向扩容服务器数量支撑客户不断增长的业务流量。
但随着互联网短视频、直播业务的发展，大数据存算分离模式的应用，客户云上云下途径专线的流量呈现爆发式增长，单客户动辄可达Tbps级别带宽。对于Tbps级别的业务流量，服务器将近上百台的规格，设备数量急剧增加的同时，运营成本增加、交付周期延长、运维复杂度提升、扩容难度更是难上加上。此外，随着大数据、对象存储等业务的发展以及自身处理能力的提升，导致频繁出现大象流、微突发等难以定位的网络问题，导致客户业务的抖动。虽然基于服务器形态的转发系统能基于实时流统计功能，可以识别大象流，定位问题原因。但单流性能问题由于受限于CPU单核处理性能，已经达到物理上限，无法通过技术手段解决。因此，基于可编程交换机的转发技术为解决上述问题提供全新的方向。基于内核态、DPDK、可编程交换机三种架构的对比如图9所示，可编程在应对大带宽、高性能的转发场景的优势显而易见。
图9 不同转发架构对比
高性能、低成本、低时延 –Tbps带宽，2us 时延
基于可编程交换机的转发系统，不再像服务器一样经过复杂的硬件处理流程，流量仅在ASIC芯片上即可完成所有的处理，实现高效转发，转发时延2us，单流 100Gbps线性转发完美解决大象流问题，整机Tbps带宽、PSS可高达12亿，转发性能提升的同时运营成本也同比下降。此外，对于专线对接的VPC中有大量虚拟机和容器的场景，需要支持百万级别的路由。因硬件受限于芯片SRAM/TCAM等表项资源，通过流水线折叠拓展了业务表项也可以满足此类场景需求。因此综合来看，基于可编程硬件的转发系统完全与专线大带宽、高性能、低时延的业务诉求不谋而合。
软硬协同 - 业务灵活定制，需求快速迭代
专线可编程硬件转发系统基于腾讯可编程平台，硬件模块化设计、软件一体化平台、可编程框架、服务APP部署及数据面（Pipeline）灵活定制，通过软硬协同的模式，满足专线业务流量高性能转发，同时又能支持硬件无法处理的业务，通过软转数据面和路由面处理，即如图10所示架构。
基于可编程数据面的流水线和业务表项编排，实现业务租户隔离、隧道转发、分片等通过硬件直接高性能转发；而对于租户的Overlay ARP和Trace Route等功能则通过基于DPDK的软转数据面处理， Underlay的BGP/BFD/LLDP这些则通过软件路由面处理。为了避免业务上送CPU的互相影响，针对不同的上报业务类型、结合集群的整体能力和业务特征，通过QOS避免业务交叉影响。
图10 可编程转发系统架构
►►►
总结
腾讯云专线上线至今，单客户最大专线接入已达19T，随着客户需求、网络技术演进、成本等因素，经历了从1.0到2.0的系统架构演进、可编程交换机的进阶。新一代的专线架构开放、灵活、自主可控，可满足专线大带宽、低时延、高性能、高安全和快速迭代的业务需求。后续随着需求的迭代、技术的革新，专线架构还会持续迭代，但所有的一切也都会围绕企业接入大带宽、低时延、需求快速迭代、成本等关键因素而展开以不断提升用户上云体验。
欢迎关注公众账号“鹅厂网事”，我们给你提供最新的行业动态信息、腾讯网络最接地气的干货分享。
注1：凡注明来自“鹅厂网事”的文字和图片等作品，版权均属于“深圳市腾讯计算机系统有限公司”所有，未经官方授权，不得使用，如有违反，一经查实，将保留追究权利；
注2：本文图片部分来自互联网，如涉及相关版权问题，请联系：sandyshuang@tencent.com或 mianyang@tencent.com
/
关
注
我
们
/
/ 鹅厂网事/
分享鹅厂网络的那些事
