音视频通话:小议音频处理与压缩技术

在视频或者音频通话过程中,一方面为了减小原始声音数据的传输码率,需要进行音频压缩,另一方面为了得到更高质量的音质,需要进行音频处理。那么,如何处理好这两方面,保证声音传播的高真性?本篇文章将会结合网易云信在音视频技术方面的实战和经验,小议音频处理与压缩技术。   推荐阅读: 《视频私有云实战:基于Docker构建点播私有云平台》 《高清音质背后:网易云信音乐教学方案技术解密》   音频处理的方法主要包括:音频降噪、自动增益控制、回声抑制、静音检测和生成舒适噪声,主要的应用场景是视频或者音频通话领域。音频压缩包括各种音频编码标准,涵盖ITU制定的电信领域音频压缩标准(G.7xx系列)和微软、Google、苹果、杜比等公司制定的互联网领域的音频压缩标准。(iLBC、SILK、OPUS、AAC、AC3等)。   音频基础概念 在进一步了解音频处理和压缩之前需要知道这些: (1)音调:泛指声音的频率信息,人耳的主观感受为声音的低沉(低音)或者尖锐(高音)。 (2)响度:声音的强弱。 (3)采样率:声音信息在由模拟信号转化为数字信号过程中的精确程度,采样率越高,声音信息保留的越多。 (4)采样精度:声音信息在由模拟信号转化为数字信号过程中,表示每一个采样点所需要的字节数,一般为16bit(双字节)表示一个采样点。 (5)声道数:相关的几路声音数量,常见的如单声道、双声道、5.1声道。 (6)音频帧长:音频处理或者压缩所操作的一段音频信息,常见的是10ms,20ms,30ms。   音频处理基础 噪声抑制(Noise Suppression) 手机等设备采集的原始声音往往包含了背景噪声,影响听众的主观体验,降低音频压缩效率。以Google著名的开源框架WebRTC为例,我们对其中的噪声抑制算法进行严谨的测试,发现该算法可以对白噪声和有色噪声进行良好的抑制。满足视频或者语音通话的要求。 其他常见的噪声抑制算法如开源项目Speex包含的噪声抑制算法,也有较好的效果,该算法适用范围较WebRTC的噪声抑制算法更加广泛,可以在任意采样率下使用。 回声消除(Acoustic EchoCanceller) 在视频或者音频通话过程中,本地的声音传输到对端播放之后,声音会被对端的麦克风采集,混合着对端人声一起传输到本地播放,这样本地播放的声音包含了本地原来采集的声音,造成主观感觉听到了自己的回声。 回声产生的原理如下图所示: 以WebRTC为例,其中的回声抑制模块建议移动设备采用运算量较小的AECM算法,该算法的处理步骤如下图所示。有兴趣的读者可以参考AECM的源代码进行研究,这里不展开介绍了。 自动增益控制(Auto Gain Control) 手机等设备采集的音频数据往往有时候响度偏高,有时候响度偏低,造成声音忽大忽小,影响听众的主观感受。自动增益控制算法根据预先配置的参数对输入声音进行正向/负向调节,使得输出的声音适宜人耳的主观感受。 以WebRTC为例,它的自动增益控制算法的基本流程图如下所示。 静音检测(Voice ActivityDetection) 静音检测的基本原理:计算音频的功率谱密度,如果功率谱密度小于阈值则认为是静音,否则认为是声音。静音检测广泛应用于音频编码、AGC、AECM等。 舒适噪声产生(ComfortableNoiseGeneration) 舒适噪声产生的基本原理:根据噪声的功率谱密度,人为构造噪声。广泛适用于音频编解码器。在编码端计算静音时的白噪声功率谱密度,将静音时段和功率谱密度信息编码。在解码端,根据时间信息和功率谱密度信息,重建随机白噪声。 它的应用场景:完全静音时,为了创造舒适的通话体验,在音频后处理阶段添加随机白噪声。 音频编码基础 音频的另一个广泛应用的领域:音频编码。 首先看一下当前应用最广泛的一些音频编码标准,如下图所示。 图中横轴是音频编码码率,纵轴是音频频带信息。从图中我们可以获得如下几方面信息。 (1)对于固定码率的编码标准,如G.711或者G.722,图中采用单点表示,说明这两个编码标准是固定码率编码标准。其他如Opus、Speex,它们的曲线是连续的,说明这类编码标准是可变码率的编码标准。 (2)从频带方面看,G.711、G.722、AMR和iLBC等标准适用于narrowband(8khz采样率)和wideband(16khz采样率)范围,针对普通的语音通话场景。AAC和MP3适用于fullband(48khz采样率)范围,针对特殊的音乐场景。而Opus适用于整个频带,可以进行最大范围的动态调节,适用范围最广。 (3)从标准的收费情况看,适用于互联网传输的iLBC、Speex和Opus都是免费且开源的;适用于音乐场景的MP3和AAC,需要license授权,而且不开源。   随着音频处理和压缩技术的不断发展,效果更好、适用范围更广、性能更高的算法和新的技术必将不断涌现,如果你有好的技术或者分享,欢迎留言,我们一起探讨。 想要获取更多产品干货、技术干货,欢迎关注网易云信博客。   网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。

2018-09-26

连麦互动直播方案全实践2:网易云信连麦互动直播方案的演变过程

