涨知识！从一个简单的消息服务，看云计算架构的真容

Posted 2020-08-22

一转眼，云计算已经十年了。十年间，从AWS亚马逊云开始，涌现了Salesforce、微软、谷歌、IBM、VMware、阿里、腾讯、网易等一批云计算服务商，从互联网公司到传统IT巨头都卷入了这场云计算的时代大潮中。Gartner数据显示，2016 年全球公有云服务市场规模有望达2,086 亿美元，较2015年的1,780 亿美元市场规模增长17.2%。

然而，虽然十年过去了，公有云市场也将超过2000亿美元规模，但很多人依然不明白，到底什么是云计算？云计算的架构与传统IT架构到底有何区别？本文就以一个看似非常简单的即时通讯云服务为例，看一看典型云计算架构的真实世界。该案例以网易云信的即时通讯云服务为实例，由网易云信首席架构师周梁伟在2016全球架构师峰会上介绍。

不同云服务场景中，消息也有很多种

【图一：具有不同时效性的消息】

可能有些人会说，消息不是很简单么？就是一个数据包，在接收方和发送方之间传输一下，不就这么回事儿嘛？但实际在云计算环境中有各种应用场景，包括即时通讯、CDN直播、在线客服等等具体的场景，不同的场景里有不同类型的消息。

从功能上来区分，可以分为带有多媒体文件的消息，需要在消息里内嵌采用了对象存储服务的文件以及提供上传下载功能，从而避免开发者接入第三方存储服务的麻烦；自定义消息，可以根据需求定制个性化消息功能，如阅后即焚、红包等。

从使用场景上区分，可分为单聊、群聊与聊天室等。对于单聊消息来说，只有单一接收者，且当接收者处于离线期间，有意义的消息也需要存储下来；对于群聊消息来说，每条消息都有多个接收者，而且也需要存离线消息；对于聊天室消息来说，只有在线消息，接收者是当时所有在聊天室的成员。

从时效上来区分，可分为发送者多端同步消息、Online在线、Offline离线、漫游消息和云端历史消息等。其中，发送者多端同步消息，指从发送者的角度，在任何一个端上发出的消息都会被实时同步到其它在线端上。Online消息主要指当有客户端在线时，消息直接投递到对方的设备上，需要秒级送达。Offline消息主要是为了保证消息不丢失，消息被存储在Cache和关系型数据库中，当上线之后可在第一时间获得到离线期间的未读消息。

漫游消息，这类消息不局限在单一设备上，只要通过账号登录，即使是在不同的设备上发生的消息，也能通过云端在其它设备中获取。云端历史消息，指存储在海量数据库中的历史消息，这类消息发生的时间可能已经很久，单位可以年来计算，它的访问频率低但存储量大。

由上述的几种消息类型的分法，就可以看到不同的消息适用于不同的应用场景和环境中，相互之间有着复杂的搭配与组合关系。

云计算架构的两大特征（1）：规模化并发与应用逻辑节点分离化

云计算最大的特点就是分布式计算，而且是互联网规模的分布式计算，这种计算模式在应用开发的架构上有两大主要特征：原有APP应用的逻辑节点的分离化与按着新逻辑的节点的集群化。

怎么理解？先看一个原有应用的逻辑及逻辑节点。以消息投递过程为例：

首先，要理解在每个IM客户端都会各自维护一条与服务器的长连接，各自的消息和信令都在这条长连接上传递，这是最基本的原理。

【图二：传统点对点型消息投递】

在图二中是一个点对点型的Link服务器，当发送者A发送一条消息之后，通过Link这条消息提交到APP中处理，APP中查询到该消息接收者B所在的Link服务器是Link y，于是向Link y服务器下发一条下行通知包，Link y上再找到用户B对应的长连接并将通知下发到客户端。

这种模式下，所有的接入点Link对于所有的用户来说都是对等的，可以接入到任何一个服务器中，任何消息的发送都必须在业务层查询到目标接收者所在的Link服务器，并往相应的Link服务器下发通知包。

因此，如果是一次群发行为，那就需要在业务APP上把所有群内的成员所在的Link列表都查询一遍；这是一个比较耗时的操作，并且是随着消息接收成员的数量不断上升而开销不断增大。所以如果需要往聊天室内发送消息，由于聊天室内的成员数量非常庞大，这种模式很快就会遇到性能瓶颈，消息投递的延时会非常严重。

【图三：多点对多点型广播型（例如聊天室）消息投递】

