网易云信自研大规模传输网核心系统架构剖析

Posted 2021-12-15 LiveVideoStack_

随着边缘计算及RTC技术的兴起，业务服务器的边缘化可以带来大量收益：一方面就近接入可以优化客户端上下行质量，另一方面边缘节点可以大幅降低带宽成本。但如何保证相隔千山万水的边缘服务器之间的网络传输质量成了一个难题。本次LiveVideoStackCon 2021北京站，我们邀请到了网易云信服务端首席架构师——吉奇通过分析网易云信自研大规模分布式传输网（WE-CAN）核心系统的架构对上述问题进行了深入探讨。

文 | 吉奇

整理 | LiveVideoStack

大家好，我是吉奇，来自网易云信，今天演讲的主题是网易云信自研大规模传输网核心系统架构剖析。

首先自我介绍一下，我目前在网易云信做服务端架构，原来在美国工作过一段时间，回国之后接触到RTC和通信行业。我本身的经历是一直在做服务端，在分布式后台、网络传输，包括高并发、传输协议等领域都有一定的经验。

1. 云信介绍

云信是网易集24年IM以及音视频技术打造的融合通信云服务专家，稳定易用的通信与视频PaaS平台。相信大部分同行对云信的IM能力应该是很熟悉，其实我们的音视频技术也有很多的积累，最近也有很好的发展。包括现在我们结合网易易盾也有了很多安全方面的一些独到的方案，我们立志要做全行业最好的融合通信PaaS平台。最近我们网易云信也被纳入Gartner 2021年《CPaaS 市场指南》研究报告，还是有很不错的进展的。

2. 项目介绍

我们这个WE-CAN项目是云信自研的传输基座，承担的是网易云信所有业务层需要通信的流量传输的一个大型传输网络。

目前WE-CAN在全球所有主要地区都已经实现节点部署，在国内的话，我们在每一个省份的ISP都有节点，比如你在中国任意一个省份，不管电信、联通还是移动，都可以就近接到一个与你这个ISP匹配的同省的机房。在国外的话，所有大洲都有节点，在东南亚的主要国家，像新兴市场，一些主要的出海目标国家，每一个国家都有可能不止一个节点来做本地覆盖。

WE-CAN作为云信的通用传输基座，它本身是完全独立于业务的，是完全独立的一个通用传输网络。本次分享主要是从网络分层的角度去剖析WE-CAN的架构，因为WE-CAN是一个非常复杂的系统，它有很多的核心组件和边缘辅助组件。所以本次分享不采取分解服务或者部署架构的角度，而是用这样一个比较抽象的网络分层的角度去讲解，会比较易于理解和抓住WE-CAN的关键设计决策。

3. WE-CAN网络分层

这是WE-CAN的一个分层架构，大家可以看一下。

我把WE-CAN分成了这么几层，核心的当然是网络层、传输层和应用层了，某种程度上对应传统的互联网模型的三层。当然不是严格对照。

在分层架构最底下是基建层，基建层都是我们网易自研或者说云信自研的一些基础平台。包括数据平台、管控平台即我们WE-CAN的内部Dashboard、我们自研的一个全球的分布式的缓存系统即所谓存储平台，还有配置平台。

基建层往上的控制层其实和网络层结合非常紧密，可以看到接入、转发、调度和路由这四块是WE-CAN最核心的模块。再上面的传输层主要是一个协议层，网络层和控制层是做路由的，那么传输层就是做QoS和各种各样的策略层。

最上面的应用层是对传输层和网络层能力的封装，做了很多比较抽象的基础服务。业务层是实际各个业务场景中对应用层能力的使用。

4. 为什么要强调网络分层

那么为什么要强调网络分层呢？首先WE-CAN本身就是一个overlay，它本身就是基于公共互联网上的一层。然后网络分层做得好，我认为可以做到各个系统模块各司其职，系统边界比较清晰，并且其实各层有各自不同的传输优化策略，这个后面会展开讲。比如网络层和传输层的优化策略是不一样的，可以做的事情不一样，甚至同样的优化策略如ARQ，在网络层和传输层的实现方式也是不一样的，网络层策略都是转发节点间逐跳的，传输层是接入节点到接入节点之间的。

