写点什么

环信CTO:解析即时通讯云平台技术难点

2015 年 4 月 09 日

移动互联网时代,用户对于移动应用的各种功能的要求正变得越来越高,而即时通讯就是其中之一。环信长期致力于为用户提供优质的即时通讯云服务,帮助应用开发者提供个性化的即时通讯客户体验,在即时通讯领域拥有丰富的经验与过硬的技术实力。为了进一步了解国内即时通讯服务的发展,以及环信即时通讯云服务的功能与特点,我们特意邀请了环信CTO 马晓宇进行了专访。

InfoQ:您能否谈谈环信 IM 服务和客户自行搭建 IM 服务器的区别在什么地方,而环信的服务相比之下又具有什么样的优势?

马晓宇:我认为主要有三个区别:时间、系统容量、以及成本。

从时间来说,移动应用领域竞争激烈,产品生命周期即使不是以天为单位,那至少也是以周或以月为单位。用户如果自行研发一个即时通讯平台,平均需要几个月的时间。另外还要考虑到这个产品的发展问题,比如之前比较流行的匿名社交、匿名聊天室、匿名群组,如果用户自行开发的话同样需要几个月的时间,这对于一个移动应用来说显然是得不偿失的。

从系统容量上来看,如果起步阶段只有几万、几十万用户的话,那么自建 IM 服务器还是比较容易实现的,而且其中的一些技术还可以从其他地方借鉴。但是如果当用户数量达到几百万,甚至上千万的时候,自建服务的难度还是比较大的。以 QQ 为例,QQ 的发展从几十万用户,到上百万用户,再到上千万用户的过程当中,每个主要的版本都是彻底推倒重做的,如果一个移动应用真正能成功的话,真正在短时间内能达到几百万日活的话,就一定会对系统容量,对技术造成比较大的挑战,这并不是三、五个人在短时间内就可以完成的工作。

第三个区别,就是开发成本。成本又可以分为两个部分,一个是开发成本,包括技术团队成员的人工及工资成本了。当移动应用的用户量增长到比较大的时候,更大一部分的费用就体现在运维成本上了。以每百万长连接为一个基准,整个 IM 服务的资金成本大概从几万到十几万都有可能,如果用户考虑自建的话,很可能会比环信所提供的专业即时通讯服务的成本还要高很多。

InfoQ:能否从云服务的角度来谈一谈,现在很多现象级的应用可能在一段时间之内,它对于整个系统的负载可能会很严重,但是当用户数逐渐减少之后,又会出现计算资源的浪费的情况。那么这对于自行搭建 IM 服务器的用户来说,这又意味着什么呢?

马晓宇:这个问题首先要从我们服务商的角度来说,环信在云端有着各种各样的监控,如果突然有用户在给系统大量发消息的话,环信会以较快的速度来增加服务器来去完成消息的发送工作。推送也是一样,如果说有些消息给苹果用户推送不过来的话,环信同样也会增加服务器,环信的系统可以在较快的时间内完成动态调整,分钟级的部署现在也已经可以实现。

另一方面,不同的时段,用户的活跃度也是不同的。如果用户白天比较活跃,或者是晚间比较活跃的话,那么如果使用云服务,单用户的成本以及整体上的成本就都会降低很多,但如果自建服务器的话,就必须要按照峰值时间的需求进行准备,那么峰值范围以外的时间段整个系统都将闲置,就会造成很大的资源浪费。

InfoQ:能不能谈一谈,建立即时通讯云平台需要跨越的技术障碍是哪些?产品上线之后的运营过程中还会遇到哪些挑战?环信是怎样解决这些问题的?

马晓宇:在环信的创业探索过程当中,确实遇到过一些比较大的技术挑战,首先需要解决的就是后台的大数据高并发。环信每天需要处理的消息过亿,还要处理千百万的长连接。环信的具体作法是做系统拆分,将系统分成与用户长连接相关的连接服务器和无状态服务器两种,其中使用了 Erlang 语言,本身支持高并发,同时还内置有跨节点的分布式数据库,可以进行 session 同步。对于用户管理、推送等其他无状态服务来说,环信搭建了基于 Java 的后台服务,允许进行动态调配。

另外环信主要是一个实时系统,它将发送用户消息等实时业务与其他非实时的后台业务进行解耦,那些像数据统计等不影响前台用户体验的业务会进入消息队列,即便这些非实时业务出现问题,也不会影响到实时业务的运行。

很多应用每秒钟都会有几万甚至几十万的用户同时登录,在登录的过程中还要获取用户的基本信息以及好友列表,而环信为了提升登录的用户体验,缩短登录时间,因此为最近登录的用户存储了大量的后台缓存,而不用每次登录都需要访问数据库。从数据存储角度来说,环信后台主要的数据存储点基本上都是基于 Casssandra 数据库的,利用 NoSQL 来支持大规模的数据处理。

