网易云信CTO阙杭宁:如何保障十万不同应用的通讯稳定与实时性

OICQ、QQ、MSN、飞信、iMessaGE、微信，即时通讯从PC时代就开始陪伴着我们。现在以即时通讯为起点的产品仅剩耳熟能详的几个，而更多面向衣食住行的产品也已经具备即时通讯的功能。即时通讯作为一个连接人与人的功能，在各个场景中都不可或缺。近期，在一场演讲上，网易云信CTO阙杭宁就即时通讯云技术难题、云服务不同阶段应该如何解决稳定性问题，以及如何解决百万级聊天室实时性与稳定性风险，分享了自己独到的见解。

即时通讯云平台面临的三座大山

尽管即时通讯早就出现，但此一时彼一时，PC时代与移动时代的即时通讯有着不同的特点。

在网络连接、用户在线状态、流量计费、设备性能、运行环境方面，即时通讯在两个时代都存在差异。

面对移动互联网时代的诸多特点，我们在做一个即时通讯云平台时，要翻越三座大山：第一是连接管理；第二是业务协议满足低流量、低运算环境的特点；第三是能承受高并发。在这个过程中，研发团队会面对四个问题：技术难度大，整体开发和调优周期长，业务细节繁复，以及上线后维护复杂度高。在这次演讲中阙杭宁剖析了四个问题中第一个也是最重要的“技术”难题。

技术角度来讲，作为有16年研发经验的云平台，网易云信已经处于成熟期 。这个阶段的云平台容量大、日常业务量大、增速平缓，所以大客户新接入时对整体容量的冲击并不明显。在这个阶段一个即时通讯云平台需要坚守的决定成败的生命线有两个。首先是数据实时性，比如对全网的网络调度，对弱网环境的数据实时性的优化。另一方面是一些异常调用，比如自循环，特别是一些调用技术较大，终端用户技术较大的应用。如果出现这样的情况，云平台就需要对接入者做好沟通，并对资源竞争做好应对。以下我们分别来详细了解即时通讯在实时性与稳定性两方面存在的问题，以及云信的应对之道。

如何保证即时通讯实时性

首先，对于一个即时通讯云平台来讲稳定性是基础，而实时性则是衡量即时通讯云平台的一个关键指标。

从全网角度看，即时通讯云面对的问题是客户端网络无法由单一的网络入口来满足，包括BGP机房同样无法满足全国或全球区域的覆盖。这是即时通讯云现在面对的主要问题之一。既然单一的入口无法满足复杂庞大的全网的网络要求，那就需要利用更多的入口来覆盖更广的网络。云信的策略是通过选取代理或加速节点这样的服务端网络来替代部分特殊客户网络。

我们可以通过一张拓扑图来理解云信的服务网络入口的网络结构（如下图）。我们将图中的服务入口看作BGP入口，绿色为正常覆盖的区域，黄色是不稳定的节点，红色则是偏远节点或链路。图左侧可能是一些云服务的普遍思路，右侧则是云信目前的策略。针对不稳定的节点，云信会先基于地理位置就近选择网络质量较好的机房，并做服务连接测试和区域网络测试，取其最优节点，然后征收一个代理，把这区域的用户入口分发到代理上。对于红色的节点，云信会下发一组入口，由客户端选择是直连还是做代理，或者是通过LBS选择更好的节点。

在整个过程中，入口会有动态调整。云信会通过上次连接的入口缓存为客户端进行重连，并维持ISP不变。同时，云信还利用类似懒加载的方式，对那些在短期内重复连接和中断计数达到一定量的客户端发起LBS请求。不过在大多数情况下，由于手机运营商、家庭Wi-Fi都可以维持稳定连接，只有在服务节点出现增加、服务负载出现变动的时候，才会通过这套方法来保障实时性。

再从弱网角度看，连接的中断、续连、切换比较频繁，如何快速地重建连接，如何将信息尽快追加上去，这也是即时通讯云现在面对的主要问题之一。针对这个问题，云信优化了连接探活和重连效率，特别是针对Android系统，云信Android架构师曾。与此同时，云信还会精简数据包，以减少数据包在弱网下重传的量，提高对弱网的支持。

“延迟0容忍”的实时互动音视频

IM、实时音视频与聊天室是即时通讯云的三个主要业务，三者对实时性最敏感。

在实时音视频的场景下，用户普遍认为对话双方距离近，应该延迟更低。但事实是，两者距离圆的，网络传输距离一定比较远，传输速度相对慢。但两者物理距离近，网络距离却不一定近，同一个屋檐下的对话有可能是从数据中心绕了一圈才传到另一人的面前。

从网易云信的经验来讲，在做实时互动业务架构时就定下了一个目标，尽量让实际的调度走直线，缩短整个传输距离，并提供多通路，可以根据客户端之间的网络测探情况来择优分配。