对于广播型的Link服务器，在分配接入点时要遵循一个原则：那就是同个聊天室内的成员在分配聊天室时，尽量分配在同一组接入点上；在Link上维护了每个房间内所有成员的长连接集合；在App上维护的不再是特定用户和Link之前的映射关系，而是维护了特定房间分配的Link集合。

于是任何一个成员发出一条聊天室广播消息之后，消息通过link上行到App，App只要找到该聊天室已经分配的Link地址列表，往每个Link上下发一个广播消息，Link在收到下行的广播消息之后再在本地做广播分发，这个效率比点播的模式高出了不止一个数量级。

通过这个对比，可以明显看到，针对聊天室这种特殊的场景采用广播的消息投递机制可以使消息并发能力得到指数级的增强：针对一个10000人的房间，假定同时只有1/10的人在发言，那每条消息会被广播给所有人，整体的消息并发就能达到百万千万量级。

而在广播模式中，将消息的分发拆解到了两个过程中：第一步先将消息从App投递到Link服务器中，这个过程每条消息只有一份；第二步是将消息通过Link服务器再次拆分后投递到本地最终的客户端上，这个过程在Link中直接完成。

因为作了节点的分拆，就可以在每个节点由单点对单点模型变为单点对多点甚至多点对多点，从而达到了规模化并发和分布式处理的效果。

云计算架构的两大特征（2）：应用弹性与分离后节点的集群化

在前面的广播型消息投递过程中，可以发现单个Link节点的业务压力非常大，消息的上行压力和下行压力也有同样的很大,不可避免得很快会遇到单个节点的性能瓶颈。怎么实现应用弹性？这就是集群化发挥作用的时候了。

集群化分为两步，第一步是消息在进出Web浏览器过程中的Web服务的集群化与优化。

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

针对这个问题，网易云信使用nginx（一种高性能的软服务器）作为前端代理，并把SSL的处理过程移到了nginx上，并使用性能较好的服务器来做nginx代理服务，而在后端WebLink上直接使用http协议，极大提升了后端节点的处理能力。通过这种代理方式，在4核8G的虚拟机上，单个节点的承载能力从1万连接数飙升至10万。

【图四：实际的互联网超大规模并发消息投递】

集群化的第二步是网络环境的集群化与优化。

在图四中可以看出，在网易云信实际的实践过程中，把Link服务器与APP之间再做了拆分，中间增加了网关接入层和路由层。

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

而应用业务层需要处理大量请求并负责数据库、缓存、队列、第三方接口等组件的交互，其稳定性、可用性和扩展能力直接影响了整个云服务的质量。为了使业务层具有更好的弹性，在网关接入层和业务层之间引入了一个路由层来解耦。业务节点在上线之后，会将自己注册到服务中心，路由节点会转接网关层的请求包，并从服务节点中挑选匹配的节点分发请求。因此，这种三层架构使系统整体具有更好的弹性。

为了提高业务的可用性，还会将业务节点分布到分属于不同网络的环境中，正常情况下可以同时提供服务，一旦其中一个环境的网络或者基础设施出现故障，可以快速得通过路由层来将故障集群下线。对于一些对资源独占需求比较强烈的应用或客户，可以通过路由层将该客户应用下的所有流量导入到独立的集群中。这样的模式还灵活支持灰度升级模式，可以将其中部分业务节点升级，然后通过路由层的配置将指定的用户流量导入到新升级的节点中。

【图五：实际案例数据】

以2016年某卫视中秋晚会现场活动为例，该晚会有一个在线评论区就是一个典型的聊天室，观众可以在其中发布自己的消息。这种场景的特点是突发流量非常高，用户几乎在同一时间连接到服务器上，发消息的行为也具有很强的突发性。针对这个特殊活动，云信分配了6台云主机作为长连接服务器，整个活动的活跃人数达到了50万，并发在线人数达到了10万多，广播消息的峰值在1000万每秒以上。

再以一个典型的在线秀场类型应用为例，开发者使用聊天室消息来发布文字和礼物等消息，这种使用场景的特点是每个房间的人数不会特别多，平均单个房间的同时在线人数在几百人左右；但是房间个数非常多，用户活跃行为没有突发性，却具有持续性。网易云信分配了10台云主机，承载的单日活跃人数达到百万+，并发在线用户数峰值也达到了10万以上，单日的消息总量2亿+。

支持千万级高并发消息的云服务架构

网易云信是网易公司集16年IM经验打造的即时通讯云服务（PaaS），也是网易云第一个开放给市场的云服务产品。网易云信从2015年10月13日上线至今，已成功接入15万+APP开发者，覆盖用户达到5亿+。在网络和区域上面覆盖了196个国家、567个地区，并保证100%的送达率。

