BT

周梁伟:通信协议选型与三种类型的消息处理
录制于:

| 受访者 周梁伟 作者 InfoQ 发布于 2017年3月8日 | 欲知区块链、VR、TensorFlow等潮流技术和框架,请锁定QCon北京站!
20:50

个人简介 周梁伟,网易云信首席架构师。2011年加入网易,先后参与了云存储系统、日志采集平台、通用网站数据分析平台、易信后台等基础平台和产品系统的功能设计和开发;也从事过HBase集群运维,数据统计分析等大数据相关工作,对大数据技术在线上产品中的应用具有一定的实践;关注通用高性能服务器设计实现,大数据技术和IM类应用的相关技术和发展;目前作为云信系统架构师负责云信IM平台的架构设计和服务器研发团队。

QCon是由InfoQ主办的全球顶级技术盛会,每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来,已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

   

2. 您提到了"感谢非常多的开发者",网易云信的目前用户是企业级和开发者个体吗?

周梁伟:都有,根据最新的统计我们已经接入大概14万以上的开发者,覆盖5亿用户。

   

3. 云信的消息中间件是全部自己开发的,还是基于开源的项目,采用什么语言?为什么??

周梁伟:我们的很多服务之间都需要用到消息通信,这一块我们用的自己研发的一套消息通信服务NQS,这套NQS底层是基于开源的RabbitMQ做实例,上层做了一些服务化的事情,我们主要做的事情就是可以在私有云的平台里快速的建一些消息队列的实例,可以快速的扩容,更方便的做运维工作。云信使用NQS服务的时候,我们在上层又做了一层封装,主要考虑的点就是扩容,很多消息队列可能用户要做数据隔离,我们需要用不同的实例来做。实现语言主要是JAVA,一个是业界比较成熟,还有就是这块的从业人员非常多,我们公司也是以JAVA程序员为主的,选择更加成熟的技术或者语言对技术的传承会更好。

   

4. 当时为什么选择RabbitMQ?

周梁伟:RabbitMQ我们在测试的过程中发现它性能比较好,比较稳定,它是基于ERLANG实现的,对并发通讯能力方面特别强。

   

5. 能否评价一下MQTT和XMPP通信协议?为什么你们没有采用这些通信协议?

周梁伟:你说的这两个用的开发者也比较多,我们考虑到IM是我们的核心业务,当然如果开源的东西如果技术合适的话也很好,但是从我们的研究来看,像XMPP这样的协议,它是基于HTML的,消息量太大时整个数据包都变得非常大,针对移动互联网,我们要尽量帮助用户节省流量,所以这个不是很合适。MQTT是基于发布、订阅的模式,它本身可能对推送这样的应用场景比较合适,但是在IM里我们觉得适用性不是那么强,而且网易做IM业务已经做了很多年,有很多技术积累,这块我们已经沉淀出来一些比较稳定的技术架构了。

   

6. 你提到XMPP太大了不适合移动端,当时做PC的时候为什么不用?

周梁伟:也是同样的考虑,PC端的网络环境相对好一些,但是从我们的角度,要业务处理更快肯定消息量越小越好,所以会有这样的考虑。

   

7. 你们最开始做的时候是从移动端出发还是从PC端起步?

周梁伟:刚开始是PC端起步的,我们最早做的是网易泡泡,在这个过程中不断的做演化。

   

8. 不管是消息中间件还是协议,你们都做了很多定制化的事情,会考虑把这个开源出去吗?

周梁伟:网易这些年也在做一些开源方面的事情,但是就云信本身来说,因为云信是一个商业化的产品,商业化的产品如果很多技术做开源的话我们的客户会有顾虑。但是我们会把过程中沉淀的基础技术和基础服务,它跟我们的业务不是强绑定或者强依赖的关系,这部分以后可能会慢慢的有一些开源的东西放出来。

   

9. 您演讲中提到消息分为三类:Online、Nearline和Offline,您能谈谈这三种类型的消息对应的要求、技术处理和原因吗?

周梁伟:说到消息的这三个分类Online、Nearline和Offline,这三个术语是netflix在介绍它们的推荐系统的时候说的三个层次的不同维度的推荐组合方案,我在这里借用一下来描述在IM场景下的消息的运行。在消息里面我们为了保证消息不丢失或者消息快速到达或者消息是可追溯的,它是不同的时间维度来做的,在时间线上有一定的时效性。比如说Online消息,主要指如果用户在线的时候,消息发过去他马上能收到,对发送者来说当前如果在多个设备上登录了,我在一个设备上发出的消息或者收到的消息在另外的设备上能同步,这是应对办公场景的会话同步场景,这是Online的概念。Nearline主要应用在,比如用户当时处于离线状态,我发送消息他一会儿登陆才能看,它不是准实时但可以是接近实时的状态,这个是属于Nearline的。还有一种是如果我原来在另外一个设备上已经看到这个消息了,当我回到pc或者手机上要看这个消息的时候,它也可以从云端同步下来,这也是接近实时的一个Nearline的消息。Offline的时间线就更长了,特别是现在一些办公场景需要追溯三个月或一年以前的消息,这个时候它需要从云端去拉,它是一个纯离线的消息,它的消息量会非常多,用户关系又会非常复杂,存的时间限制很长,在这种情况我们会把它存到hbase里去,它的特点是读取会非常少,但是读取的时间线可以很长。

   