在调度调优方面，阙杭宁透露了云信的方法。他们以用户IP、用户ISP、全国ISP和位置到各地机房的数据作为调度引子，利用分配算法“rate=DIStance*prioity*rand/isp”进行动态调整。也就是距离和集群优先级以及一个随机因子，反比的因子就是ISP，以ISP为主要维度，同时去参考双方之间的距离来选择具体实际物理机房的位置，再根据其业务优先级和随机因子算出一组结果，取头几名汇报给客户端，由客户端进行网络探测，再择优录取。

不过实时音视频面对的并不只是距离带来的问题，还有网络条件带来的差异。在Wi-Fi下，我们可以根据网络承载情况来传输码率较高、质量较高的数据。但是在4G、3G，甚至2G网络下，码率就需要降低。为了保障实时性，云服务需要对不同机型、网络来做不同的参数预案，比如抗抖动算法和动态码率。云信自研了一套抗抖算法，融合了pjsip和webrtc的neteq算法，并投入了大量的测试做参数校准，目前可以做到800毫秒左右的抗抖效果。除了抗抖算法，云信为了提高对弱网环境的支持，将数据包进行了精简，以减少数据包重复传输的量。

如何支撑无上限聊天室海量实时信息

目前很多云服务平台都开始支持实时直播聊天室，甚至也有以此为起点的创业公司。网易云信不仅支持此业务场景，还可以支撑无人数上限聊天室。

聊天室的特点在于，一万人的聊天室，它的消息量绝对会放大数倍，而且里面除了有效信息，还会包含点赞、礼物，甚至是大量无效的消息。在架构上主要要解决的是组播性能。云信的经验是，在架构上采用分布式并行架构，可以横向无损扩展。在性能方面，云平台要减少消息放大中间环节的数据量。阙杭宁分享了他们的聊天室业务多层架构（如下图），分为客户端层、网关接入层、路由层、业务层。

在客户端层，SDK可以做多平台适配、移动弱网优化，在重连效率方面，也可以保存一些相关连接授权信息来提高重连速度。云信曾在MDCC上详细分享过弱网优化的经验。云信还可以在出传输层上做安全加密、压缩和拆解包、数据包分包等。在网关接入层，它的重点是做长连接的管理、优化，以及广播分包，让升级和跨网络切换更加平滑。在路由层，云信支持服务化的后端，负责接收网关层发来的请求。路由层可以根据热更新策略划分集群入口，还能实现横向扩展。到了业务层，微服务架构提供了高可用、弹性伸缩的整体扩容、横向扩展。

保持云平台稳定性的应对之策

除了实时性，稳定性是即时通讯云平台的另一个需要坚守的“生命线”。

阙杭宁分享了一个例子。云信平台上有很多App，有些App的一夜爆红或大型在线活动，都可能带来容量上的剧烈抖动。

用户的异常调用通常会给云平台带来资源侵略，同平台上的其它应用会收到影响。这时候考验的是云平台的扩容策略与架构的灵活性。那么应该以什么策略来

减少异常调用给其它应用带来的干扰呢？

云信有两个应对措施：快速扩容与单元化服务。快速扩容有两个关键，第一是扩容的时机，第二是环境准备与服务部署。在触发扩容之前，需要观察子服务的集群容量和水位，水位上升和容积紧张可能只是一时的抖动，但如果这时出现任务积压，那么生产速度远大于消费速度，这就是需要扩容的时候。第二方面之所以说是环境准备和服务部署，为的是提高扩容的速度。由于云信是搭建在网易蜂巢Docker之上，云信团队在运行环境的构建上面，通过蜂巢的API可以很快实现创建。

第二个措施，单元化服务。网易云信的单元化服务也叫单元化服务域，它本身就是基于微服务架构的。以消息服务为例，可以将它拆分为A域的消息服务和B域的消息服务，在一个域中不是只有IM一个功能，它是通过一些排列组合，包括一些规格容量的定义，让它变得有实际业务意义。开发者会在各自的服务域里面享受到底层数据层，且互相隔离。服务域可以在发生抖动的时候将异常应用切入独立的域，从而保证它不会给其它应用带来影响。在刚刚的案例中，云信就采用了相同的策略。

阙杭宁认为做即时通讯云服务需要从客户的终端去理解即时通讯的场景，再进行API的设计和后续的教程引导。从他分享的案例可以看出，云服务要做的不是为了避免太多资源冲突而给客户的业务行为太多条条框框，而是利用灵活的架构和调优手段来应对接入者的需求，甚至是突发的非常规调用。

即时通讯已经成为很多产品的标配功能，而实时互动直播更有可能在未来成为内容类、娱乐类、协作类产品的必备能力。以优化连接探活、精简数据包、自研抗抖算法等策略应对即时通讯的实时性挑战，用灵活的分钟级扩容、单元化服务来保障即时通讯的稳定性，一个即时通讯云服务只有在底层有这样一套成熟的架构与危机应对机制，才有可能承受住未来十万甚至百万级海量用户数据的考验。