最后网络分层和解耦做得好，可以支持更多的传输场景。WE-CAN不只是要支持实时音视频通信、低延迟媒体流传输，我们是要做一个通用的传输加速网络，所以分层做得好可以把各层的能力抽象剥离，就可以支持更多的传输场景。

5. 目录

这个是我要讲的顺序，跟刚才的分层顺序有一点调整，把网络层放在前面，控制层放在后面，这样更有利于理解。

6. 网络层

网络层是WE-CAN核心网的入口，WE-CAN的节点数量比较多，报文从边缘节点出来后就直接进入网络层了。

网络层的功能主要就是报文的寻址路由，它会将一个报文从它的上行接入节点投递到目的地下行接入节点去，这是WE-CAN最核心最基础的能力，所以它是架构最复杂、流程最长的一层。

网络层是基于公共互联网提供优质传输能力的。为什么要强调公共互联网这几个字呢？因为这个是我们WE-CAN“软件定义”的特点，意思是我们走的是公网流量，通过软件路由来保障传输质量，在绝大部分场景下我们都用不到专线，在传输层面我们不需要建设大型的中心机房和专门的骨干线路，这些大型基建的建设周期很长并且成本是很高的。

6.1接入

网络层可以分为两部分，一个是接入，一个是转发。

首先在接入部分我们对比一下两个常见的接入方案，接入节点又叫登录节点或者边缘节点。WE-CAN做的一个主要的事情是节点的边缘化。在云信采用WE-CAN之前，我们的节点是比较典型的那种大型中心机房，比如在国内我们主要有北京、杭州、广州以及中西部贵州节点，在海外全球有少数的那么几个数据中心。这些数据中心规模比较大，并且建设周期比较长，投入比较大。在这种少数中心机房的情况下调度策略很简单，基本上就是看看哪个节点离用户相对较近，这样做的问题是很多情况下用户还是会远程接入，比较依赖节点本身的网络质量。但最大的问题是因为要覆盖广地域的各种用户，所以中心节点一般来说都是采用的BGP资源，BGP资源的带宽成本是非常贵的，跟单线的边缘节点比是数量级上的差距。BGP资源可能要大几十，一两百块钱一兆，单线资源的话便宜的可能就几块钱一兆，这个差距是非常大的。

所以WE-CAN的思路是节点边缘化，首先我们都是比较小型的节点，就像我刚刚说的，我们的节点覆盖是非常全面的，比如在全国每一个省份都有覆盖，海外我们目前最重点的区域东南亚每一个国家都有覆盖。要做到这一点，我们每个节点的规模是不大的，这样的好处是灵活易于调整，实际上节点的规模小不是坏事，其实是好事。因为我们内部有一个赛马机制，我们对节点有一套运营机制，如果某个节点的网络质量不好，当我们跟供应商沟通无效，查问题也查不出来，那我们可以直接把它换掉。我们会有一批储备的资源，实时观察，质量不好了就淘汰，质量好的就会提高优先级或者扩容。

然后在拥有大量的边缘节点之后，就可以做精细的调度优化，可以给用户分配更适合的节点，这样的话就能够做到真正的就近接入，提高Last-mile质量，降低上下行延迟。

最后正因为我们通过WE-CAN大网组织起了各地的边缘节点，我们才可以挑选成本最低的单线静态带宽资源，大大降低上下行带宽成本。

6.2 转发

---

当流量通过接入节点进入WE-CAN网络之后，就来到了我们的转发网络了。

转发网络是WE-CAN真正的核心。我们的转发网络是由中转节点组成full-mesh网络，是一个软件定义的实时智能路由网络。我们的中转节点会探测互相之间的网络质量，然后由控制节点通过数据平台收集到实时的探测网络质量，计算出各个节点之间的路由表，并把路由表下发到各个中转节点。最终由中转节点根据路由表对报文进行转发。