10. 对于这种Offline的消息你们在存储时有没有做一些压缩处理?

周梁伟:要做压缩,我们所有的消息存储时都会序列化然后压缩再存储,主要是两个方面考虑:一个是从性能方面考虑,还有一个方面是从安全方面考虑。

   

11. 这三类的消息对于网易云信造成的流量压力大概是什么样的比例呢?

周梁伟:压力其实并不会太大,对于我们来说,用户关心的比如说在线消息是一个实时送达的消息;Nearline消息主要是存在关系型数据库和缓存中,我们使用的都是一些横向扩展能力非常强的集群化的数据库方案和缓存方案,这块可以做水平拓展。还有一个就是对于历史消息来说,hbase本身就是应用于这种场景,所以基本上没有什么压力。

   

12. 网信云信的数据在公网传输是加密的,私网上你们是怎么做的呢?

周梁伟:我们在公网的加密级别是会话级别,也就是说加密数据只对当前长连接保持的会话是有效的,如果把这个加密方案带到私网中就会有问题,因为每个会话加密方案是不一样的。我们到私网怎么做呢?到私网以后这个消息会被解密,但是我们会做一层特殊处理,比如做压缩、做序列化。安全方面更多从另外的角度考虑,我们不会把它做加密,但是我们会控制能接触到这部分数据的人。比如说我们现在所有的服务都是通过自动的部署运维平台部署的,在这个部署平台上它部署时用的是一个独立的帐号,一般的开发者或者运维人员接触不到,如果要做一些特殊的运维操作会有特殊的审批流程。第二,在传输的过程中这个数据包本身只有程序可读,这也是一方面的考虑。在存储方面,我们存进去的数据也都有这样一些特殊的处理。近两年来我们发现有些网站出现被拖库,用户信息泄露的问题,所以我们在最初存储方案设计的时候就考虑了这些。

   

13. 一般情况下IM领域会受到的攻击有多频繁?有多严重?

周梁伟:我们进入IM领域之前就料到了可能会有这样的情况,但是实际情况有点超出我们的想象。现在云信遭受的攻击非常多,好在我们网易做互联网这么多年,积累下来的技术平台包括信息安全部门的技术积累非常强大,这部分的攻击在机房层面或者前端层面就已经被打掉了,对云信造成的影响相对很小。要说频率的话一周可能有好几次,攻击的方式和流量都不等,从一个侧面说明这个领域的竞争非常的激烈。当然根据我们的分析很多攻击也不是直接针对云信而是针对开发者,同一个行业的竞争非常的激烈。对很多创业团队来说,可能应对这种攻击的能力相对差一些,如果采用一些云服务或者安全保障更高的服务,帮他拦掉前端的攻击是一种比较好的解决方案。

   

14. 会不会有意识的差异,有的人可能认为上云反而是不安全的?

周梁伟:上云不安全他们顾虑更多的是什么?最早云计算的初衷是资源的共享,他们担心的是上云之后会不会抢占我的资源,导致服务不稳定,首先对于云这一块我们本身有一个QoS保障,能够保证你的计算资源独占,还有对于一些大客户,云信也提供了一些专有的、私有的方案,保证你的计算资源是独享的,是一个权衡的问题,毕竟做云计算的公司在基础设施方面投入会比较大一些!

   

15. 网易云信当前的架构是怎么演变的呢?过程中有没有重大的阶段性变化?

周梁伟:我们云信技术团队或者说网易公司在IM这块的技术积累最早是从做产品开始的,我们做过泡泡,做过最近的易信,在这个过程中积累了很多的经验,但是做产品和做云服务是不一样的。举例来说我们的产品应用是自己开发的,它的调用方式、调用频率、市场推广和用户增长模式都是可预测的,但是在云信这个云服务里面,我们的用户的用户是怎样的增长模式对我们来说是不可见的,所以在这种情况下架构肯定要做调整。主要考虑的是一方面服务需要做到动态的扩展,需要对服务内部做容量监控。正常情况下我们系统的容量会保持在相对比较低的水位下,以应对某些客户突然的流量的增长。还有一种就是要做限流,在我们的架构里,如果你做一个产品对限流这块可以不用太担心,因为你可以即时扩容。但是对于云服务来说,我们就要考虑这方面的因素,如果真的一旦突破流量限制怎么办?我们要保证现有用户的服务不受影响,所以这块在架构上的调整还是挺多的。

   