毫无疑问直播是当前移动互联网最热门的领域之一,在超强热度的引导下直播领域也吸引了大量的商业资本。在各大直播应用万花齐放的时刻,也正是直播应用面临的真正风口。站在这个风口上,直播应用只把握好风向标,推出具备高用户粘性的差异化功能,才能在这个不断推陈出新的时代站稳脚跟,获得不可动摇的地位。 《连麦互动直播方案全实践》系列文章基于网易云信的摸索和实践,从场景、流程到方案、架构,对直播体验深度优化方案——“连麦互动直播”进行了全面的讲解和介绍。 相关阅读推荐: 连麦互动直播方案全实践1:什么是连麦互动直播? 连麦互动直播方案全实践3:网易云信连麦互动的实现方案 《连麦互动直播方案全实践》系列第一篇文章介绍了什么是连麦互动直播,现在我们来看一下网易云信在连麦互动直播方案的演变过程。我们从2015年年初就开始研究连麦互动直播技术,提出了一个在主播客户端合流的方案。后来随着移动端直播的快速兴起,我们在老方案的基础上,迭代推出了一个新方案,也就是服务端合流方案。 接下来我会为大家详细阐述这两个方案的具体实现方式,并且分析各自的优势、劣势以及适用的场景。 主播端合流方案 首先我们来看一下老方案,我们称之为:主播端合流。 传统的直播流程是:主播客户端采集并编码音视频数据以后,直接使用RTMP协议推流到CDN,其它观众使用对应的拉流地址向CDN拉取音视频流。 该方案我们不改变由主播来推流这个架构,只是在主播需要与观众连麦互动时使用实时音视频系统来进行主播和观众的实时互动连麦,通过实时通话通道主播端收到观众端发送的音频和视频数据,主播端将自己的声音和观众的声音做混音,并将自己的画面与观众的画面做视频合成,最后主播将混合的声音和画面推流到CDN流媒体服务器。通过这种方式就实现了观众与主播的连麦互动直播。 那么这个方案有什么优缺点呢? 由于上述两个问题,该方案并不是移动端上连麦互动的最佳方案。 为了解决这两个问题,我们团队用3个月时间来做技术攻关,设计并开发了一个替代方案。 服务端合流方案 这个全新的连麦互动直播方案,作为优化替代方案,方案的关键是:主播不再直接推流到CDN流媒体服务器,而是基于实时音视频通话系统,由实时音视频的中转服务器转发给互动直播服务器,再由互动直播服务器处理后推流到CDN流媒体服务器,互动直播服务器是我们为方案二全新研发的一个服务器。 音视频实时通话系统,可以实现多人的实时互动,而且多人模式下所有的数据包都是通过音视频中转服务器中转。此时如果观众需要与主播连麦互动,只需要让观众加入到实时音视频的房间中,音视频中转服务器在转发给房间中其他客户端的同时,转发一份到互动直播服务器,互动直播服务器对收到的语音进行混音,同时对视频画面做混合处理,处理完毕以后再推流到CDN流媒体服务器。 通过这种方案,将方案一中由主播端做的混音混合及推流操作,转嫁由互动直播服务器来承担。对于普通观众不需要其它额外的处理逻辑就能在原来的拉流地址上拉取到连麦互动的直播画面。 那新方案有哪些优点? 简单的提一下,有些APP使用不同与上述两种方案的其它方案来实现连麦互动直播。也就是主播和连麦者分别发送一路RTMP流到CDN服务器,观众端通过分别拉取主播和连麦者的两路流来实现连麦互动直播。 这个方案的问题是:RTMP协议延迟很高,一般至少在3秒,主播和连麦者之间使用RTMP协议来做连麦互动,互动的实时性是不可接受的。同时普通观众要拉取两路流,功能流程会变得复杂,同时还增加了普通观众的下行压力。 由于这两个问题,该方案不是一个合格可行的低延迟连麦互动方案。 那么网易云信全新的连麦互动直播方案具体是怎么实现的呢?《连麦互动直播方案全实践》第三篇文章将会向大家详细介绍。

2018-09-26

连麦互动直播方案全实践3:网易云信连麦互动的实现方案

毫无疑问直播是当前移动互联网最热门的领域之一,在超强热度的引导下直播领域也吸引了大量的商业资本。在各大直播应用万花齐放的时刻,也正是直播应用面临的真正风口。站在这个风口上,直播应用只把握好风向标,推出具备高用户粘性的差异化功能,才能在这个不断推陈出新的时代站稳脚跟,获得不可动摇的地位。 《连麦互动直播方案全实践》系列文章基于网易云信的摸索和实践,从场景、流程到方案、架构,对直播体验深度优化方案——“连麦互动直播”进行了全面的讲解和介绍。   相关阅读推荐: 连麦互动直播方案全实践1:什么是连麦互动直播? 连麦互动直播方案全实践2:网易云信连麦互动直播方案的演变过程   接下来我们来看看网易云信全新的连麦互动直播方案具体是怎么实现的?我们从架构图中可以看出,整个连麦互动直播主要由两大模块组成,实时音视频系统和互动直播服务器系统。 实时音视频系统 首先我们来看一下实时音视频系统。实时音视频其实就是基于网络的,能够进行音频或者视频,低延迟的双人或者多人之间的实时通话。像skype,facetime,微信,易信都提供了实时音视频通话功能。在互动直播中,实时音视系统主要是为了实现低延迟连麦功能。 我们来看下实时音视频的架构图: 各平台客户端使用客户端sdk接入实时音视频系统,包括:iOS,Android,PC和嵌入式设备。 客户端与业务服务器集群维持一条APP协议长连接,使用加密的tcp私有协议作为交互协议,主要用于相关业务的发起、通知推送等等。业务服务器集群包括用户加速接入的边缘连接服务器,包括用于为用户智能分配全球媒体服务器节点的分配服务器。客户端通过APP协议从分配服务器获得媒体服务器地址以后,就进入实时音视频的媒体和网络流程。 为了更直观的说明,架构图里展示的是单向流程。左侧是发送方,右侧是接收方。发送方的编解码进行音视频采集、音视频预处理,然后进行音视频的编码,随后进入网络层,在做完私有协议的封包、传输可靠性的保障以后,使用加密的udp私有协议作为传输层协议,将数据包发送到分配服务器根据智能算法分配的媒体服务器集群。通过边缘加速节点到达核心媒体中转服务器,媒体中转服务器负责将数据包转发给同一会话的其他用户。 接着我们来看接收方。接收方同样使用加密udp私有协议,接收方的网络层收到媒体中转服务器发过来的数据包,自底向上首先进行私有协议解包,然后做相关的网络层QoS保障。网络层处理结束以后将完整的音视频编码数据回调编解码层。在编解码层中,首先进行音视频的解码,然后相关音视频后处理,最后将处理完的音频进行播放,并在界面中绘制出视频画面。 这样就完成了一次音视频数据的单向交互,反向的流程一致。另外我们看媒体服务器集群中除了最关键的是中转服务器。还有录制存储服务器用户将通话过程中的音频和视频录制下来,并存储到云端。而统计分析服务器用于分析统计用户的通话质量与系统的运行状态,为优化实时音视频的通话效果很有帮助,同时对于节点分配服务器的策略也有相应参考。 实现的这套实时音视频系统的几大技术要点,主要包括下面四个部分:网络、音频、视频和适配。 有了上面实时音视频部分的介绍,我们就为连麦互动直播的低延迟连麦打下坚实的基础了。   互动直播服务器 互动直播服务器的功能主要是: 进行互动直播中主播与连麦者的画面合成; 对接CDN流媒体服务器 互动直播服务器的要点主要是:融合实时系统与直播系统;实时处理视频的合成;保证互动同步性以及高性能硬件。 下面我们来简单看一下互动直播服务器的多线程异步架构。 互动直播服务器主要由一个IO主线程、多个工作子线程和多个推流线程池组成。 IO主线程负责创建udp监听fd,并注册可读事件到eventloop事件循环中。中转服务器将音视频数据转发到主线程监听的端口上,eventloop可读事件回调,IO主线程负责读取内核UDP缓存中的将数据包,并根据哈希算法放入到与工作子线程一一对应的临时队列中。当内核缓存被读空以后,IO主线程会触发eventloop监听在eventfd可读事件的各个工作子线程。然后通过闭包的方式将各个主线程临时队列里的数据派发到相应的工作子线程中处理。 工作子线程从队列中依次取出数据包,对数据进行协议解包,进入协议分发器,进行业业务逻辑的拆分,对于音频数据进行丢包处理,然后会由jitterbuffer算法来平滑抖动并解码成pcm数据;对于视频会同样会进行丢包处理,然后进行视频解码成yuv数据,视频部分还会做一步和音频的同步操作。之后会进行每个房间的多路音频pcm数据的混音和多路视频yuv的混合。混音结束以后会将pcm数据再编码为aac然后调用aac推流,视频yuv数据编码为H264以后调用H264的推流。 推流线程池负责讲aac和h264的裸数据按照FLV的格式进行封装,然后使用推流网络IO将音视频包使用使用RTMP协议推送到cdn流媒体服务器。 普通观众可以使用rtmp拉流地址向cdn流媒体服务器拉取音视频流完成连麦互动直播的收看。 我们看到我们只有一个IO线程来处理IO读操作,这样做的目的主要是保证我们的IO不受音视频编解码的影响,我们会把IO线程绑定在特定的cpu上。 工作子线程也会绑定对应的cpu核心,这么做也是为了提高性能。绑定以后,性能大概可以提高20%。主要是因为工作子线程是超高计算密集型的,对cpu的压力很大,如果不绑定,线程就有可能在不同的核心上切换,导致相应的性能损失。   服务器部署和智能分配 讲完了上面两大系统各自的功能和实现细节以后,我们还缺少什么呢? 我们的服务是要部署在我们服务器上,而服务器的部署和分配在连麦互动直播里至关重要,那我们接下来就来看服务器部署和智能分配方面有哪些要点。 首先为了能够为全球的用户提供优质服务,全球范围的节点部署是必不可少的。以网易云信的经验,依赖网易在全球的机房,我们在国内部署多个BGP机房和三线机房,对于海外我们部署了海外节点,特别为了优化跨国聊天,我们还使用跨国代理的光纤专线。 第二,在有了这么多节点以后,就需要由一个节点的智能分配策略。需要根据用户的地理位置、用户的运营商ISP类型为用户分配最佳接入的节点。当然分配的时候还需要考虑服务节点的实时负载情况和实时的网络状况。 第三,单纯的服务端的节点分配是不够的,客户端还需要配合使用智能选路策略。根据各链路的丢包和时延,智能选择最佳链路。同时当某条链路中断后,还会切换到另一条链路上。链路的切换是透明的,对上层用户无感知,也就是通话不会受到影响。 第四,为了保证整个实时音视频服务的高可用,我们的所有服务器均使用高可用的架构部署,由于音视频服务器对网卡是高需求,我们80%的服务器使用了配备万兆网卡的高性能物理机。同时对于服务器宕机、网络切断,都使用了相应的恢复和策略切换,所有这些都为了我们实时音视频服务的高可用。   以上就是网易云信全新连麦互动直播方案的具体实现方法,欢迎大家留言,与我们互动交流。