转发网络的原理、模型非常简单，各家的实现都大同小异。但是WE-CAN做了很多独到的优化，比如我们在路由的时候计算的是Top K的最短路径，不只是最佳路由。在转发节点会对这Top K的每一条路径实时维护一个动态的权重分值，也就是说报文在决定下一跳往哪走时不一定会去路由算法决定的最短的那条。完全依赖最短路径的话问题是当网络有抖动的时候，路由切换传输恢复时间较长。正常情况下如果网络有抖动或者节点之间的网络有拥塞，这个拥塞情况会由节点之间的质量探测机制感知到，质量探测结果通过数据链路反馈到控制节点，控制节点更新完路由表下发到中转节点，才会把这个有问题的“前最短路径”切走。但是这个流程比较长，导致所有经过拥塞节点中转的路由都会出现抖动。

为了解决这种问题，我们的边缘节点现在对路由表本身是有一定的调整能力的，它可以根据当前的网络反馈情况去对这个Top K路径去做动态调整。这种动态调整使得对于丢失的报文，在网络拥塞情况下，在重传的时候可以选一个不一样的路径，也许是次优路径，但如果不做这种避免，那重传报文很有可能还是丢了。并且这些选择次优路径的决策又会动态影响接下来新的报文对路径的选择。

WE-CAN的转发网络另一个投入较大、做了深度优化的地方是在多目的地的多播场景下，路由的时候会自动组成树状级联，对中转路径尽可能复用。这在大频道或者直播的场景下有很好的应用，当频道比较大，用户分布比较广，接入服务器跨度大数量多的时候，上行的媒体流往外扩散的度会比较大。WE-CAN通过树状级联一是可以最大化路径复用以降低带宽成本，二是可以优化传输质量，降低每个节点的流量扩散使得节点间可以有余地做冗余策略，当然最根本的一点是树状级联消除了上行节点的出度限制，使得超大频道成为可能。

另外，如果组成一个级联的转发树，那么越上游靠近树根的节点发生故障，影响越大。而WE-CAN的树状级联结构是各个中转节点自动生成的，对于任何一个节点的故障的规避和恢复是非常及时的。

7. 控制层

讲了网络层，下面是控制层。控制层其实就是控制网络层工作的，在传统的CDN或者SDN里就是所谓的控制面，其他都是数据面。

控制层分为两部分，一个是路由，一个是调度。在我跟别人解释WE-CAN的时候常常把它比作一个数据的高速公路，上面有很多节点，路由做的事情是我们组织一个高速公路，把流量从高速路网的任何一个节点快速地投递到任意另外的一个节点。这里所谓的节点是WE-CAN内部的节点。所以路由解决的是网内传输质量，提高网内传输的到达率，降低延迟。

调度系统的角度不同，它解决的是上下行Last-mile的质量问题，类比高速公路路网，调度的任务是为你找到一个距离最近，能够最快上高速的入口或说高速公路收费站。因为Last-mile质量相对来说是比较难解决的一个问题，我们对Last-mile的控制力度和可以做的事情相对网内传输要少一些，所以调度质量也是我们极为关注的一个方面。

7.1 调度

---

WE-CAN的边缘节点调度技术我把它分为两大类，静态调度和动态调度，这个名字是我自己取的，不是标准术语，那么什么是动静态调度，什么是动态调度呢？它的区别就是静态调度是传统的查表调度，有一个静态的IP库，当然这个IP库是经常更新的，每天更新，但总体来说还是比较固定的。基本原理是通过查找这个静态IP库，对于每一个调度请求，我们能获得用户的相对准确的地理位置，并分配一个同ISP的情况下地理距离最近的一个节点。当然我们并不总是单纯地做直线距离就近分配，在实际情况下，我们会优先考虑用户的区域归属，尤其在一些省份的边界或者国家交界处。比如国内我们希望用户到同一个省份的节点去，不一定是最近。在海外不一定有这么细粒度但希望用户起码可以去同国的节点，也不一定是最近的。但总体来说所谓静态调度原理是通过查找静态的IP库，就近分配。

动态调度是跟静态调度相对的，它查找的是动态IP库。动态IP库的核心在于它不是预先生成好的，而是依托我们的业务数据，对实时和历史数据进行分析和汇聚，来产生一个我们认为对用户来说最优的选择。