16. 为什么你们的架构采用了Nginx?有没有什么踩过的坑?

周梁伟:Nginx本身是一个比较通用的方案,现在也很成熟,各大公司都在用。网易内部也不是直接使用Nginx,而是封装了一层到我们的云计算环境里面,我们叫它NLB,它主要做一个负载均衡的功能。一般开发者使用Nginx可能是单独使用的,但是Nginx本身还是单点,虽然后端可以挂多个节点,有互备的方案,但是Nginx本身如果单节点部署的话还是有可能会挂,一般通用的方法可以在Nginx前面再做一个keep alive方案,单节点故障的时候通过ip漂移的方式做到平滑的处理。在我们公司内部,NLB做的很重要的一件事情就是这个,把负载均衡和高可用这套方案都集成化,可以在最短时间内重建、运维服务。

   

17. Nginx你们是从什么时候开始使用的呢,最开始的时候用的就是nginx吗?

周梁伟:Nginx比较标准,我们用的比较多!

   

18. 能否分享一下负载均衡上的经验?

周梁伟:从我的理解,负载均衡一个是业务对外、对客户端或者请求调用者来做,这是日常最常见的负载均衡。比如说http服务它进来的时候需要用到nginx或者HAProxy这类的负载均衡方案。有一些应用,像我们提供的一些长连接的服务,或者开发者自己做的一些第三方私有服务,负载均衡不是那么方便做,如果用通用方案可能是用HAProxy做四层的代理。如果没有办法用通用方案做,需要在应用层去考虑,在云信里面我们有一个接入网关的选择过程,这个过程是在应用层根据更多的选项和维度做连接地址的分发,这也起到了负载均衡的功能。往后走的话,在业务层之间也要有一个负载均衡的能力,我们叫它HA层,防止单点或单个业务集群出现故障的时候,对前端过来的用户流量不受影响,可以马上送到可用的另一个集群,再往后数据库层、缓存层每一层都应该要做这样的HA。

   

19. 是从什么时候开始意识到应该这样做的?

周梁伟:每一层都会做,对于网易云来说我们依赖的是整个网易云计算的基础设施,在网易云计算的基础设施里面缓存也好,数据库也好,都会先把HA的架构集成进去,保证提供的每一层的服务上都有QoS的要求。

   

20. 网易云信采用的是长连接机制,您能否谈谈对长连接的优缺点分析?服务器的整体性能、并发能力怎么优化呢?

周梁伟:长连接的话是这样的,我们做的是IM场景化的云服务,很重要的一点就是消息能否及时送达,如果不用长连接,而是短连接的话很难保证消息的及时性。缺点肯定有,基于tcp的长连接对网络情况比较敏感,特别现在很多是手机端的APP,移动互联网网络环境比较复杂,很多弱网环境,这种情况下怎么办?我们从多个角度做优化,首先在客户端上做优化,客户端跟服务器端会有探活,探活之后发现连不上会重连,用这样的机制来保证客户端的稳定性。服务器端也是一样,我们从多角度做,一个是尽量多的布点,我们的客户分布非常广,需要在各个地区布点,在一些边远地区布一些加速节点,保证用户能够在最近的地方找到接入点保证网络情况,这是从网络层优化来说的。

   

21. 客户端自动探活的频率是怎样的?

周梁伟:一般几秒钟就会探一次,他对长连接很敏感,如果客户端还没有发现连接已经断了,但是服务器那边可能已经掉下去了,它需要尽快发现来做重新连接。

   

22. 这个是固定的吗,还是和网络情况相关?

周梁伟:基本是固定的,但是重连的时候会有退避的机制。

   

24. 全国大概有多少个加速节点?

周梁伟:具体数目不方便透露,从使用情况看,一般的用户连接都没有问题。

   

25. 是按照用户的需求还是从地域角度来考虑的?

周梁伟:这是一个慢慢完善的过程,刚开始的时候,我们会做一些监测分析,发现某个地区用户量往上走,这时候那边可能会有压力,我们就去布点,慢慢的完善系统。

   

26. 这些加速节点都是网易运维来负责的吗?

周梁伟:对,我们的运维部门要负责,而且我们有一个完善的监控,如果某个节点出现故障或者网络不通都会有报警并会及时的处理,下线或者替换掉。

   

27. 你们每个节点做的时候都会有备份吗?

周梁伟:可以这么理解,但它可能不是一个完全意义上的备份,可能在一个地区有多个节点可以互相备份。

InfoQ:我们今天的采访就到这里,谢谢!

BT