开发者通过集成客户端SDK和云端OPEN API，即可快速实现强大的IM功能，网易云信全面支持android、ios、Web、PC等多平台。除了应对传统开发者的各项IM基本功能外，网易云信还提供了高级通讯功能，包括实时音视频、教学白板、互动直播、专线电话、短信、专属云在内的独家功能以及更多其他服务。

【图六：网易云信的架构图】

图六为网易云信的分层架构图，处于最下层的是客户端SDK覆盖了安卓、iOS、Windows PC桌面端、Web网页端和嵌入式设备等多种开发平台。在SDK层使用的网络协议有TCP协议和Socket.IO协议，后者专门用于Web SDK中提供长连接能力。A/V SDK是基于UDP协议的实时音视频SDK，用于实现基于网络的语音和视频通话。

再往上就是客户端直接接入并与服务器建立长连接的连接层，这里提供了Link服务，以及基于HTTP协议上API服务和LBS服务等，其中LBS服务用于帮助客户端SDK选取最合适自己的网关接入点，从而优化网络效率。

在网关接入层之上有一个路由层，这是一个比较有意思的负载均衡层，它在Link层和Service层之间解耦并提供高可用和易扩展等特性。在HA的具体实现方式上，提供了一个叫协议路由的服务，代为分发业务请求——路由层会按照预定义的规则将来自客户端的请求转发到相应的业务节点上，当业务集群扩容之后路由服务马上能发现新的可用节点，并将请求转发过去，当发现业务节点出现异常时也会被路由层标记并隔离下线以备替换。

在路由层上就是具体的业务节点集群，后端直连数据库、cache等各种基础服务，这个集群中节点的特点就是轻量级，并且每个节点都是无状态的。在实际部署这个集群时会跨网络环境部署，比如在同城双机房中分别部署一套业务服务节点，前端通过路由层来分发业务请求，平时正常时业务互为热备，平均分担线上的业务流量，当单一网络环境或者基础设施出现故障时马上会被路由服务检测到，并将该环境下的计算节点标记下线，将线上的流量请求全部转发到正常工作的集群中，从而提高了服务的整体可用性等。

最后在业务层之上，云信中提供了关键功能；包括核心的单聊消息、群聊消息和聊天室、通知等；以及用户信息托管，特殊关系管理等；还有面向API提供的如短信业务、回拨电话和专线会议等；还有实时音视频和直播功能等。

最右边的是从服务层上单独列出来的更重要的功能，包括与开发者应用的第三方数据同步、个性化的内容审核支持、超大群服务、登陆登出事件日志、漫游消息和云端消息历史功能、推送服务等等。

【上图：网易云信首席架构师周梁伟】

周梁伟介绍网易云信服务有三大特点：稳定、安全和快速。在稳定方面，网易云信的SDK采用长连接机制来实现，并且由SDK+心跳的方式来检测断线和自动做重连，同时针对移动网络等弱网环境，对SDK做大量的优化工作。对Web端，云信使用socketIO协议，实现长连接的同时也解决了浏览器的兼容性问题。

在安全方面，网易云信对所有在公网传输的数据都进行了加密，主要采用了流式加密。即客户端需要生成一个一次性使用的加密秘钥，并使用非对称加密方式将这个秘钥加密之后传给服务器，之后该加密秘钥被保留在该长连接的会话信息中，数据来往均使用该秘钥加密。经过实践，这种流式加密能够有效防止中间人攻击和数据包回放等攻击手段。

在快速方面，网易云信借助LBS服务，帮助客户端寻找到最适合自己的网关接入点。对频繁的前后台切换和重登陆这种移动客户端场景，SDK提供自动登录和重连等机制，即在UI界面起来的同时已经提前把消息通道建立。而在接入网关的选择策略中，通过并行来提升连接建立的速度。

周梁伟说网易云信不把自己定义为一个狭义上社交工具，云信可以定义为一个OTT，以即时通讯为切入，提供一个管道，用户通过网易云信的管道可以实现任何意义上连接服务，而不限于IM.可以是电商平台、社区、在线教育，也可以做任何一个想做的产品。云信不会集成账号，账号都是用户自己的。“因为网易云信就想做一个非常专业的‘管道’”，周梁伟说。

看到这里，读者应该对云服务有了新的认识。哪怕是看上去一个很简单的消息传递云服务，想要覆盖5亿+用户的并发需求，都不再是一件小事。（文/宁川）

本文出自 “云科技时代” 博客，请务必保留此出处http://cloudtechtime.blog.51cto.com/10784015/1880506