动态调度系统会根据用户历史数据，汇聚成各个维度的质量指标，比如说登录的成功率，信令连通情况，音视频的卡顿率等等。同时WE-CAN也会针对每一个客户端产生一个探测列表，客户端会主动地对这些接入节点做网络探测并上报。根据这些数据的汇聚结果，动态调度系统会产生出调度黑名单和白名单，黑名单就是根据数据分析发现某些客户端IP地址到某些机房质量持续不好，那就避免分配这些机房给这个客户端，即使它是距离最近的。白名单就是根据历史数据，尤其是探测数据判断客户端到某些节点质量很好，那WE-CAN就优先让这个用户去那些机房。

动态调度首先可以大大提高接入质量，最终提升端到端质量，另外有一个好处就是小运营商用户可以不用再固定去一批预留的BGP节点了。因为我们的边缘节点都是单线静态带宽，所以需要在各地保留少量的BGP节点去覆盖小运营商用户，而在动态调度系统中，对于小运营商用户我们会下发任务让他们去和附近的单线节点进行网络探测。因为小运营商一般来说跟大运营商都有一些亲缘关系，如果比如探测结果表明某些用户连电信的服务器质量好，那调度的时候就会让这个用户分配到这个电信的节点去，这样不但可以提高小运营商用户的接入质量，也可以降低BGP带宽消耗。

因为通过数据实时计算产生的IP库我认为它是动态的，所以叫动态调度。这是调度的两个大的模块，调度系统的架构我会在后面再深入讲。

7.2 路由

---

调度是解决Last-mile接入的问题，路由就是解决网内传输的质量问题了，它体现的是控制层对于中转节点的控制。

首先中转节点负责探测节点间网络质量，并上报到数据平台。经过数据平台的原因是一方面可以借助数据平台的计算汇聚能力来辅助路由表生成，另外这些路由原始数据存下来之后可以对它做各种展示和分析。

然后WE-CAN的路由计算是中心化的，也就是说路由表的计算完全是由中心控制节点完成的。为什么不能像比如说BGP协议一样去中心化地计算路由表呢？是因为在WE-CAN这个大型的传输网络里有一个很关键的核心问题就是流量的管控问题或者说是流量分配的问题。如果去中心化地计算路由表，网络是没有办法对全局的流量进行管控和分配的。

如果缺乏全局流量管控，首先很多成本优化就没办法做，并且最严重的一个问题是在节点故障路由表切换的时候，尤其是一些流量比较高的重要中转节点网络出现抖动的时候，在重新计算路由表的时候网络自然要绕开这个中转节点，把它上面的现有流量切到别的节点上去。在这个情况下很多流量网网会跑去另一个“次优节点”，如果网络缺乏总体流量管控，这个次优节点很快就会被瞬时流量突增打爆，就会引发雪崩效应进而引起全网大规模故障。而且不只是故障处理方面，在日常运行的情况下，我们也希望能够控制各个节点的流量在相对比较平稳，比较均匀的水平线上。

当然成本优化也是很重要的一个因素，不同的中转节点的带宽成本是不一样的，我们希望通过流量分配来避免流量尖峰，并且对不同的业务场景和服务分级来使用不同的节点带宽。

8. 传输层

讲完了网络层和控制层，接下来是传输层。如果说网络层是WE-CAN架构最复杂、流程最长的一层，传输层就是WE-CAN协议、代码最复杂的一层。

传输层是基于网络层的路由和转发的能力，为了服务更复杂的应用场景，对网络层做了很多协议、传输场景上的适配。其中最主要的是我们基于UDP协议自研了一套可靠传输协议，包括重传、排序等等。

相对于网络层原始UDP协议，传输层还有很多其他功能，比如说它对UDP MTU的限制进行了扩充，对大报文进行切片，对小报文聚合发送。对小报文聚合发送，一个是提高效率，降低报文overhead，另一个方面是我们在做FEC的时候希望能把报文尽量对齐，尽量靠齐到接近MTU的大小，这样可以降低FEC冗余报文的开销。

另外传输层还负责流量控制、熔断限流等，传输层还有一个重要的作用就是要提供各种提供分级服务策略，提供各种冗余传输能力。传输层的协议是非常复杂的，它有各种力度的冗余传输和QoS的能力和策略。