2018-09-26

几十万人同时在线的直播间聊天,如何设计服务端架构?

一个热门视频直播间人数可能达到几十万甚至上百万人,几十万人发消息,几十万人接收,流量相当惊人,那么服务端要如何设计才能保证系统流畅?本文作者将结合他在网易云信多年IM开发的经验进行深度分析。 推荐阅读 高并发IM系统架构优化实践 IM即时通讯:如何跳出传统思维来设计聊天室架构? 聊天室架构应满足哪些条件 高可用:任何一个节点故障都不应该引起服务不可用; 易扩展:具有水平扩展的特性,对不同量级的在线用户数都有应变的能力; 高并发低延迟:能支持大量的用户同时收发消息,消息从发出到送达所有在线端的延时在毫秒级; 客户端兼容性:新型的应用都是能同时跨多种设备实现消息互通的,比如网页端,手机端和桌面端,甚至智能电视等。 聊天室架构如何设计 客户端层 处理各种设备的兼容问题,包括对ios,Android,Windows, Web等各种开发平台的语言适配;消息通道的管理维护,包括移动设备上的弱网络管理,断线重连等;保证数据安全,所有上行下行的数据包都需要加解密处理,规避数据泄露或中间人攻击等各种安全风险。 网关接入层 管理大量客户端连接,单个节点可以维护的客户端数量在数十万量级;处理不同类型客户端的协议兼容,由于客户端实现技术的多样性,导致客户端与网关之间底层的数据通信协议存在差异,需要由不同的接入网关做协议转换;处理数据安全逻辑;跨网络的高可用逻辑,网络级别的主备(谁知道哪天网线会被蓝翔的毕业生挖断呢?);广播消息的高效下行分发,将收到的广播消息分发到所有连接在本节点上的客户端。 路由层 作为业务层接入的中转,同时承担负载均衡和高可用的作用,单个业务节点处理能力达到瓶颈时更方便的扩容,路由层使业务层扩容对前置网关层完全透明;当一个网络的业务集群出现网络故障时,可以切换到备用网络,保证服务可用性。 业务层 处理聊天室内的业务消息,一个集群内有众多节点,节点角色相互对等,任何一个节点的故障会使整个集群的处理能力下降,但不会引起服务的中断,因为其他节点可以继续接管业务数据包的处理;业务集群同样有多个网络环境的热备,以应对可能出现的区域性网络故障。 难点在哪里 客户端多样性 目前的应用都存在跨平台的需求,iOS、安卓和PC端,网页端,甚至IOT物联网设备,能连多少是多少,多多益善;但是不同开发平台之间的技术差异性极大,不是所有公司都有这么全的全栈程序猿的;如果团队开发的话单就客户端开发人员就不是几个人可以完成的。 数据安全的保证 当前的网络安全形势异常复杂,开发应用时如果不在通信安全上花心思,那你的用户就是在互联网上裸奔;开发者需要针对不同的平台,不同的通信技术实现可靠的安全方案,避免用户数据在传输过程中泄露,避免中间人攻击等安全风险。 跨机房网络级的高可用方案 当机房网络出现故障时把责任推给市政施工队或者“网络抽风”已经不流行了,用户需要的是故障无感知。 所有环节的单点故障排除 任何硬件和软件都存在故障的可能,我们无法避免应用罢工,那就需要随时准备替补上场。 能应对任何用户量级的需求 架构级做到水平扩展的能力,当用户量增长时随时可以通过堆服务器来解决,而不是将架构推倒重来。 看完文章还是不知道怎么做?那么可以尝试借用目前已有的平台或工具,现在应用需要关注的是怎么以最快的速度抓住用户。网易云信是一个面对开发者的很好的IM云平台。十余年的研发积累,使其在即时通讯技术方面处于全国领先水平。网易云信至今已申请了60余项IM专利,远超市场同类产品。欢迎大家与我们讨论IM技术,也欢迎大家多多关注网易云信。 另外,想要获取更多产品干货、技术干货,记得关注网易云信博客哦~  

2018-09-26

连麦互动直播方案全实践1:什么是连麦互动直播?

