浅谈云巴实时通信的编程模型

浏览: 146 发布日期: 2016-09-28 分类: erlang

概要

有人常问,云巴实时通信系统到底提供了一种怎样的服务,与其他提供推送或 IM 服务的厂商有何本质区别。其实,从技术角度分析,云巴与其它同类厂商都是面向开发者的通信服务,宏观的编程模型都是大同小异,真正差异则聚焦于产品定位,业务模式,基础技术水平等诸多细节上。本文暂不讨论具体产品形态上的差异,着重从技术角度浅谈实时通信的编程模型。

什么是实时通信

「实时」(realtime) 一词在语义层面上隐含着对时间的约束(real-time constraint),在工程上,我们习惯对「需要在一定时间内」 完成的操作称为「实时操作」。通常,实时可细分为 「软实时」(soft realtime),「准实时」(firm realtime)和 「硬实时」(hard realtime)。它们之间的差异,简单来说,就是对无法在指定时间区间内(deadline)完成事务的容忍程度。维基百科上对这三者有如下解释

  • Hard – missing a deadline is a total system failure.

  • Firm – infrequent deadline misses are tolerable, but may degrade the system's quality of service. The usefulness of a result is zero after its deadline.

  • Soft – the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service.

假如我们把无法按时完成任务(missing a deadline)称为异常事件,那么硬实时系统无法容忍异常事件;准实时系统则可容忍极少量的异常事件,但超过一定数量后系统可用性为 0;软实时系统可容忍异常事件,但是每发生一次异常事件,系统可用性降低。

综上所述,我们可以举例:

  • 火星上的无人探测器是硬实时系统,因为一次异常事件就极有可能导致探测器不可用,同理可类推核电站的监控系统,军用无人机系统,远程导弹的导航系统等一系列军工产品;

  • 金融交易系统是准实时系统,此类系统可容忍极少数的交易故障,一旦故障次数增加,系统就会陷入崩溃状态;

  • 短信 / 手机推送 / 电商购物等都是软实时系统。对于此类系统,用户都可以容忍异常事件,但是太多的异常事件则会大幅降低系统可用程度,用户体验急剧下滑。

就目前来说,绝大多数互联网产品(甚至可以说是 100%)都是软实时系统。云巴实时通信系统的目标则是要做一个高可用的软实时系统

一个最简单的实时通信编程模型

在软件工程中,很多复杂的项目其实都可以用一个非常简洁的模型来概括。正如爱因斯坦所说的:「一切都应该尽可能地简单,但不要太简单」(Everything should be made as simple as possible, but not simpler)。虽然这是描述物理世界的经验之谈,但同样适用于计算机领域,将物理世界的关系投射到某种人为语言(物理公式/计算机编程语言),其规律其实都是共通的。

让我们假设这么一个简单的场景:对 10 个客户端发送一条消息

这个需求其实可以用伪码表示为:

for (i..10) {
    send_message(get_socket(i))
}

如果下图所示:

"

在这个简单的需求下,我们只需要让这 10 个客户端分别跟服务器建立 TCP 连接(本文暂时只讨论 TCP 协议),然后遍历地发送消息即可。显而易见,这是一个 O(N) 复杂度的逻辑。

基于这个简单的模型,我们可以认为一条消息从发出到接收,有以下几个延时:

  • 网络延迟 ,一般是一个较为稳定的值,比如从北京到深圳,ping 延迟大约为 40 ms 左右;

  • 系统处理延迟,较之网络延迟,该值变化幅度较大,且可能因处理请求数的增加而急剧增大;

云巴实时通信系统以 200 ms 延迟作为总延迟标准,也就是说,假如网络链路是从北京到深圳,除去网络延迟的 40 ms,要想达到 200 ms 的通信时间,系统延迟必须小于 160 ms。

可以想象,当客户端数量达到一定数量级(比如百万级别)时,以上系统模型的实时性将面临极其严峻的考验。

分而治之

在海量用户下保持稳定的实时性,其实很多时候就只有一个手段:分而治之

图 1 表示的是单机处理情况。当单机的处理能力,带宽都无法应对客户端数量急剧增加的时候,我们就必须将线路进行分割。而且图 1 只体现了推送的意图(单向),但通信往往是一个双向的概念,综上,我们将 图 1 改成下面的 图 2

这样每台机器就可以处理符合其当前水位的连接。

在现实开发中,我们可能不仅仅满足于一个如此简单的消息系统,我们可能想要有离线消息,数据统计,数据缓存,限流等一系列操作,所以我们还可以再优化一下架构:

  • 将整体架构划分成业务逻辑层和数据存储层;

  • 数据存储层又可以根据存储数据类型的不同来进一步划分;

  • 前端可以单独划分一个网络接入层;

  • 数据包的流向可以用 MQ 来串联;

这样我们可以得到以下的图 3:

在这个模型中,网络接入层和消息业务逻辑层整体上应该是一个 stateless 的模块,可以较为轻松地做横行扩展。存储层作为一个有状态的模块,想要做到横行扩展是一件很不容易的事情。如果撇开这点来看,至此,这个模型理论上在应对海量用户的场景下应该是有效的。

通信协议和技术栈的选择