8.1 协议

---

这里大概示意一下传输层协议的各个字段，图上列举的是最主要的一些字段，我们的传输层协议是一个很复杂的二进制协议，和互联网分层一样，WE-CAN传输层有一个传输层的报头，网络层有网络层的报头，网络层的报头相对比较简单，所以就没有展开讲。

传输层协议字段主要有三类，标识字段、寻址字段、策略字段。首先我们每一个报文会有一个唯一的标识，一方面是为了用来做问题调查，报文的链路跟踪。另一方面标识字段本身有一些功能，比如序列号是用来做排序的，分段号是用来做切片的，其他比如做报文聚合的时候，还有聚合号等。

寻址严格意义上讲不是传输层的事情，主要是在网络层实现的。WE-CAN协议里传输层和网络层在寻址上面的区别是：网络层负责把报文从网络的一个节点传输到另外一个节点，核心是路由。而传输层的寻址字段充当的功能有点像端口，到了目的地节点之后我用传输层所带的信息把报文分发给每个实际的客户端或者说实际的服务器。因为WE-CAN的定位是一个通用的传输服务，它不只是为云信RTC或者IM做传输。

策略字段相对最复杂，首先我们的报文会有优先级，不同的优先级会有不同的FEC策略，不同的重传策略，不同的冗余策略，它是一个综合的字段，很多其他的策略都会参考优先级字段的赋值。另外每种其他策略都会有单独的开关，比如我们会有多路冗余策略，典型场景是在重要会议的音频可以发两路，这两路我们要保证它路径不重合，这些都是由传输层透给网络层来保证的。另外还有重传次数、重传等待时间等等。

之前提到过网络层和传输层对提高网内传输质量有不同的做法，比如说网络层和传输层的重传是不同的。对于网络层来说，中转节点到中转节点之间它是有逐跳的重传的，而传输层有传输层的重传，也就是说WE-CAN的两个接入节点之间也有自己的ARQ。然后网络层会有逐跳的FEC，因为逐跳做FEC会比较灵活，比在两个接入节点之间做效率更高。

9. 应用层

下面是讲应用层，应用层是对传输层的协议能力的一个封装，目前最主要的一个应用叫Message Bus。

9.1 Message Bus

Message Bus是一个通用的消息服务，它是对传输层可靠传输协议的一个封装，在消息传输之外提供了一套Topic自动订阅、管理的机制。

Message Bus你可以认为它是一个全球部署的一个分布式的跨地域的消息队列系统，类似分布式的Kafka。所以除了传输之外，它还有状态管理的能力。另外Message Bus的消息投递支持广播的形式，也支持Round Robin的形式，由Message Bus负责轮询和链接状态管理。

Message Bus由WE-CAN核心网络来保证传输的可靠性，目前它最主要的业务场景之一就是承载了RTC服务端的信令。

这个是Message Bus的架构图，画得很简单，因为Message Bus最主要的复杂度是在协议上面。

它的架构中最复杂的是上面这个Topic管理的模块，这是我之前提到的基建层里面的存储平台，是我们全球分布式的一个缓存系统，会做跨大洲的状态同步和缓存，来保证Topic状态同步的一致性和及时性。

消息服务的传输保证跟媒体是不一样的，首先消息需要保证有序到达，另外要保证一定程度上的可靠，在实在无法投递时也要能明确告知发送端投递失败。

9.2 HTTP Proxy

---

在Message Bus之上我们封装了另一个服务叫HTTP Proxy。HTTP Proxy的用意是简单易用，对业务代码侵入性小，比如说REST API要加速，就可以直接上HTTP Proxy，开发工作量非常小。

架构也比较简单，从客户端直接调用我们这个Proxy Server，通过Message Bus，利用WE-CAN的传输能力，到目的地的Proxy Server，目的地的Proxy Server可以帮你去做HTTP调用，最后把结果通过Message Bus再回传过来，在调用发起方HTTP Proxy转换成HTTP Response。