毫无疑问直播是当前移动互联网最热门的领域之一,在超强热度的引导下直播领域也吸引了大量的商业资本。在各大直播应用万花齐放的时刻,也正是直播应用面临的真正风口。站在这个风口上,直播应用只把握好风向标,推出具备高用户粘性的差异化功能,才能在这个不断推陈出新的时代站稳脚跟,获得不可动摇的地位。 《连麦互动直播方案全实践》系列文章基于网易云信的摸索和实践,从场景、流程到方案、架构,对直播体验深度优化方案——“连麦互动直播”进行了全面的讲解和介绍。 相关阅读推荐: 连麦互动直播方案全实践2:网易云信连麦互动直播方案的演变过程 连麦互动直播方案全实践3:网易云信连麦互动的实现方案 背 景 当前国内大多数的直播应用,使用的是单主播模式,主播与观众仅仅使用文字、点赞、礼物等方式进行互动。在主播直播时,观众如果能够与其进行实时的视频互动,给观众连麦露脸的机会,这将大大提高用户的参与感与幸福感,增加用户粘性。 什么是连麦互动直播 为了更直观的阐述互动直播是什么,举个简单的例子:传统直播就像看“新闻联播”,观众只能收看这个节目,偶尔能通过手机短信发信息与节目组进行互动。当然现在基于互连网的直播已经先进得多,可以使用互联网发送文字、点赞、送礼物,消息的实时性也大大提高,但本质上与看“新闻联播”的体验类似。 而互动直播就像到达芒果台快乐大本营的录制现场,观众坐在录制现场的观众席上,可以看节目,同时还有机会被邀请到台上和主持人互动,当然主持人可以邀请多名观众上台进行互动,而互动的内容其他观众也能看到。 连麦互动直播相比传统单向直播,给了观众更直接的参与感以及与主播音视频实时互动的满足感,对提升直播应用的活跃度和粘性都有明显作用。 连麦互动直播功能流程 (连麦互动直播功能流程图) ① 主播正常开始直播,普通观众看到主播的单人直播画面; ② 需要连麦的观众发起连麦请求,进入连麦申请列表; ③ 主播从连麦申请列表中选择一名或多名观众进行连麦操作,主播与连麦观众进行实时音视频互动,同时互动直播系统生成“合成画面”; ④ 普通观众看到直播画面为包含主播与连麦观众的“合成画面”; ⑤ 连麦结束,恢复主播单人直播模式。 连麦互动直播的应用场景 首先是娱乐秀场的场景,这个场景大家很好理解:美女主播和台下粉丝互动,对用户幸福感的提升,效果绝对明显。我们来看左图是观众申请连麦以后,主播端连麦申请列表的状态。主播选择一名观众进行连麦互动,连麦者的出现在直播画面在右下角。 第二个是在线教育连麦场景,口语老师在讲课的过程中可以让学生参与阅读发声,老师可以及时纠正发音,能够达到很好的教育效果,其它同学听到教学过程也会有一些自己的收获,这对在线教育来说是明显的进步。 第三个是电商互动场景,买家可以与卖家直接互动沟通。对于提升用户体验与参与感有明显作用。这样买卖双方的沟通成本大大降低,也提升直播平台的用户活跃度。 讲完了应用场景,我们来看一下网易云信连麦互动直播方案的演变过程,《连麦互动直播方案全实践》第二篇文章将会详细介绍。

2018-09-26

视频私有云实战:基于Docker构建点播私有云平台

私有云是为一个客户单独使用而构建的,因而提供对数据、安全性和服务质量的最有效控制。前置条件是客户拥有基础设施,并可以使用基础设施在其上部署应用程序。其核心属性是专有的资源。本篇文章将会结合网易云信的实践经验,以全局概述的方式带大家认识点播私有化平台构建的整体架构面貌。   推荐阅读 《几十万人同时在线的直播间聊天,如何设计服务端架构?》 《高并发IM系统架构优化实践》 云计算的出现,通过硬件的虚拟化将大量的服务器硬件抽象为巨大的资源池,可以动态的为用户提供基础设施、平台和应用三种形式的服务。目前企业的使用方式有公有云和私有云。公有云下,企业可以抛弃复杂的基础设施构建和维护,按需购买计算资源和应用服务。但是考虑到一些数据的敏感性和网络互连互通问题的限制,企业将自己最核心的业务完全托管至公有云有很大顾虑。因此,基于业务上的可靠性、安全性、可控性,很多企业选择建设私有云。 私有云是为一个客户单独使用而构建,因而提供对数据、安全性和服务质量的有效控制。前置条件是客户拥有基础设施,并可以使用基础设施在其上部署应用程序。其核心属性是专有的资源。   架   构 点播私有云平台的模块设计 基础服务包括: 缓存、数据库、消息队列等部署在PaaS层的服务,提供数据的存储和访问。 容器管理基于Docker和Kubernetes管理点播服务各个组件的生命周期。 能力管理集群包括: 上传服务集群,基于S3设备的分布于不同节点的断点上传。 流媒体服务集群,支持视频的边下边播等播放特性。 转码集群,处理视频转码的引擎。 通过提供基础服务和能力管理集群构建平台服务,用户只需要在此基础上接入业务应用,集成播放SDK和上传SDK,即可快速构建点播服务。   点播私有云平台的部署实施设计     上图阐述了点播私有化平台的最小部署集群,其中控制集群包含通过基于Openstack进行的硬件资源虚拟化、Docker和Kubernetes实现的容器服务管理、基于虚拟资源和容器的哨兵监控以及账号管理。计算集群包含点播服务组件的部署以及依赖的存储、数据管理服务。   平台组成 整个私有化平台从底层向上构建包括:硬件资源的虚拟化、数据存储服务构建、点播组件服务部署。   硬件资源的虚拟化 上图阐述了将硬件资源虚拟化的分层抽象架构: IaaS:基于Openstack的云计算基础服务(包括云计算、云网络和本地存储) 将硬件资源虚拟化为云主机,支持云主机的管理操作(创建、启动、停止、重启、删除、快照、修改规格、离线迁移、修改云主机名称等操作)、镜像快照管理、安全组管理、网络资源管理(通过管理内网IP和外网IP浮动池,使用获取,销毁释放至IP池)、监控报警(云主机的各项指标监控)。 Pass服务:基于IaaS构建的多租户PaaS服务(包括存储服务、数据库) Kubernetes:多租户的集群编排的容器服务 Kubernetes服务为分布式应用服务提供容器的创建、编排、调度、服务发现、弹性伸缩等功能。基于Kubernetes的特性同时融合基础服务的负载均衡服务能够保证服务的高可用、高可靠、弹性扩容、不同级别的服务隔离。 管理服务:提供用户管理和API操作相关服务 提供产品的开发环境、测试环境、线上环境等生命周期的容器服务平台。通过SOA服务化系统的部署,支持静态资源发布、后端服务的动态扩容发布、服务的自动上下线等。     数据存储服务构建 PaaS层上数据库的构建 基于MySQL在计算节点上进行主从部署,隔离网络环境,提供私有网络实例。所有实例都是高可用实例,即每个实例都有master和slave角色。slave宕机时,不会对服务产生影响,master发生宕机的情况,会切换至slave实例,同时服务管理会拉起master实例。从而提供稳定可靠的数据库服务,提供多重安全防护措施和专业的备份、恢复等功能。   PaaS层上存储服务的构建 基于S3设备,同时提供多节点的断点上传、以及图片和视频处理云信息获取服务。提供高可用、支持断点续传,同时针对视频文件特性,获取视频文件元信息的存储特性。其中上传服务和云信息获取服务采用Docker镜像部署,保证服务的管理自动化。   点播组件服务部署 所有点播组件的部署基于Docker镜像,通过容器管理服务保证服务的高可用以及自动化管理。组件图如下所示: Registry:服务注册与发现的注册中心。部署原生的zookeeper集群作为独立的注册中心,主要使用zookeeper提供的一致性同步协调能力和服务探活能力。zookeeper的部署采用Docker容器,利用容器的服务管理能力保障服务的稳定、高可用。 Consumer:调用远程服务的服务消费方。包含对外提供的API接口和为直播录制视频存储开放的接口。用户通过接口进行视频上传、转码和管理。消费方服务部署采用Docker容器,利用容器的服务管理能力保障服务的稳定、高可用。 Provider:调用远程服务的服务提供方。包含视频处理服务、视频检测服务、录制视频处理服务、统计服务。提供方服务部署采用Docker容器,利用容器的服务管理能力保障服务的稳定、高可用。 Monitor:统计服务的调用次数和调用时间的监控中心。   组件间调用关系 服务提供者启动,向注册中心注册自己提供的服务。 服务消费者启动,向注册汇总新订阅自己所需的服务。 注册中心基于长连接推送服务提供者列表给消费者。 服务消费者从列表中,基于一定的负载均衡算法,选一台进行调用,如果失败,再选取另一台调用。 服务消费者和提供者,内存中累计调用次数和时间,定时发送统计数据到监控中心。   优    点 私有云相比较于公有云,在数据安全、充分利用现有硬件和软件资源、服务质量、管理流程上有突出优势。基于Docker构建点播私有云平台在具有以上优势的同时,还具备资源弹性管理、监控完善、部署简易、自动化维护等特性。 (1)数据安全。由于存储服务部署于用户的硬件环境,构筑在防火墙之后,同时存储服务的高可用,能够保证用户数据的可靠和安全。 (2)监控完善。上述描述的哨兵系统介入整个点播私有化平台的构建过程,能够及时上报各个过程中组件的异常情况。 (3)资源弹性管理。基于Openstack构建IaaS平台,能够自由管理创建云主机。基于Docker和Kubernetes构建容器管理服务,能够基于服务镜像自由创建服务,同时容器管理服务能够做到弹性扩容。 (4)部署简易、自动化维护。在通过事先编排好的脚本构建好基础IaaS平台后,利用服务镜像能够快速部署服务。容器管理服务的服务发现能力使得服务的维护变得简单。   总    结 整体来说,私有云由于其特性,在实施过程中,运维成本远远高于开发成本。所以,在面向用户交付实施的过程必需简易,后续维护尽量做到自动化。尽大可能减少人工介入。本文构建过程中采用的架构技术特点(Openstack、Docker、Kubernetes、zookeeper)比较符合这些特点。本文以全局概述的方式试图带大家认识点播私有化平台构建的整体架构面貌。后续将会在此基础上不断深入每个过程的细节,探讨实现的考虑点和合理性。想要获取更多产品干货、技术干货,欢迎关注网易云信博客。

