架构解析｜网易自研新一代大规模分布式传输网

文｜Keith

网易云信服务端首席架构师

沟通是人类永恒的追求，我们总是渴望突破时空的限制，拉近人与人之间的距离。

随着RTC、直播等技术的成熟，更实时、更高质量的通信变得越来越触手可及。结合传统的IM消息等，“融合通信”成了近年来的一个热点领域，而网易云信则致力于打造业界“融合通信云第一品牌“。

想要达到这个目标，通信数据的传输质量是至关重要的，但在长距离、复杂网络条件下保证传输质量一直都是一个难题。并且在追求更高质量的前提下，更低的成本以及更通用、更灵活的架构也是考察一个通信系统是否更优秀的重要指标。

在这些背景下，网易云信自研的新一代大规模分布式传输网络——WE-CAN(Communications Acceleration Network)诞生了。

它不仅可以大大提高端到端的通信质量，降低通信成本，并且能够适用于多种应用场景。

WE-CAN不但有远大的目标、先进的架构设计以及优秀的工程实现，在云信的实际线上业务中也已经得到了充分的落地和验证：

1. 每日传输千亿条消息和数亿分钟媒体流数据；

2. 在亚太的主要国家都有多个节点，印度、中东、欧洲、北美、北非等地区也都有节点覆盖，中国国内每个省级单位都有大量边缘节点，覆盖全球 200+ 地区；

3. 在国内音视频传输中做到了超过99.9%的网内优质传输率，端到端优质传输率超过99%；

4. 跨国通信接近专线质量，全球范围内延迟不超过250ms。

本文将从各个角度剖析WE-CAN的架构设计和关键的技术难点。

1. WE-CAN的定义和目标

WE-CAN(Communications Acceleration Network)是一个架设在公共互联网上，通过对各种资源智能调度来实现提高数据传输质量、降低数据传输成本目标的复杂网络系统。

作为打造网易云信“融合通信第一品牌”的基座，WE-CAN的根本目标是建立一个能将任意数据从全球任一点稳定、快速、高效地发送到全球任何其他角落的通用传输网络，且这个网络是架设在公共互联网之上的 —— 即无需借助任何特殊的硬件设备或架设专线，而是通过软件方案来达到目标。

对比同类产品，WE-CAN的目标是：

• Faster than cdn

• Cheaper than SD-WAN

• More versatile than RTN

2. WE-CAN的优势

做传输网，云信不是第一家，也不会是最后一家，相比其他同类产品，WE-CAN有其独特的优势：

• 相较于CDN来说，WE-CAN不但能做到内容的大规模、边缘化分发，并且能做得更快；

• 而对于RTN来说，WE-CAN不但能支持流媒体RTC业务，也能支持其他多种传输模式。

WE-CAN能对流媒体进行高到达、低延迟的传输，且WE-CAN能在媒体本身的各种QoS策略之外额外进行可选的、对业务透明的ARQ、FEC及其他冗余策略，这些策略对WE-CAN其他所有传输模式也通用；

WE-CAN也能对视频直播进行超大规模分发，通过路径级联和复用消除房间人数瓶颈，降低带宽成本，做到成本上接近CDN，实时性上接近RTC，更好地支持低延迟直播场景；

WE-CAN还能对信令、IM或其他数据进行可靠传输。所谓“可靠传输”是指保证数据一定能到，并且保证数据投递的顺序性；

WE-CAN的服务和协议拥有业界领先的解耦和分层设计，实现优雅，使用简单，方式灵活。例如其对可靠传输协议进行了抽象封装，对外提供了一个极简接口，我们管它叫MessageBus，MessageBus的目标是提供一个全球部署的分布式消息队列服务。

3. WE-CAN的效果

以下都是WE-CAN生产环境的线上真实数据，用云信RTC部分频道走WE-CAN，部分频道媒体服务器间直连(不走WE-CAN)做A/B测试的对比结果。

优质传输率对比

下图是12天的端到端优质传输率变化曲线，从图中可以看出走WE-CAN的频道其网络传输到达率有明显提高(我们的优质传输率指：所有统计窗口中到达率大于95%的比率)：

卡顿率对比

下图是云信RTC音频大盘卡顿率在12天的变化曲线：

延迟对比

下图给出了24小时的大盘延迟梯度统计：

4. WE-CAN的架构

考虑将一个报文从A发到B的过程，站在WE-CAN的角度看，这个过程分为3个阶段：

1. 从客户端A到其接入的服务器A'；

2. 从服务器A'到B的服务器B'；

3. 从服务器B'最后到客户端B。

所以WE-CAN需要优化两种不同的传输场景：

• S2S (Server to Server)，就是网内传输；

• Last-mile，就是边缘接入。

对这两种传输场景的优化又都可以进一步分为两个维度——质量和成本。

所以网内传输和边缘接入分别有不同的手段去优化质量和成本，并在这两者间找到一个平衡。