时序图里，我们有个比较特别的地方是在做HTTP代替的时候，要把目的地的URL放在请求里面，没有用标准HTTP代理的形式，因为HTTPS如果用标准协议代理的话，握手信息也需要来来回回传输，在跨大洲的情况下延迟会比较高。所以我们用了这种形式，HTTPS的握手跟我们的代理服务器去做，到了目的地代理服务器再去和实际的资源做握手，可以降低延迟。

9.3 统一调度

---

另外一个非常重要的应用层的系统叫统一调度，这个其实就是我们整个调度系统的一个外在表现，是一个高度抽象的通用调度服务。为什么要强调“高度抽象”、“通用”呢？是因为WE-CAN能支持很多的应用场景，有很多的下游的业务系统都在用WE-CAN，每一个场景、每一个应用都要用到我们的调度服务。对于业务应用来说，如果接了WE-CAN，那必然要给最终用户选择一个接入节点。

统一调度系统是与实际业务的调度逻辑解耦的，因为实际业务的调度中不一定只是要给用户找一个最好的节点去接入，往往各个业务有自己的附加要求和各种其他业务逻辑。WE-CAN的统一调度系统就提供了一种纯粹的，保证调度质量的服务，在此之上我们通过管控平台提供了多个维度的定制能力，尽最大可能满足各个业务方的调度需求。实际上在实现中业务方会在统一调度系统之上再加一个业务调度系统，对WE-CAN调度结果再做一次封装，这样可以在我们挑选出来的结果之上再去使用自己的业务逻辑和各种各样的限制。

统一调度系统在选择最优节点的同时会进行负载均衡，调度系统另一个重要的概念是资源汇聚，在RTC中就是频道汇聚。比如在音视频通话中如果同一个房间里有一个江苏移动和一个浙江移动的用户，我们可能就不希望江苏人接到江苏移动机房去，浙江人接到浙江移动机房去，而是希望他们汇聚到同一个机房。这样一来可以降低转发带宽成本，另一方面落到最终端到端传输质量上往往是有提高的。

统一调度的架构非常复杂，图上只是其中的一部分，它封装了WE-CAN的各种各样的能力。首先Message Bus会去帮它做各个节点的负载的收集，客户端会报它自己的负载，我们叫它custom load，接入节点又会观察收集机器的一些资源使用情况，比如内存、CPU、网络等。这些信息会通过Message Bus发到统一调度系统的控制模块去。控制模块对外提供一个RESTful接口，它本身是一个信息收集汇总的模块，WE-CAN基建层的配置平台，IP库等信息都会汇总到控制模块去，对于每一次调度请求它都会去调用策略模块，由策略模块计算调度的结果。

动态调度系统是通过数据平台的数据通过汇聚、计算，最后把动态IP表更新到策略模块去。我们会优先考虑使用动态IP表，然后用静态IP库做兜底，因为实际上不一定有这个用户的历史数据，所以很多情况下还是要有传统的基于地理位置的就近接入来做兜底。

架构图里没画上去的一个重要模块是我之前提到过的资源汇聚系统。

在应用层还有许多其他的服务，比如说我们有一个全球的时钟同步系统，它是基于WE-CAN的大量节点和中转传输的能力来搭建的，这个系统会保证所有的服务器之间的时钟是能以非常高的进度来达到一致，最终可以同步给客户端，以及一些其他的应用服务系统。

10. 业务层

10.1 RTC

下面来说一下我们具体的业务应用，最主要的肯定是RTC了，我们云信的实时音视频服务。

对于RTC来说，首先WE-CAN最大的好处是可以提高端到端的传输质量，因为用户就近接入了，而网内传输又相对可控。尤其是WE-CAN可以大大优化远距离特别是跨国通话质量，在云信的出海业务中，海外跨国通话或者海外回国等场景下，利用WE-CAN的传输服务就不需要再拉专线或者是用专门的代理加速来保证通话质量，WE-CAN可以保证从全球的任意一个地方到另外任一个地方的通信质量。

另外RTC用 WE-CAN可以大幅降低节点带宽成本。从BGP机房或者三线机房替换为单线机房，带宽成本是数量级上的一个降低。