另外对于移动端,由于应用在移动设备里需要长期运行,所以环信也对内存占用进行了优化,尽量减少内存的占用量。比如用户有很多的消息对话,实际上其中只有最新的那一段对话是加载在内存里的,其他部分都已经做了置换以便节省内存。消息流量也是一样,环信对其进行压缩处理,在节省流量的同时,也优化了设备耗电量。

此外,用户的集成体验对于环信来说也是需要不断完善的。目前的解决思路是,为用户提供一个开源的 UI 模板,里面已经演示了如何调度不同的 SDK,如何登录、发消息、创建群组等等,便于用户将环信 SDK 更容易的集成到应用里,只需要直接添加代码就可以。另外一方面,环信还发现有些用户,可能更希望直接把 UI 整个拿过去使用,所以环信在开发 UI 的控件封装,将基本的聊天、单聊群聊做成一个控件,这样用户就不需要再去做一个新的对话窗口。

从运维角度上来看,环信同样采取了一些优化手段,比如一个 API 只能处在的一个合理的调用范围内,这样就可以避免某个用户进行大量频繁的异常调用。再比如某些用户需要群发消息,但对发送速度不做要求,这样的话系统就可以将这些消息放到慢速队列中,以避免影响快速队列以及真个系统的运行速度。

实际上,无论准备多么充分,意外还是会不时发生,所以环信也比较看重监控系统。当主要消息队列出现拥堵的时候,监控系统在报警的同时还能检测出问题出在什么地方,将会影响哪些用户的具体哪些操作。同时,环信系统在主要的连接点上都有降级开关,保证基本服务的运行不会受到影响。

环信还会每隔一两个月进行一次降级演习,模拟缓存、数据库、登录等故障的出现,以制定应急预案,这样在实际运行时出现相应问题时就容易处理了。

InfoQ:环信提供的是一种 PaaS 服务,对于云服务的用户来说,最关心的肯定是安全这个话题。那么环信在安全方面,以及保护用户隐私数据方面都做了哪些具体措施呢?

马晓宇:首先用户数据之间是隔离的,用户的数据是基于 Token 访问的,用户不能使用一个应用的身份验证去访问另一个应用里的数据。同样地,在同一个应用里面,环信也设置了两个不同访问权限,一个是管理员权限,而另一个则是普通用户权限。在普通用户权限下,是看不到管理员权限下的一些数据的。

从运维操作的角度来说,环信制定了严格的操作规范,后台工程师对数据库或者接口的访问权限是有严格限制的,只有特定的人才拥有相应的权限,所有的服务器登录操作都将记录到日志里。

另外,环信考虑过第三方服务的因素。由于环信本身是多租户系统,当与第三方云存储服务商合作的时候,就不能像一些个人云服务那样,所有的数据都是存储在一起,使用一个账号就能访问所有的数据。环信同样要求第三方云存储也要支持多租户系统,环信也会与合作伙伴一起在这方面进行并行开发与集成的工作。

简单的数据访问上,环信同样采取了一些保护措施。比如用户上传图片是通过 HTTPS 通道的。每个图片上传之后,环信会对应生成一个身份验证进行绑定,也就是说要想下载这张图片必须同时拥有正确的 URL 和身份验证,缺一不可。

InfoQ:一家企业的技术理念同样是企业文化的一部分,同时也会影响企业未来的走向。您能不能谈一谈环信的企业技术文化?

马晓宇:因为经历的原因,环信的几位创始人都曾进行过大量的开源项目开发工作。另外环信系统本身在消息对列、数据库等方面都在使用基础的开源服务,因此可以说,环信与环信的技术人员一直对开源文化情有独钟。

环信首先是希望做出一个能为用户提供价值的、技术上成功的开源架构软件系统。环信认为,在解决很多技术挑战过程中,肯定能够分析总结出一种通用的技术方案,最后形成一套完备的基本系统,再将这个系统开放给更多人,让更多的应用开发者受益。即使这一过程可能需要耗费环信几年的时间,但这对于热爱开源的技术人来说这并不算什么。

在团队管理上,环信也同样希望能采用一个开源软件开发的组织结构,逐步形成一个自管理的技术团队。比如环信的技术人员可以远程办公,自由安排工作时间,或者每年只有有两次到北京来和团队其他人员一起开会,平常直接以邮件等方式沟通,完全以开源软件的方法来维持整个团队的运作。这样的工作方式能够让员工的工作与生活联系的更紧密,同时也能激发员工的创造性思维。

InfoQ:您认为今年移动端云计算市场会出什么样的一些变化?哪些因素推动了这个移动端云计算市场变化的?

