转载

三大措施助力连接提速 网易云信打造智慧IM云架构

三大措施助力连接提速 网易云信打造智慧IM云架构 编者按:互联网+时代,消息量级的大幅上升,消息形式的多元化,给即时通讯云服务平台带来了非常大的挑战。网易云信不仅能够完美支持千万数量级的高并发消息量,还与此同时做到了稳定和快速。这背后究竟有着什么样的架构和特性?

现在,更多面向衣食住行的应用产品早已具备即时通讯功能,即时通讯作为一个连接人与人的功能,在各个场景中都不可或缺。据《中国互联网络发展状况统计报告》显示,2016年6月中国即时通信用户规模达6.42亿人,网民使用率为90.4%。越来越多的企业和厂商正在进行转型,将会进一步拉动云服务市场的快速发展。企业级的IM云服务,作为最通用、最活跃、最刚性的需求,极有可能成为中国企业服务的入口级应用,同时也成为被国内众多巨头主力拓展的市场。CSDN采访了网易云信首席架构师周梁伟,针对企业级IM架构如何支持高并发且安全、稳定等话题做出了深入的探讨。

IM云市场,机遇与挑战并存

在如今互联网+的浪潮下,各产品在节奏快的情况下,选用IM云服务是必然趋势。这对IM云服务市场的各家平台,是一种机遇,同时也是一个全新高度的挑战。在互联网+时代,消息量级的大幅上升,消息形式的多元化,给IM云服务平台带来了非常大的挑战。如何支持更大数量级的高并发消息量,并能够做到稳定和快速,成为各IM云服务平台的重中之重。

“智慧IM云架构”—— IM云分层架构

周梁伟表示,网易正是看到了这一趋势,凭借在即时通讯领域长达16年的经验与技术积累,推出了网易云信即时通讯云服务(PaaS)。网易云信在用户的设备之间建立了一个可靠的端到端的连接,在不同的场景中用不同的方式投递消息,不同类型的消息会产生不同的消息行为,在网易云信的消息通道中有内容审核和数据同步。开发者通过集成客户端SDK和云端OPEN API,即可快速实现强大的IM功能,作为PaaS服务模式的网易云信全面支持Android、iOS、Web、PC等多平台。

周梁伟首先介绍下网易云信的技术框架,有助于大家系统的理解云信产品的设计思路:

三大措施助力连接提速 网易云信打造智慧IM云架构

• 客户端SDK层:SDK多平台适配、移动弱网络优化、安全加密压缩。

• 连接层:长连接管理优化、支持平滑升级、支持跨网络切换、广播分包。

• 路由层:用来解耦并提供高可用和易扩展等特性,同时提供协议路由服务,代为分发业务请求。

• 业务层:处理具体的客户端请求,并返回结果。提供后端直连DB、cache等各种基础服务。高可用,弹性扩展。

核心功能:连接

“IM服务架构最核心的功能就是“连接“,它需要解决的最基本的问题是稳定,安全和快速”,周梁伟对IM架构需求作出了明确说明。

稳定

网易云信的SDK采用长连接机制来实现,并且由SDK+心跳的方式来检测断线和自动做重连,同时针对移动网络等弱网环境,对SDK做大量的优化工作。对移动端/PC端,云信使用TCP来连接客户端与服务器。对Web端,云信使用Socket.IO协议,实现长连接的同时,也解决了浏览器的兼容性问题。

安全

网易云信对所有在公网传输的数据都进行了加密。在SDK与服务器的连接建立过程中有一个复杂的秘钥协商过程,客户端需要生成一个一次性使用的加密秘钥,并使用非对称加密方式将这个秘钥加密之后传给服务器,这个加密数据会被服务器解密,之后该加密秘钥被保留在该长连接的会话信息中,数据来往均使用该秘钥加密,这是一个流式加密,能够有效防止中间人攻击和数据包回放等攻击手段。对于web端则通过Https来保证Socket.IO协议的数据安全。

快速

网易云信借助LBS服务,帮助客户端寻找到最适合自己的网关接入点。同时,在连接建立之后,长连接的机制可以极大提升消息上下行的速度,并且在数据传输过程中,对数据包压缩传输,降低网络开销来提升消息收发的速度。对频繁的前后台切换和重登陆这种移动客户端场景,SDK提供自动登录和重连等机制,即在UI界面起来的同时已经提前把消息通道建立。在接入网关的选择策略中,通过并行来提升连接建立的速度。

连接层管理优化

消息快速到达的前提是客户端和服务器之间保持了稳定的快速的连接,所以连接层可以理解为奠定云信服务稳定性的基石。网易云信采取三大优化措施,全面助力连接层的提速和并发提升:

优化一:通过边缘节点优化网络拓扑

区域性网络问题是任何一个应用或者服务都会面临的问题,特别是对IM这类对于网络质量特别敏感的服务。网易云信通过部署区域性的边缘加速节点的方式来优化网络拓扑,提升网络质量。网易云信目前在海外,像美国,欧洲,中东和东南亚等很多国家和地区提供了这类边缘加速节点,加速节点和数据中心之间再通过专线等优质网络做互通,将整个用户链路中的关键路径替换成IDC之间的专线,大幅提升连接的稳定性和速度。通过优化,客户端到IDC中心的速度从之前的500+ms锐减至200ms,实现提速60%。同时,消息丢失率也从之前的20%+降低到0%。