2018-09-26

IM即时通讯:如何跳出传统思维来设计聊天室架构?

因为视频直播业务的大规模扩张,聊天室这种功能在最近几年又火了起来。本篇文章将会重点挑选聊天室这个典型场景,和大家分享一下网易云信在实现这个功能时是如何做架构设计的。 相关推荐阅读 几十万人同时在线的直播间聊天,如何设计服务端架构? 高并发IM系统架构优化实践 常见的虚拟社群 聊天室的应用场景非常广,除了传统的图文聊天外,时下流行的视频弹幕、在线秀场、在线教育、游戏互动等各式各样产品中都有类似的应用场景。 在讨论聊天室之前,我们先了解下几种常见的虚拟社群形态。下表从参与人数、消息送达即时性、离线消息关注度等维度对论坛、IM P2P、IM群和聊天室这几种常见的虚拟社群形态做了简单对比,从这个对比可以看到聊天室是不同于论坛和群模式的一种虚拟组织,聊天室的架构需要跳出传统思维来设计。 聊天室跟普通的IM群(微信群,QQ群等)相比最大的不同点在于它是一个比较开放的虚拟组织。我们可以将聊天室比喻成一个广场,广场是开放无边界的,所有的人都可以随进随出,而群就像一个房间,是一个有边界有容量上限的私密组织,并且进入这个房间需要一定条件,一般是主动申请加入或被邀请加入。聊天室对比BBS论坛这种虚拟组织来说,它既具有了IM群消息即时送达的特性又有论坛参与人数无上限的特性。 聊天室关键技术和难点 那么,是否能从一个已有的成熟技术框架上改造一个聊天室出来呢? 经过前面的比较我们看到,聊天室和论坛及IM群都具有一定的共性,看起来似乎可以将论坛架构改造成聊天室,也可以将IM群改造成聊天室。 路径一:将论坛架构改造成聊天室,首先需要提高消息送达的即时性,由于论坛都是基于HTTP协议的,为了保证消息即时送达,需要客户端不断轮询服务器来获取新的消息,如果对即时性的要求越高,那轮询的时间就需要缩短,这种模式在用户量达到一定规模后是无法承载的。为了保证消息的高效送达,客户端与服务器之间的需要采用长连接机制,新消息的送达通过服务器主动向客户端下推来完成。 路径二:将已有的IM群改造成聊天室,由于群具有对离线消息关注度高的特性,所有的群消息在成员离线时需要持久化,因而群人数越多效率越低,也正是因为这个原因,一般的IM群都是有人数上限的,如果想把群改造成聊天室,就不能存离线消息,所以这种方式看起来也不是这么顺畅。 现在市场上很多提供聊天室类服务的产品其实都是基于群的模式来实现的,所以人数上限一直是一个难以突破的瓶颈,甚至有的服务直接使用“超大群”或“千人群”这样一种特殊群模式来满足用户对聊天室场景的需求。 下面我们来看下,如果要实现一个人数无上限的聊天室服务,需要解决哪些难题。 首先:客户端多样性。近几年来移动互联网发展得非常快,现在推出的APP一般都需要同时具备iOS版、安卓版和Web版、PC版等不同的版本,跨平台的开发需求一直是拦在创业团队面前的一座大山; 第二:数据安全保障。当前的网络环境异常复杂,我们的APP在客户端与服务器之间的数据通信都暴露在复杂的公网环境中,消息经过哪些节点,中间有没有被抓包,数据是否被恶意采集,这些问题普通用户开和发者都容易忽略。如果数据通信过程中忽视了安全需求,很容易造成用户数据的泄露,数据的安全保障对于产品而言也很重要; 第三:需要应对网络故障或服务单点故障的难题。开发者代码写得再好也无法避免硬件故障或是网络故障这种不可预知的问题,在产品积累了一定的用户量之后,如果遇到服务可用性问题会造成用户流失; 第四:架构需要具备足够的弹性。在用户量级上来之后能支持快速的水平扩展,不会因为架构的问题需要重构; 最后:消息投递慢。聊天室对消息的即时性要求非常高,同一条消息在投递给不同成员时需要在毫秒级的延时完成,如果消息投递慢了会造成消息时间线错乱,聊天室里的人无法理解上下文场景。 基于这些难点,我们提出聊天室需要具备这些指标:跨平台、数据加密、高可用、易扩展、高并发低延迟。 网易云信聊天室的架构 上图是网易云信的聊天室分层架构。 客户端层:处理各种设备的兼容问题,包括对ios,Android,Windows, Web等各种开发平台的语言适配;消息通道的管理维护,包括移动设备上的弱网络管理,断线重连等;保证数据安全,所有上行下行的数据包都需要加解密处理,规避数据泄露或中间人攻击等各种安全风险。 网关接入层:管理大量客户端连接,单个节点可以维护的客户端数量在数十万量级;处理不同类型客户端的协议兼容,由于客户端实现技术的多样性,导致客户端与网关之间底层的数据通信协议存在差异,需要由不同的接入网关做协议转换;处理数据安全逻辑;跨网络的高可用逻辑,网络级别的主备(谁知道哪天网线会被蓝翔的毕业生挖断呢?);广播消息的高效下行分发,将收到的广播消息分发到所有连接在本节点上的客户端。 路由层:作为业务层接入的中转,同时承担负载均衡和高可用的作用,单个业务节点处理能力达到瓶颈时更方便的扩容,路由层使业务层扩容对前置网关层完全透明;当一个网络的业务集群出现网络故障时,可以切换到备用网络,保证服务可用性。 业务层:处理聊天室内的业务消息,一个集群内有众多节点,节点角色相互对等,任何一个节点的故障会使整个集群的处理能力下降,但不会引起服务的中断,因为其他节点可以继续接管业务数据包的处理;业务集群同样有多个网络环境的热备,以应对可能出现的区域性网络故障。 看完文章还是不知道怎么做?那么可以尝试借用目前已有的平台或工具,现在应用需要关注的是怎么以最快的速度抓住用户。网易云信是一个面对开发者的很好的IM云平台。十余年的研发积累,使其在即时通讯技术方面处于全国领先水平。网易云信至今已申请了60余项IM专利,远超市场同类产品。欢迎大家与我们讨论IM技术,也欢迎大家多多关注网易云信。 另外,想要获取更多产品干货、技术干货,记得关注网易云信博客哦~  