从这个角度出发，WE-CAN的终极目标就是为各种类型的数据传输需求都能够提供高质量、低成本的边缘接入和网内传输解决方案。

网内传输

WE-CAN的网内传输部分核心系统主要分为三种节点，接入节点(Edge)、中转节点(Relay)、控制节点(Controller)。

接入节点

Edge作为接入节点，是WE-CAN在物理部署上离客户端最近的部分。

中转节点

Relay负责数据在网内的中转，Relay节点相互之间组成一张(近似于)Full-Mesh的网络：

• 数据的中转在远距离传输，尤其是跨国传输时较为多见，有时甚至会需要进行多跳中转。如广州机房的数据发往洛杉矶时WE-CAN可能会让其先发往香港，然后再从香港发到洛杉矶，甚至可能会走广州-香港-新加坡-洛杉矶的中转路径。实际的路径由当时的网络状况决定；

• 第二种需要中转的情况是单线接入节点跨ISP(网络供应商)时，如江苏移动接入节点上的数据要发往浙江电信节点，需通过江苏三线(或浙江三线)Relay进行中转；

• 第三种常见的需要中转的情况是多线机房某条线发生故障或网络抖动时，如杭州三线节点联通口发生故障时，国内其他联通机房可以将数据先发到就近的三线节点Relay，再发到杭州三线的电信/移动口，这样就可以使杭州三线节点联通口故障时继续提供服务。

除了少数预设规则(如两节点跨ISP的情况下一定需要进行中转)外，WE-CAN中任意两点间的数据是否需要中转，中转路径如何都是根据当前网络状况动态进行路由和调配的。

控制节点

Relay互相之间会进行链路质量探测并向Controller上报。

两个Relay之间如果有直发数据流量(不需要中转)，这些流量报文及其Ack会被用作统计链路质量；对于没有直发流量的Relay-Relay链路，WE-CAN会按照特定模式构造人为的探测流量，并用这些探测流量来统计链路质量；任意一对Relay-Relay间需不需要进行链路质量探测和统计，是由控制节点Controller来决定的。

有些特定的链路是不做探测的，比如电信到联通节点之间因为一定会走中转，所以链路探测没有意义。所以Controller会对Relay的组网/探测策略根据预设配置进行计算并将其下发至Relay。

质量优化

WE-CAN通过中转节点间实时智能路由来提高网内传输质量。

每个WE-CAN中转节点都会定期互相之间进行质量探测，并将探测结果向控制节点汇报。控制节点在收到全网的质量探测信息后会计算出网络全图的最佳路由，然后将路由下发到各中转节点，当两个接入节点之间直连质量较差时他们之间的流量就会经由中转节点进行转发；而“路由”则决定了走哪些中转节点，以及中转节点间的串联关系。

因为每个中转节点的承载能力是有限的，所以在路由时要避免中转节点过载，当某中转节点故障或网络抖动恶化时其流量要均匀地分配到其他中转节点，防止其他中转节点被打爆造成网络雪崩效应；且控制节点收集质量探测信息、计算路由下发是有周期性的，当某中转节点出现网络抖动时路由的切换和规避会有一定滞后性，所以WE-CAN的中转节点会动态地根据当前的探测结果对路由表进行修正来快速响应网络拥塞和节点故障。

总而言之WE-CAN是通过各节点的紧密配合，由控制节点周期性对路由表的更新下发以及接入/中转节点实时对路由表的修正来提高网内传输质量，降低丢包率和延迟的。

WE-CAN在各节点之间还会做报文级别的ARQ(超时重传)和FEC(丢包恢复)来提高传输质量，这种ARQ和FEC策略对传输内容是透明的，因为这些策略会带来额外的带宽消耗，所以其打开与否和打开程度都是可选的。

WE-CAN也可以提供两点间的多路冗余传输，以多倍的传输带宽来提高传输质量，这种策略也是可选的，并且WE-CAN会保证多条冗余传输路径间互不交叠。

成本优化

WE-CAN通过公网传输以及边缘节点下沉来降低网内传输成本。

WE-CAN不依赖专线保证节点间传输质量，而是通过智能实时路由的手段，由普通的公网传输来降低带宽成本；

同时，WE-CAN不使用昂贵的BGP节点或者是三线(多运营商)节点进行接入，也就是说接入节点一般情况下只部署在单线机房(特定运营商)，中转节点才会主要部署在三线机房，这样可以大幅降低带宽成本；

此外，WE-CAN在计算路由时会考虑中转节点的历史峰值带宽，避免在同一计费周期(月)内对不同中转节点造成较高的峰值，在不影响路由质量的前提下将带宽尽量稳定地分配到各中转节点。

WE-CAN支持单个报文向多目的地投递，多播报文的多个目的地接入节点和路径上的中转节点会组织成树状级联结构，通过路径复用来降低流量，在大频道或低延迟直播等场景中，有很好的效果。

边缘接入

接入节点

WE-CAN接入节点在网内传输的角度来看是一个叫Edge的服务，但它其实是由一组服务组成的服务集群(Edge Cluster)：