马晓宇:去年各种针对个人的服务比较多,而今年开始针对企业的服务会不断增加。尤其是企业 SaaS 服务,现在已经涌现出一批 SaaS 服务商正在进入市场,涉及的领域包括存储、安全、人力资源管理,甚至是统计表单等等。企业的 SaaS 服务将成为主流趋势,包括环信即将正式推出的移动客服在内,都是完全针对企业的一种 SaaS 服务。

InfoQ:从环信现有的用户来看,您认为哪些行业或者类型的应用会出现新的增长点呢?

马晓宇:从用户数量的增长速度来看,最热门的基本都是图片类的应用,这些应用不仅仅是用户增长快,而且用户的活跃度也非常高。另外,一些特定的垂直领域应用的用户粘性也比较大,比如动漫类的应用,当它增加了即时通讯功能以后,一天的消息流量就到了上千万条,这也证明此类垂直领域的应用还是比较受欢迎的。

InfoQ:您认为现在国内的即时通讯云市场与国外相比还存在哪些不足?需要在哪些方面进行改进呢?

马晓宇:国内现在的相关厂商不少,国外也有像 Layer 这样的公司。以 Layer 来举例,它的定价基本上是环信的 10 倍,这一方面说明可能美国用户在付费上的意愿比较高,而另一方面,也证明国内的市场竞争已经进入了白热化的阶段。但总体上来说,因为市场的规模比较大,所以基本上还是处于良性竞争的状态。在国内与国外厂商的差距上来看,目前还是有一些的,无论是商业环境还是人力资源上,环信以及国内厂商都处于劣势,尽管国外厂商技术人员的总数并不多,但如果每一个人都是精英翘楚的话就会变得很不一样了。因此技术人员的储备,进一步吸引世界级的工程师,也是环信接下来的方向,只有在人才上有所突破,才有可能真正走到国外去竞争更大的市场。


给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。欲了解更多环信资讯,欢迎访问环信专区

2015 年 4 月 09 日 08:4574999

评论

发布
暂无评论
发现更多内容

滴滴七层接入平台实践和探索

滴滴技术

运维 滴滴技术 微服务治理 七层接入

1.Flink检查点算法-15

小知识点

scala 大数据 flink

出自字节技术专家之手的SpringBoot全栈开发实战,真香

周老师

Java 编程 程序员 架构 面试

架构师训练营0期 第十二周作业

WW

数据分析之伯克森谬误:颜值和性格真成反比吗

KAMI

人生 数据分析 数据

在Rust里面嵌入python代码

lipi

Python rust

AtmoicXXX与AtmoicXXXArray源码分析

Darren

源码 内存布局 CAS java 并发 AtmoicXXX

滴滴云平台事业群——就是稳!

滴滴技术

招聘 滴滴技术 滴滴云平台事业群分享月

【Spring注解驱动开发】AOP核心类源码解析,这是最全的一篇了!!

冰河

spring aop ioc

我们一起学程序-五子棋

叫练

Java 多线程 游戏 websocket

Elasticsearch初步认识

枫林

Java elasticsearch ES

缓冲区溢出

C语言与CPP编程

c++ C语言 缓冲区 堆栈溢出

闲聊胡扯

C语言与CPP编程

随笔杂谈

滴滴Ceph分布式存储系统优化之锁优化

滴滴技术

云计算 分布式存储 Ceph 滴滴技术

腾讯大牛半年心血高级编程PDF,帮你轻松构建企业级Web应用

周老师

Java 编程 程序员 架构 面试

自定义线程池来实现文档转码

架构师修行之路

Redis做消息队列全攻略

架构师修行之路

redis MQ 消息队列

浮点数比较的精度问题

C语言与CPP编程

c c++

Docker 安装和简单使用

枫林

Docker

Docker -快速安装Elasticsearch

枫林

滴滴数据通道服务演进之路

滴滴技术

大数据 滴滴技术 数据服务通道

滴滴数据仓库指标体系建设实践

滴滴技术

大数据 数据仓库 滴滴技术

物联网的银河,华为的桨,少年的歌

脑极体

c语言函数指针之回调函数

C语言与CPP编程

C语言 回调函数 函数 函数指针

实时数仓在滴滴的实践和落地

滴滴技术

大数据 滴滴技术 数据通道服务

【高并发】要想学好并发编程,关键是要理解这三个核心问题

冰河

写作 多线程 高并发 同步 分工

指针变量的传值和传址

C语言与CPP编程

c++ 指针 C语言

C语言与C++常见面试题

C语言与CPP编程

c++ 面试题 C语言

Zeppelin SDK :Flink 平台建设的基石

Apache Flink

flink

C/C++函数指针与指针函数

C语言与CPP编程

c++ C语言 函数指针

你真的了解 Base64 吗

hepingfly

Java base64 编码

环信CTO:解析即时通讯云平台技术难点-InfoQ