2018-09-26

如何快速实现移动端短视频功能?

在“互联网+”概念被炒的如火如荼的今天,短视频以视频短、传播快、生产流程简单、制作门槛低、参与性强等特点在互联网所有的热门的焦点中脱颖而出,出现在公众的视野里。那么如何快速实现移动端短视频功能呢?本文作者将根据其对行业的洞察,结合网易云信技术进行具体的分析。   推荐阅读: 几十万人同时在线的直播间聊天,如何设计服务端架构? 连麦互动直播方案全实践1:什么是连麦互动直播? 连麦互动直播方案全实践2:网易云信连麦互动直播方案的演变过程 连麦互动直播方案全实践3:网易云信连麦互动的实现方案   短视频推送和播放 目前AppStore上有很多包含或者以短视频业务为主的APP,比较典型的有今日头条、快手和网易新闻。 这三款产品是当下日活比较高的APP,可以在一定程度上代表短视频的业务走向。这三款产品在视频业务上具有以下几个主要特性: 视频时长较短,内容精彩,播放便捷。 视频来源广泛,有网友原创、有视频合成、有影视节选。 根据用户行为推送用户感兴趣的内容,精准定位用户需求。 广泛的社交圈子分享、大量的运营公众号推送。 因为这一类APP的业务重心是靠海量视频推送让用户产生“产品粘性”,因此对于短视频的前期采集和编辑等方面的业务显得薄弱,也正因为这样才会产生以下几个弊端: 用户群范围缩小,不能达到随拍随发的效果 用户单项接收视频推送,社交圈子活跃度存在发展瓶颈 前处理的力度不够,失去用户创作的视频资源。   短视频的采集和前处理 基于这种业务需求,市场上日益兴起了短视频的另一类业务分支——视频采集和前处理,例如美拍、VUE、Alive。 如果说第一类的APP是为用户提供了一个可以展示自己的平台,那么这一类的APP对于用户来说就是可以创作一个自己满意的作品。这类APP主要有以下几个业务特性: 1)视频来源的多样性。包括本地视频、网络视频、采集的视频等等视频来源。 2)完善系统的视频编辑。包括视频的裁剪、拼接、滤镜、混音、过渡、转码等。 3)视频输出的多样性。包括视频分享、视频上传特定平台等。 4)良好的编辑体验。所有的编辑特效均可以达到“所见即所得”,可以直观的向用户展示编辑完成后的效果。 5)优越的编辑性能。目标视频的生成快速,电量消耗低。 因为这类APP具有着优秀的前端处理能力,因此使产品的类型更偏重于工具类,因此也具有工具类通用的弊端: 1)无法长时间“粘住用户”,导致日活远不及第一类产品 2)  所有技术均放在前端,容易被同类竞品替代,失去市场     完整的短视频业务生态 一个完整的短视频生态应该同时具备以上两类产品的业务侧重点。如图所示: 完整的短视频生态业务应该同时具备视频的本地编辑、云端处理和最终的用户预览。如图中所示红色箭头是视频数据的流向,蓝色虚线是视频相关信息的流向。短视频的核心业务主要有以下几点: 1、视频获取。 移动端设备可以根据用户所需分辨率,进行视频采集,并以文件的形式进行保存。这部分业务在安卓和iOS平台上均可依靠相应平台接口,进行相应分辨率的数据的采集。 2、视频处理。 视频处理主要是视频的裁剪、滤镜、水印、拼接、过渡、混音等特效,一般使用ffmpeg来进行相应的效果处理,更深入的也可以使用某些系统自带的优化接口,或者使用图像处理的相应算法进行视频的效果实现。 3、视频上传。 主要是和视频服务平台进行交互,主要的问题就是要保证上传的速率,一般来说这些服务平台会根据用户位置来分配最近的服务节点,以保证上传速率。 4、视频服务平台 提供视频云处理服务。这里的处理主要包括提供视频的存储空间,为视频进行云端转码,视频信息的加密处理,视频下载和播放结点的优化选择等服务。其中存储和结点优化方面,可以结合自身情况在全国范围内布点,或者直接使用第三方运营的CDN,保证给用户提供最优的链路。 5、用户服务平台。 用户服务平台一般用来做视频信息的统计,一般对用户行为的预测算法都是在用户服务平台做,保证推送给用户的都是最新的视频。同时用户服务平台还需要向视频服务平台获取最优线路,保证用户的下载速率和在线观看的流畅度。 6、视频播放。 一般对于短视频来说,视频播放部分并不需要支持特别全面的视频格式,因为视频服务平台会将所有上传的视频进行统一的格式化转码,因此相对于传统的播放器来说短视频需要一种比较“轻量级”的视频播放器,仅需要支持mp4、flv等主流格式即可。 总体而言,短视频的业务相对是一个闭合的生态,因此比较容易和其他领域的业务进行交叉合作,并滋生出新的类型的app,如图所示的几个外延拓展业务例如社交、直播、IM等     如何快速打造短视频业务 从短视频的核心业务来看,短视频的开发需要比较专业的音视频开发人员进行开发,并且需要长时间的技术沉淀才能在同类竞品中脱颖而出。那么如何才能快速打造一个稳定的短视频业务线呢?因为短视频业务的独立生态特性,可以考虑将短视频业务封装成一个独立的sdk,接入时仅需简单几步,即可完成短视频业务,市面上比较可靠的短视频sdk有网易云信、金山视频云和阿里视频云等。 以网易云信的短视频服务来说,SDK主要完成的业务如下图所示: 如图所示,sdk几乎完成了所有的短视频业务,这里说一下推荐原因: 1、接口灵活。内置提供几近完备的视频处理方案,对于基础薄弱的开发者可以使用默认配置,对于有一定基础的开发人员可以采用完全自定义的方式完成项目的需求。 2、视频服务平台。网易云信具备大规模全网分发能力,转码能力强,点播和下载速度相对较快,弱网情况下,抗网络抖动能力很强。 3、集成方便。接口颗粒度设置相对合理,几乎没有任何代码侵入性,方便快速集成。 最后展示一下,我个人基于网易云信短视频sdk集成的短视频Demo,山寨了一下竞品UI,经过测试可以完全胜任目前市面的所有短视频业务需求,项目开发时长两周。 相信大家看完这篇文章,对于如何快速实现移动端短视频功能已经有了初步的想法,想要获取更多产品干货、技术干货,欢迎关注网易云信博客。 了解网易云信短视频功能,请移步网易云信。  