优化二:场景化的消息分发机制提升吞吐率

点对点的消息分发模式非常依赖用户的在线状态。在消息分发过程中,一次在线状态的查询假定需要10ms,如果有100人发送消息,仅查询在线状态的开销就要1秒钟,并且这个时间开销还会随着消息接收人数的增加而成倍增加,再加上中间消息包的网络分发开销,这个消息处理的时间很快就会到达瓶颈。在聊天室场景下,这个问题就尤为突出。网易云信针对这种特殊的消息分发场景实现了一种消息分发的广播模式。假定一个100万人的聊天室,所有用户分布在10个连接节点上,一条广播消息在分发过程中只需要查询一次在线状态,并给每个Link分发一个广播包,到最终用户端的消息包由Link节点做内存拆包和下发,并且不同的节点之间可以完全并行处理。这种方式的消息分发使一个百万量级的消息分发任务可以在秒级处理时间之内完成,对消息接收者来说也能有效控制消息到达的延时情况。

优化三:集群化解决单节点性能瓶颈

通过组建集群来对业务处理能力做水平扩展是云信常用的一种方法。云信最初在设计针对Web浏览器的长连接服务器时,由于服务器既需要处理SSL编解码,请求包的格式转换,又要做长连接的管理,这直接导致了服务器性能很快达到瓶颈。特别是在用户侧的连接有比较频繁的重建的场景下,大部分的CPU资源都花在了SSL握手过程中。

连接建立之后,最终要的事情就是要开始做消息的分发投递了。为了应对聊天室这类特殊的消息场景,云信将消息的投递分拆到了两层上,并将大头计算量往前移到了连接服务器上;前置的连接服务器的压力会变大;针对这种情况引起的单个节点性能瓶颈,通过集群化和分离功能的方式来提升系统性能。

IM服务化和高可用

任何一个软件系统对数据库,存储平台和缓存平台等基础资源的依赖都非常强,这类基础平台资源的服务质量和强大的扩展能力会直接影响到整体系统的稳定性。云信集成了网易自研的分布式数据库,分布式缓存和对象存储服务等基础平台,使云信在面对业务扩容需求时更加从容。此外,云信还集成了如反垃圾云,视频云等面向具体业务的云服务,更加专业的团队来为云信的基础功能保驾护航。谈到网易云信作为即时通讯云平台的高可用性话题,核心功能保证99.99%的可靠性,一年不可用时长要小于52分钟,周梁伟解释要想要做到如此,必须做到以下两个方面:“第一、开发团队需要极高的运维意识,在开发设计时就注重应用的可用性和扩展性。第二,运维团队了解开发,通过专业的运维能力帮助开发规避风险。运维和开发相互合作,打造了云信的稳定。同时,容灾也是必不可少的。“

三大措施助力连接提速 网易云信打造智慧IM云架构

周梁伟讲解了云信的架构模式及逻辑关系:

网关接入层,负责客户端长连接的维护和管理,所有的接入节点甚至可以是无状态的对等节点,只负责客户端与服务器之间请求的传递的转发,并优化转发效率;网关接入层在实际部署时会同时分布到不同的网络环境中,比如分布在异地的两个机房中。

业务层,需要处理大量请求并负责和DB、缓存、队列,第三方接口等组件的交互,其稳定性,可用性和扩展能力直接影响了整个云服务的质量。为了使业务层具有更好的弹性,云信在网关接入层和业务层之间引入了一个路由层来解耦。业务节点在上线之后会将自己注册到服务中心,路由节点会转接网关层的请求包,并从服务节点中挑选匹配的节点分发请求,这种三层架构使系统整体具有更好的弹性。为了提高业务的可用性,云信会将业务节点分布到分属于不同网络的环境中,一旦其中一个环境的网络或者基础设施出现故障,云信可以快速得通过路由层来将故障集群下线。

支持灰度升级模式,云信可以将其中部分业务节点升级,然后通过路由层的配置将指定的用户流量导入到新升级的节点中。

专属服务的灵活支持,对于一些对资源独占需求比较强烈的客户,我们可以通过路由层将该客户应用下的所有流量导入到独立的集群中。

网易云信在云服务时代,不把自己定义为一个狭义上社交工具,云信可以定义为一个OTT,以即时通讯为切入,提供一个管道,用户通过网易云信的管道可以实现任何意义上连接服务,而不限于IM:可以是电商平台,可以是社区,可以是在线教育,用户可以做任何一个他想做的产品。

小结

网易云信从2015年10月13日上线至今,积累了大量的用户,非常多的开发者加入进来。据统计,云心已成功接入15万+APP开发者,覆盖用户达到惊人的5亿+。在网络和区域上面覆盖了196个国家,567个地区,并保证100%的送达率。除此之外,还获得了国内即时通讯云服务领域的首个CSA-STAR和ISO27001认证,并已拥有56项认证专利。云信作为一个场景化云服务提供者,本着便捷开发者使用的初衷,与大家共同创建即时通讯云的未来。

原文  http://geek.csdn.net/news/detail/129233
正文到此结束
Loading...