融云:技术架构的衍变源自对需求的把握

4月16日,全球软件开发大会(QCon)在京举行,融云首席架构师&联合创始人李淼发表了以《海量消息的直播互动系统演进历程》为主题的演讲。

云服务助力直播行业井喷

云服务由下至上可分为IaaS、PaaS和SaaS,其中PaaS层厂商既可纵向往SaaS层发展,面向C端或B端客户提供直接服务;也可横向拓展其他相关需求,提供一站式服务,成长为PaaS工具商店。其中在IM(即时通讯)等有集中需求的领域,后者较为凸显。说到即时通讯,我们可能会想到QQ、微信,其实你在直播平台上看主播表演、给主播打赏都属于即时通讯范畴,直播业务的高速发展使得IM云服务用户规模处于快速增长期,服务的稳定性和对用户的运维能力是决定IM云服务厂商能否进一步发展的重要因素。

去年被誉为“中国网络直播元年”,互联网、移动互联网的发展以及智能终端的普及为实现移动端直播提供了良好的基础,多元化的视频应用场景带来了新的商业模式与市场机遇,而直播云作为基础设施与服务的提供商也为直播行业的发展起到了极大的推动作用。随着技术进步与市场的不断扩大,视频云行业将会获得高速的发展,目前玩家主要有融云、环信、亲加等。

2016年12月,艾瑞发布的《2016年IM云服务行业白皮书》显示,根据艾瑞MuserTracker对即时通讯云服务厂商日活用户数的监测,融云日活跃用户数达4500万,日均消息量达300亿条,日消息量峰值超过 1000 亿条,全球 SDK 触达用户数突破 12 亿,以绝对优势稳居市场第一,并超出其它厂商数据总和,成为业内唯一一家经过数千万日活用户验证的即时通讯云服务商。新的一年到来,短短几个月过去,融云最新数据显示:融云日均活跃用户已突破5000万,消息峰值超过2000亿条、全球SDK触达用户数创下15亿+的惊人纪录。进步之快,令人感叹!融云的成功与其对技术的不断追求是分不开的,本文仅从其直播架构的演变过程角度,以窥一二。

融云直播架构演变过程

融云的直播互动系统架构自2014年上线以来,历经三次调整。本文将以融云直播体系架构演进过程,浅析IM云服务发展历程。

融云自2014年-2015年8月直播架构如下图,此架构特点为同一直播间用户会落到同一直播节点;业务与消息在同一服务中,主要存在问题是此架构单一直播间最大支持8000人,难以支撑更大的直播业务,显然与如今动不动就同时几百万人同时观看直播的现实相冲突。

直播架构1.0

直播架构1.0

为解决上述问题,融云2015年8月,开始使用下图架构。此架构中加入了直播消息服务模块,可按照同时在线规模进行线性扩容,解决最大支撑人数问题。此时,直播服务模块只负责用户的关系维护和消息上行,直播消息服务模块则负责消息分发和下行服务,其实是消息下行服务得到了升级,而上行并未升级,如此便会出现上行压力过大时,出现超时情况。因此此架构只使用了短短一个月时间便终止。

直播架构2.0

直播架构2.0

融云自2015年9月至今一直使用的是架构2.1,在此架构中,融云在业务层加入了上行控制服务,上行总量得以控制,直播压力大大降低,但此架构由于上行、下行流量都得到保证,必然对网络质量也有了更高要求。

直播架构2.1

直播架构2.1

网络质量对于直播可靠性的影响看过直播的你我都清楚,为了解决直播中网络的问题,融云先后采用了链路1.0和2.0架构。从图中可以看到,在链路1.0中,客户端和数据中心之间只有链接加速代理这一种加速机制,对专线依赖较高;而在2.0中,采取的是模拟CDN进行数据分发,专线内只跑上行消息和广播消息,降低了对专线的依赖,数据中心可进行链路选择,另外,融云了采用智能DNS、多接入点、多数据中心、多连接管理池、多集群等策略,保证每一个环节都提供冗余接入。

链路1.0

链路1.0

链路2.0

链路2.0

技术一定是不断进步的,创业型企业最大的财富在于可以深入群众,在与用户确切的切磋与你来我往中,发现真正的需求点和矛盾点,融云直播架构的衍变过程是与直播风口的来临、飞起相吻合的,一定程度上也反映了我国IM云服务的发展历程。从群众中来,到群众中去,也许说的正是这个道理。