2018-09-26

Android 即时通讯开发小结(一)

《Android 即时通讯开发小结》基于IM Andriod 开发的各种常见问题,结合网易云信即时通讯技术的实践,对IM 开发做一个全面的总结。 相关推荐阅读: Android 即时通讯开发小结(二) 移动IM开发指南1:如何进行技术选型 移动IM开发指南2:心跳指令详解 移动IM开发指南3:如何优化登录模块 客户端架构 作为一个 IM 软件,最重要的一个特性就是保证消息的达到率和实时性。达到率受服务器性能和设计协议影响,后面再谈。而实时性则主要取决于客户端进程是否长期存活,连接是否一致保持。 进程切分 在 Android 系统中,App 对于自己应用的生命周期是基本没有控制力,系统能在任意时候将你的进程杀死,且不会发出任何通知,也会在它认为合适的时候把你叫起来。进程前后台切换也同样不会给出任何通知。不过进程的生死控制也还是有一些规矩的,大体上来说就是进程占的资源越多(内存,CPU 时间等等),对于用户越不重要(前台进程->可视进程->服务进程->后台进程->空进程),越容易被干掉。因此,进程应当尽量小巧,且具有高的优先级。 如果一个应用本身就很小巧的话,一个进程就完全足够了,主线程负责 UI,另起一个后台线程跑一个服务。而如果应用比较庞大的话,将推送服务独立出来则是一个更好的选择。主进程负责用户交互和主要的业务逻辑,占用庞大的资源,当退到后台后,随时被杀死都无所谓。推送进程则仅仅负责与服务器交互,保持最小限度的业务逻辑处理。 网络连接和登录状态是绑在一起的,登录之后,同步数据也是必须的操作。因此,登录和同步数据都需要在推送进程中完成,除此之外,其他的业务都交给 UI 进程处理。推送进程收到自己不属于自己的协议时,就将数据扔给 UI 进程处理。 两个进程之间通信方式没有别的选择,只有 AIDL,难点在于接口的设计。IM 业务逻辑复杂,我们不可能为每一个调用实现一个 AIDL 接口,因此肯定会把接口调用打包成控制命令传递。而标识控制命令比较容易想到的方式,是采用类似于 Message 的 what,由我们为每一个控制命令分配一个命令号(或者再加一个子命令号),并指定对应的命令数据格式,接收端根据命令号再将数据反解出来处理。这种方式比较麻烦,且可维护性很差。更优雅的方式是使用远程过程调用,发送端申明业务的调用接口,并在远端实现这些接口,当发送端调用这些接口时,远端直接调用对应接口的实现。除了使用各种第三方框架外,Java 自身的 Proxy 也能实现这个功能。而从推送进程到 UI 进程还有一点不同,UI 进程随时可能会被干掉,AIDL 调用可能会返回失败,此种情况可选择 Intent 方式传递数据,并兼具唤起 UI 进程的功能。 保  活 保活分为三个方面,一是系统API提供了接口,应用自己就能做的,这是”合法“的,二是利用系统的缺陷,躲开系统的审查,这算是”非法“的,或者是”灰色“的,三就是多个 App 结盟,互相唤醒,这是耍流氓,谁的阵营庞大谁就赢。 第一种主要有系统闹钟,各种事件的 BroadcastReceiver,任务被移除的回调通知等。 第二种已知的就是在 4.4 及以前版本上,使用 native 进程,并将该进程从 davilk 父进程中脱离,挂接到 init 进程上,以此避开系统的查杀。然后在这个 native 进程中,定时唤起应用。为了让这个 native 进程更轻巧,可以使用 exec 的方式启动一个可执行文件,以除掉直接 fork 带入的 Zygote 进程环境。另外,这种方式也被用在监听自己应用被卸载时弹出调查窗口。 第三种方式现在各大互联网公司都在使用,方式很简单,互相调用指定的 Service,或发指定得广播即可。只要你起一个阿里系的 App,其他阿里系的 App 都会被跟着唤起。你启动一个装了友盟 SDK 的 App, 其他装了友盟 SDK 的 App,以及阿里系的 App 都会被跟着唤醒。 通常,第一种是必备,第二种和第三种则会结伴出现,流氓到底。 通信协议选择 消息的实时性的另一个保证是长连接。当然,你也可以用短连接轮询,但这个一般只在网页端短时聊天使用,在 Android 后台无限时轮询没有人能受的了。长连接类型可以选传统的 TCP,也可以使用 比较新的 WebSocket。 使用后一种的好处主要是服务器的,他们一套连接就可以服务好 App 端和 Web 端。 IM 的通信协议选择性很多,开源的有 XMPP,MQTT等,使用开源协议的优势在于上手快,资料多。而大部分主流 IM 则一般会设计私有的通信协议。使用私有协议,可以针对自己的业务逻辑,设计出更省流量,效率更高的协议,同时,还能有效保护自己的生态圈,就像 Android 手机装不了苹果系统,易信用户不能给微信用户发消息一样。 私有协议的协议内容和开源协议差不多,可以包含通用的协议头,然后加上负载包体。打包时,为了追求可读性,可以使用文本协议,为了追求省流量,则一般使用二进制协议。 在设计私有协议时,消息必达是一个需要侧重考量的地方。由于移动网络的复杂性,消息在客户端和服务器之间传递是有很大可能被传丢的。当客户端发送消息给服务器时,客户端并不能确保消息一定就会被服务器收到,需要服务器在收到消息后给客户端一个回馈,如果客户端没有收到回馈,就需要在一定超时后重新发送。这里存在一个问题就是有可能服务器已经收到了,但回馈的包被丢掉了,这时就会造成消息重复,为了去重,我们需要为相同的消息分配相同的 uuid,供接收方去重。同样,当服务器将消息转发给接收端时,服务器也不能保证接收端就一定能收到,需要接收端给服务器一个回执,告诉服务器这条消息我已经收到了,你就不要再给我发了。 Android 即时通讯开发小结(二)将会从“建立安全连接”、“心跳”、“断线重连”、“多媒体数据管理”、“图片”、“语音”等问题出发,结合网易云信即时通讯技术的实践, 进行详细的介绍和总结。  