做一个消息系统,不可避免地要涉及到对通信协议的选择。我们在对通信协议的选择上,遵循以下几个原则:

  • 协议尽可能精简轻量,因为在系统设计之初我们就考虑了对物联网的支持,省电,节约流量都是目标之一;

  • 通用性好,扩展性强,方便后期做特性开发;

  • 协议在业界被广泛认可,且尽可能多的有不同语言的开源实现,以方便不同技术栈的客户做集成;

综上,我们没有重新自定义一份通信协议,而是选择了基于长连接MQTT。从很多角度来看,MQTT 非常适合做消息总线的通信协议,而且协议栈也足够轻巧和易于实现。云巴实时消息系统传输的消息体积较小(一般小于 4 KB),比如控制信号,普通聊天信息等。就这点上,针对物联网设计的 MQTT 有着天然的优势。后面,在不断地研究中我们又发现,MQTT 其实不仅仅适用于物联网场景,在很多要求低延迟高稳定性的非物联网场景也同样适用(比如手机端 app 推送,IM,直播弹幕等)。

从前面几个章节我们看到,云巴消息系统是一个典型的 IO 密集型系统。在出于开发效率和稳定的考虑下,我们选了 Erlang/OTP 作为主力开发语言。Erlang/OTP 作为一门小众开发语言(无论是国内还是国际),在应付这类 IO 密集型系统上,有着得天独厚的优势(可参考 RabbitMQ 这个基于 Erlang/OTP 的著名开源项目):

  • 基于 actor 的进程创建模型,可以为每个数据包创建一个 Erlang 处理进程,充分利用多核;

  • OTP 的开发框架抽象了分布式开发的许多细节,使得开发者在很小的心智负担下就能轻松快速地开发出功能原型;

  • Erlang/OTP 充分运用了容错思想,应对异常不是防,而是容,很多时候我们写出一些安全逻辑上有漏洞的代码,在 Erlang/OTP 上居然也能工作得好好的;

随着不断深入地使用 Erlang/OTP, 其性能问题也渐渐凸显出来。我们发现,当客户端请求量增加的时候,用 Erlang/OTP 写出的模块轻而易举地就可以将 CPU 跑满,从而让当前实例超负荷运转。很多时候出于成本上的考量,我们无法选择更多核数的机器来提升 Erlang 虚拟机运行的性能(此点未明确验证过),所以只好选择适度增加服务处理实例来缓解压力。

不过,通过对业务模块更细粒度的划分,我们可以将一些核心的小模块用 C/C++ 语言改写,在一定范围的复杂度内,可以有效提升整体处理性能。这也是我们接下来优化核心系统的思路之一。

MQTT 的 Pub/Sub 模型与高可用 KV 存储

MQTT 协议采用的是 Pub/Sub 的编程模型。其中有三个比较关键的动作:publishsubscribeunsubsribe。通过前面几个章节的讨论,我们又可以得到这么一个场景:

假如存在一个订阅量巨大的 topic(百万级),如何在单次 publish 中保证实时性 ?

其实,解决思路跟之前的场景是一致的:分而治之。我们必须通过某种策略对 topic 进行分片,然后将分片分发到不同的 publish 模块上进行处理。在一定的算法复杂度下,这个问题理论上是可以被有效解决的。于是,topic 的分片策略就成了高性能 publish 的关键。其实,如果想采用 MQTT 做海量消息系统,订阅关系的管理一定是无法绕开的大问题。它主要有以下几个设计难点:

  • 如果采用 KV 方式存储,如何设计数据结构 ?同上,我们要怎样去设计一种高效的 topic 分片存储策略;

  • 订阅关系的管理是 MQTT 消息系统的核心模块,假如这个存储模块失效,就必定会导致消息通信失败,从而让客户端收不到消息,这就必须要求这个模块一定是高可用的,也就意味着我们必须构建一个高可用的 KV 存储集群,该集群要能容忍一定程度的节点失效;

  • 冷热 topic 要有淘汰机制,要有一定策略将不活跃的 topic 定期淘汰到磁盘以节约内存容量;

  • KV 存储集群要能高效地动态扩容;

在很长一段时间的实践中,我们采用过好几种 KV 存储的集群方案,踩了不少坑,最后还是决定自己造轮子来开发一个高可用的 KV 存储模块。不过这又是一个很大的话题,我们将在后续博客中具体阐述我们的做法。

缺陷与不足

在团队发展初期,由于人力和时间等种种因素,我们把业务逻辑模块开发成了一个巨大的单体架构应用。在团队规模较小的情况下,单体架构的应用确实较好维护和开发,但随着新人的加入,单体架构则严重制约着特性开发和性能优化。从架构层面上来看,合理地划分更细粒度的模块,在性能和可维护性上采用微服务(microservice)设计模式,成了我们未来优化系统的方向之一。

总结

软件工程上有「没有银弹」(No Silver Bullet)这条金科玉律,用户选择云服务商亦是如此,绝对没有完美的第三方云服务商,每一家都可能存在明显的优点和缺陷。用户必须从自己应用场景和痛点出发,选择合适的后端服务。云巴将会在自己产品的核心竞争力上持续发力,精打细磨,吸取行业内的高效实践经验,打造出更加优秀的高可用实时通信系统。

返回顶部