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

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

随着 RTC、直播等技术的成熟,更实时、更高质量的通信变得越来越触手可及。结合传统的IM消息等,“融合通信”成了近年来的一个热点领域,而云信则致力于打造业界“融合通信云第一品牌“。想要达到这个目标,通信数据的传输质量是至关重要的,但在长距离、复杂网络条件下保证传输质量一直都是一个难题。并且在追求更高质量的前提下,更低的成本以及更通用、更灵活的架构也是考察一个通信系统是否更优秀的重要指标。

在这些背景下,云信自研的新一代大规模分布式传输网络——WE-CAN(Communications Acceleration Network)诞生了。它不仅可以大大提高端到端的通信质量,降低通信成本,并且能够适用于多种应用场景。

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

  1. 每日传输千亿条消息和数亿分钟媒体流数据;
  2. 在亚太的主要国家都有多个节点,印度、中东、欧洲、北美、北非等地区也都有节点覆盖,中国国内每个省级单位都有大量边缘节点,覆盖全球 200+ 地区;
  3. 在国内音视频传输中做到了超过 99.9% 的网内优质传输率,端到端优质传输率超过 99%;
  4. 跨国通信接近专线质量,全球范围内延迟不超过 250 ms。

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

WE-CAN 的定义

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

WE-CAN 的目标

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

对比同类产品,WE-CAN 的目标是:

  • Faster than CDN
  • Cheaper than SD-WAN
  • More versatile than RTN

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 的目标是提供一个全球部署的分布式消息队列服务。

WE-CAN 的效果

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

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

端到端优质传输率

卡顿率对比

下图是云信 RTC 音频大盘卡顿率在过去 13 天的变化曲线:

云信 RTC 音频卡顿率变化曲线

延迟对比

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

24 小时大盘延迟梯度统计

WE-CAN 的架构

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

  1. 从客户端 A 到其接入的服务器 A’;
  2. 从服务器 A’ 到 B 的服务器 B’;
  3. 从服务器 B’ 最后到客户端 B。

报文从 A 发到 B 过程

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

  1. S2S (Server to Server),就是网内传输;
  2. 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 能够提供更灵活,更多元化的分级服务。比如网络层在软件定义的智能路由网络之外还可以提供专线服务,甚至能在专线和公网之间灵活切换。又比如传输层能提供多种报文重传策略和数据冗余策略等。

结语

依托于“分层解耦,分级服务,路径复用”等先进的设计理念,WE-CAN 成为业内首个独立于业务逻辑的传输基座。但是网易云信的追求不止于此,作为融合通信云服务专家,网易云信不仅在音视频与即时通讯技术能力层面不断打磨,更是致力于成为全球智能路由网络引领者。深入地在每一个方向上做到极致,网易云信将以持续的技术创新赋能客户的内生成长,实现价值。

{{o.name}}


{{m.name}}

原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/tech/pnotes/78421.html

(0)
上一篇 2021年8月12日 06:37
下一篇 2021年8月12日 06:38

相关推荐

发表回复

登录后才能评论