2018-09-26

Android 即时通讯开发小结(二)

《Android 即时通讯开发小结》基于IM Andriod 开发的各种常见问题,结合网易云信即时通讯技术的实践,对IM 开发做一个全面的总结。 相关推荐阅读: Android 即时通讯开发小结(一) 移动IM开发指南1:如何进行技术选型 移动IM开发指南2:心跳指令详解 移动IM开发指南3:如何优化登录模块 建立安全连接 安全性是 IM 软件的另一个硬需求。消息传递时如果通信数据如果被第三方截取,要能保证别人不能获取到真实内容。安全连接的过程可以参考 HTTPS 的方式,由服务器将证书下发给客户端,客户端产生一个对称的密钥,并通过服务器证书加密后交给服务器,之后的通信就全部使用这个对称的密钥来加密。当然,这里有两点需要和 HTTPS 有所区别,第一是证书的获取方式,HTTPS 中是由专门机构去验证证书合法性的,IM 的客户端肯定不会这么去做,为了防止获取证书的过程被人截获,然后篡改证书,可行的方式是直接在客户端安装包中直接把证书打进去,该证书可以随着客户端软件升级一起升级,也可以在加密连接之后通过协议升级。第二个问题是对称加密算法的选择,因为密钥的生命周期是跟随一次连接的,时间并不长,而移动 App 对于电量消耗非常敏感,因此加密算法应尽量选择较为简单的类型,例如 RC4。 心  跳 心跳可以分为 TCP 的协议层心跳和 App 的应用层心跳。一般我们都使用应用层心跳,一来便于服务器扩展(比如哪天我们可以换成 UDP 来传),二则是可以更灵活控制心跳间隔。 心跳协议仅仅是用来连接保活,其内容应当尽量精简,除了包头中必要的部分,包体的可选包头都不存在。 对于不同的网络环境,心跳可以采用不同的时间间隔。在不同网络环境下,间隔的选择可以参考微信智能心跳方案。 断线重连 客户端掉线的原因无非两种,客户端网络挂了,服务器挂了。客户端网络挂了也分两种,一种是本机就能感知到的网络连接断开,另一种是本机网络是好的,但互联网连接是不同的,对应到 Android API上,就是 NetworkInfo 的 isAvailable 和 isConnected。当然这个地方的 isConnected 不一定可靠,因为它是靠连制定服务器来确定的,那个服务器谁知道有没有问题。 掉线后,根据不同的状态需要选择不同的重连间隔。如果是本地网络出错,并不需要定时去重连,这时只需要监听网络状态,等到网络恢复后重连即可。如果网络变化非常频繁,特别是 App 处在后台运行时,对于重连也可以加上一定的频率控制,在保证一定消息实时性的同时,避免造成过多的电量消耗。 而如果掉线是因为本机网络连不通互联网,或者是服务器挂了,重连间隔的选择就非常重要了。 首先,如果程序是在前台,用户正在使用我们的 App,重连间隔应更加频繁,使得用户反馈更加及时,如果程序处于后台运行,则为了省电,可以适当延长重连间隔。 其次,随着重连次数的增加,说明服务器短时间内恢复的可能性逐渐降低,重连间隔也应随之延长(倍数增长)。但应该设置一个最大的重连间隔,当到达最大间隔时,不再增加。 第三,重连间隔的增加不应当是固定的,而应该增加一个随机退避策略。以免如果是服务器宕机造成掉线,所有客户端的重连时间点都是一样的,当服务器恢复后,同一个时间点所有客户端同时连接服务器,造成服务器不堪拥堵,再次宕机。活生生的例子请参考环信去年的宕机时间。 总结起来,重连间隔可表述如下: 多媒体数据管理 IM 系统中另一个重头戏是多媒体数据。由于移动网络比较慢,流量又贵,在移动端针对这些问题必须要做一些处理。在上传时,尽量减少上传时间,在下载时,能让用户尽快看到内容。同时,尽量节省流量,减少不必要的流量消耗。 文本消息因为比较小,可以直接通过长连接传输。但对于多媒体文件,通过长连接来传输则不合适,长连接服务器不会对大文件传输做针对性优化,大量的多媒体文件数据会直接抢占其他信令消息和文本消息的贷款资源。因此,多媒体消息会通过另外的通道,到专门的文件服务器存取。 在下载时,对于不同的网络环境,可以采用不同的预取策略。在 WiFi 环境下,由于无需考虑流量问题,在收到消息后,我们就能立即把包含的多媒体文件下载下来。而在移动网络中,则应当等到用户真正看到该多媒体消息时,才去下载。 图 片 上传时,现在手机摄像头的像素动辄上千万,一张图片随随便便就好几M,然而,通过 IM 软件传输的图片,通常对于质量要求并不会太高,如果我们直接将好几M的图片直接上传,往往费力又不讨好。在上传之前,将图片像素降低,并进行压缩,可以明显的减少上传转菊花的时间,减少用户流量消耗。如果用户确实要求图片质量,则提供一个原图选项。 如果是使用 http 上传,大文件会被分成多个数据块上传,前一个数据块传输成功后,再传输下一个。断线重传时,也是以数据块作为最小重传单元。针对不同的网络类型,数据块大小不同。在较好网络下(wifi/4g/3g),数据块可以比较大,这样可以减少交互时间,加快传输熟读,而在弱网环境,数据块应当设置的比较小,以降低传输失败概率,减少重传流量消耗。 使用 http 上传的另一个优化技术是使用 pipeline。在不使用 pipeline 时,上传一个数据块需要等到前一个数据块传输成功才行,数据通道是单工的。使用pipeline则可以将数据通道变为双工的,一个数据块传输完成后,不必等到回包,就能直接上传下一个数据包,能节省一次数据回包延时。 下载时,在消息展示区显示的通常只是一个很小的图片,这时候只需要下载对应大小的缩略图即可,无需下载原图。甚至,这里可以将比缩略图更小的图片二进制数据直接放到消息体中下发,并展示给用户一个高斯模糊后的效果图,在保证最低可用的情况下,减少用户等待时间,提高用户体验。 语  音 对于不同的网络环境,采取不同质量的语音编码算法,在较好网络时,使用高质量语音,而在弱网环境下,则使用较低质量,优先保证可用性。 为了减少用户等待时间,还可以采取边录边传的策略。由于录音时间比较长,在录制的过程中,我们就可以将录好的部分先传到服务器,等到录音完成,只需要上传最后一个数据包,并告知服务器录音完成即可,基本上可以做到录完即传完,无需等待。 语音消息没有缩略图,因此语音下载基本就只能实打实的将原始文件下载下来。 以上就是网易云信对于Android 即时通讯开发的小结,欢迎各位积极提问,共同探讨。  

2018-09-26