关键词：
一转眼，云计算已经十年了。十年间，从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
2021腾讯java面试题精选，涨姿势！
...#xff0c;包括使用场景和消息队列的功能特点，并设计了一个简单的消息队列。1.1系统间通信技术介绍1.2为何要用消息队列1.3消息队列的功能特点1.4设计一个简单的消息队列Part2消息协议介绍消息队列中常用的消息协议，包... 查看详情
从互联网+角度看云计算的现状与未来
...于是互联网+这个名词就随处可见了。支撑互联网化的一个重要的力量就是云计算，但现在的云已经外延被扩大的不知道到哪里去了，什么财务云，发票云等等等等ÿ 查看详情
云架构和openstack的思考
...的概念，慢慢发展成熟并能够推向市场，提供多种多样的服务， 查看详情
涨知识：java高级架构师年薪
字节跳动一面：自我介绍,主要讲讲做了什么和擅长什么看你项目做Spring比较多,问一下Spring相关的东西,IoC是什么概念?Bean的默认作用范围是什么?其他的作用范围?索引是什么概念有什么作用?MySQL里主要有哪些索弓|结构?哈希索... 查看详情
云计算的未来有多远？从阿里云看云计算会怎么样？
从商业逻辑看，互联网对传统企业的改造已经不再局限在信息以及渠道方面，而是在移动互联网时×××始真正开始影响企业的运营管理以及战略制定等方方面面。以不久前阿里云推出的数加为例，为传统企业提供了一站式云计算... 查看详情
openstack构架知识梳理
OpenStack既是一个社区，也是一个项目和一个开源软件，提供开放源码软件，建立公共和私有云，它提供了一个部署云的操作平台或工具集，其宗旨在于：帮助组织运行为虚拟计算或存储服务的云，为公有云、私有云，也为大云、... 查看详情
ros初探：ros架构
...构建程序文件。社区级（Communitylevel）：开源社区，共享知识、算法和代码等。1.1计算图级计算图级包含：节点、节点管理器、参数服务器、消息、服务、主题和消息记录包。节点（node）：主要的计算执行进程， 查看详情
asp.netcorewebapi下事件驱动型架构的实现：一个简单的实现
...架构。这个问题看上去有点大，其实主要目标是为了实现一个基于ASP.NETCore的微服务，它能够非常简单地订阅来自于某个渠道的事件消息，并对接收到的消息进行处理，于此同时，它还能够向该渠道发送事件消息，以便订阅该事... 查看详情
从rocketmq到kafka
参考技术A在基于了解或掌握其他同类MQ的基础知识上，怎么比较快速的掌握kafka的核心设计，确保在使用的过程中做到心中有数，做到知其然并知其所以然？本篇文章主要是笔者在已有的rmq的基础上学习kafka的思路以及过程的总... 查看详情
关于高性能负载均衡架构，这些知识点大多数人不知道
单服务器无论如何优化，无论采用多好的硬件，总会有一个性能天花板，当单服务器的性能无法满足业务需求时，就需要设计高性能集群来提升系统整体的处理性能。高性能集群的本质很简单，通过增加更多的服务器来提升系统... 查看详情
什么是云计算架构和组件
...在多个硬盘和计算机上的文件系统。数据永远不会存储在一个地方，如果一个单元发生故障，另一个单元将自动接管。用户磁盘空间在分布式文件系统上分配，而另一个重要组件是资源分配算法。云计算是一个强大的... 查看详情
kafka架构及基本原理简析
参考技术A Kafka是一个由Scala和Java编写的企业级的消息发布和订阅系统，最早是由Linkedin公司开发，最终开源到Apache软件基金会的项目。Kafka是一个分布式的，支持分区的，多副本的和多订阅者的高吞吐量的消息系统，被... 查看详情
简单了解什么是微服务架构
微服务与微服务架构微服务：? 从字面意思理解，它就是一个小的服务，是为了解决某个问题或是完成一个具体功能而落地实现的某个服务应用，可以简单理解为IDEA里面的一个Moudle。微服务架构：? 简单来说，它就是一种架构... 查看详情
go语言实现简单的聊天室(代码片段)
...服务器发送消息；接收服务器的广播消息；注意事项：某一个客户端断开连接后需要从连接池中摘除，并不再接收广播消息；某一个客户端断开连接后不能影响服务器端或别的客户端的连接；详细的代码如下，文档看注释就好了... 查看详情
kafka和rabbitmq比较之基础知识部分
参考技术A1.LinkedIn起初设计的基于Zookeeper协调的分布式消息系统。将消息持久化到磁盘中。2.一个典型的Kafka体系架构包括若干Producer、若干Broker、若干Consumer，以及一个ZooKeeper集群。3.Producer：生产者，消息发送方。4.Consumer：消费... 查看详情
openstack架构知识梳理(代码片段)
OpenStack既是一个社区，也是一个项目和一个开源软件，提供开放源码软件，建立公共和私有云，它提供了一个部署云的操作平台或工具集。包括OpenStack计算（代号为Nova），OpenStack对象存储（代号为Swift），并OpenStack镜像服务（代... 查看详情
涨知识！mysql字段长度过长
1.CAP的由来要理解CAP，首先我们要清楚，为何会有人提出CAP？他提出CAP是为了解决什么问题？时间回到1985年，彼时，后来证明了CAP理论的Lynch教授此时给当时的IT界来了一记惊雷：她通过不可辩驳的证明... 查看详情
网易消息推送系统微服务化实践
...本文给大家带来的分享。困扰和烦恼首先来看下我们其中一个平台之前的大体架构：随着业务的递增，我们遇到了以下的问题：什么是服务发现？在分布式微服务架构中，一个应用可能由一组职责单一化的服务组成。这时候就需... 查看详情