这是简化的RTC接入WE-CAN的架构图，大家可以看到有两个不同颜色的箭头表示，下面是媒体服务器之间直接互相级联，通过WebRTC各种协议直接进行通信。而接入WE-CAN之后WE-CAN的接入节点跟媒体服务器之间是同机部署的，媒体流通过IPC进入接入节点，然后由WE-CAN负责投递到目的地接入节点去。

10.2 IM

这是IM接入WE-CAN的架构，云信的IM有很长的历史了，并且市场对我们的认可度很高，我们的IM系统也很成熟，WE-CAN给IM的架构带来了很大的改变。

原来我们跟大部分IM系统一样，是相对比较中心化的架构，因为IM有大量的状态需要存储。而有了WE-CAN之后我们做了一个很重要的改造，就是长链接服务器前置部署。长链接服务器就是登录服务器或者叫边缘服务器、接入服务器，客户端SDK是直接登陆在这个服务器上的，消息最终是通过这个长链接服务器来推给客户端的。

WE-CAN首先可以改善IM上下行的接入质量，这是一个很明显的优势，还有一个重要的好处是广播消息的下推。也就是说我们IM数据中心产生的消息不再由数据中心的中心节点去广播或者说扩散给各个客户端了，我们先扩散到相关的边缘服务器，边缘服务器再扩散到客户端，相当于天然有了一个两层的树状级联模式。这种模式有很多的优势，比如说我们实际遇到过的一个场景，某个跨国的大频道，国内的消息要发给海外的用户的话，如果没有WE-CAN，首先肯定是要走专线加速，专线加速本身就带宽有限而且很昂贵。而且如果消息有一万个人要接收，你就得重复跨国发一万份。现在有了WE-CAN之后，首先不再需要专线了，WE-CAN会帮保证跨国传输质量，然后这个消息只用跨国发一份，利用WE-CAN发到海外接入节点再去做本地扩散。这对于降低中心机房的带宽压力和提升消息的水平扩展能力有本质的、巨大的改变。

为什么说降低中心机房带宽压力能够提升的水平扩展能力的同时还能够降低成本？因为中心机房的成本一般比较高，比如它一般都是BGP节点，而海外的边缘节点的公网带宽成本是很低的。

10.3 直播点播

---

下一个应用是直播点播，云信现在可以提供低延迟直播服务，这是一个现在比较火的能力。在一些对互动要求比较高的场景下，我们会通过WE-CAN来代替传统的CDN做音视频的分发，这样最大的好处就是延迟低了，并且通过WE-CAN的各种节约成本的手段，我们可以接近传统CDN的价格。

图上的全局智能融合调度不是WE-CAN的调度，它决定的是比如一个直播的房间是走WE-CAN还是走传统CDN 或者是走哪个CDN的选择。

10.4 数据上报

---

还有一个应用是数据上报，大家往往会比较忽略数据上报质量，但数据上报其实是走WE-CAN的一个很好的应用场景，尤其是当业务出海的时候。因为无论你的用户分布在哪，一些监控和打点数据，包括质量数据和事件上报的存储中心一般都会集中在一个地方，在跨国的情况下这些数据的上报成功率是没有办法保证的。而接了WE-CAN数据可以先报给分布在边缘接入节点上的数据收集服务，再由WE-CAN传给数据中心集群。这样一来可以显著提高数据上报成功率和及时性，二来我们边缘节点本身在传输层做了报文的缓存，缓存时长可以由具体业务调整，这样在数据中心不可用，或者在维护的时候WE-CAN可以将数据缓存一段时间，等数据中心恢复服务的时候再通过流控慢慢发过去。

当然这里所说的数据不涉及到个人信息，单纯地只是一些质量数据，比如说丢包率、卡顿率和一些事件统计等。

目前主要的业务层的应用都讲完了，还有一些比如互动白板等没有在这里展开。

可以看到，这些架构图里都缺失了一个重要的东西——调度。实际上所有的应用都是要用到我们的统一调度系统的，没画上去是因为篇幅有限，但是WE-CAN的所有接入节点的选择和调度都是由我们的统一调度系统来完成的。

今天的演讲和分享就到这里，谢谢大家！