• Gateway: 负责接收并缓存数据，以及未来可能的各种协议转换，使得下游服务可以进行热插拔升级而不用担心数据丢失；

• Broker: 负责Topic管理，MessageBus可靠传输协议封装等；

• Driver: 负责对数据进行各种处理，包括拆包、组包、重传、排序、Session管理等；

• Edge: 负责管理其他Edge以及Relay的状态；

• Monitor: 负责整个Edge Cluster的监控，包括健康状况、负载状况等。同时会对节点间网内链路质量进行评估和上报；

• ENS-Registrar: 负责Topic的注册和查询，其中ENS(Edge Name Service)是Edge Cluster的一部分，Registrar则是一个中心化服务。

管控平台

WE-CAN管控平台(Dashboard)包含一个Web页面，一个配置数据库和一组API接口，负责对WE-CAN各种资源的配置、监控与管理。

统一调度

统一调度系统通过管控平台的配置数据库获得各边缘节点的静态配置信息，结合由各Edge通过MessageBus上报的动态负载信息，对边缘节点按照预设规则和历史数据反馈进行调度分配。

统一调度系统的长远目标是对云信的所有资源都能够按照通用规则进行管理和分配。

质量优化

WE-CAN通过接入节点的实时智能调度来提高边缘接入质量，并在全球部署足够多的接入节点供调度系统就近分配。

接入节点会将自己的实时负载信息和汇聚信息上报到调度系统。对于每一个接入请求，调度系统会为其分配最优的同运营商接入节点，这样可以保证接入质量，通常情况下，最优的接入节点是地理位置最近或者是同省/同国(未必是直线距离最近)的节点。

在挑选最优节点过程中调度系统会参考汇聚信息，如同一频道的人会尽量分配在同一个服务器上，前提是这个服务器对每个用户来说都比较“接近”。

对于小运营商用户或者海外用户(没有相应的同运营商单线节点)，调度系统会给其分配BGP节点。调度系统会参考历史数据对分配结果进行修正，分为正反馈修正、负反馈修正、静态查表修正三种，小运营商用户在通过修正后也可以接入到单线节点，以避开昂贵且效果未必很好的BGP节点。

成本优化

WE-CAN通过对分配结果的汇聚和对接入节点的梯度选择来降低接入成本。

分配汇聚不但可以提高传输质量(避免节点间的传输)，也可以降低传输成本。离用户最近/效果最好的接入节点可能成本较高，WE-CAN通过对不同的业务模型有选择地分配一些成本较低的节点来降低接入成本，如在低延迟直播场景中，通过牺牲一定的延迟，既可以提高分配汇聚程度，又可以挑选成本较低的节点。

分层解耦

WE-CAN的传输协议是充分分层解耦的，首先与业务解耦，即可以支持各种数据和传输模式，然后 WE-CAN本身提供的各种功能和服务保障也被分为三层来实现，这三层由不同的服务负责，各自使用不同的协议头：

应用层

目前应用层提供了MessageBus的协议封装，包括Topic订阅、消费等机制，未来会根据不同业务场景进行扩展。

传输层

传输层负责Session的管理，报文的排序、重传、切片、重组等，WE-CAN的传输层基于UDP协议自研了一套可靠传输机制。

网络层

网络层负责数据的路由、流量调度、拥塞控制，同时网络层在各转发节点间也会有逐跳的ARQ、FEC及其他冗余策略以提高到达率、降低延迟。

由于WE-CAN对各层协议做了抽象和封装，这样既能使各层独立工作互不影响，提高系统稳定性，又能促进功能的快速迭代，降低开发难度。

彻底的分层抽象也使WE-CAN能够提供更灵活，更多元化的分级服务。比如网络层在软件定义的智能路由网络之外还可以提供专线服务，甚至能在专线和公网之间灵活切换。又比如传输层能提供多种报文重传策略和数据冗余策略等。

5. 结 语

依托于“分层解耦，分级服务，路径复用”等先进的设计理念，WE-CAN成为业内首个独立于业务逻辑的传输基座。

但是网易云信的追求不止于此，作为融合通信云服务专家，网易云信不仅在音视频与即时通讯技术能力层面不断打磨，更是致力于成为全球智能路由网络引领者。

深入地在每一个方向上做到极致，网易云信将以持续的技术创新赋能客户的内生成长，实现价值。

讲师招募 LiveVideoStackCon 2021 北京站

LiveVideoStackCon 2021 北京站（9月3-4日）正在面向社会公开招募讲师，欢迎通过 speaker@livevideostack.com 提交个人及议题资料，无论你的公司大小，title高低，老鸟还是菜鸟，只要你的内容对技术人有帮助，其他都是次要的，我们将会在24小时内给予反馈。

原文链接：https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/117677317?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165918469516781683921818%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=165918469516781683921818&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~times_rank-24-117677317-null-null.article_score_rank_blog&utm_term=%E9%A6%99%E6%B8%AFcdn