马蜂窝旅游网的IM客户端架构演进和实践总结‘nba买球正规官方网站’

产品时间:2022-06-22 00:54

简要描述:

一、引言移动互联网技术改变了旅游的世界,这个领域已往极重的信息分销成本被大大降低。用户与服务供应商之间、用户与用户之间的相同路径逐渐买通,相同的场景也在不停扩展。这促使所有的移动应用开发者都要从用户视角出发,更好地满足用户需求。 论坛时代的马蜂窝,用户之间的相同形式比力单一,主要为单纯的回帖回复等。为了以较小的成本快速满足用户需求,其时接纳的是非实时性消息的方案来实现用户之间的消息通报。随着行业和公司的生长,马蜂窝确立了「内容+生意业务」的奇特商业模式。...

推荐产品
详细介绍
本文摘要:一、引言移动互联网技术改变了旅游的世界,这个领域已往极重的信息分销成本被大大降低。用户与服务供应商之间、用户与用户之间的相同路径逐渐买通,相同的场景也在不停扩展。这促使所有的移动应用开发者都要从用户视角出发,更好地满足用户需求。 论坛时代的马蜂窝,用户之间的相同形式比力单一,主要为单纯的回帖回复等。为了以较小的成本快速满足用户需求,其时接纳的是非实时性消息的方案来实现用户之间的消息通报。随着行业和公司的生长,马蜂窝确立了「内容+生意业务」的奇特商业模式。

nba买球正规官方网站

一、引言移动互联网技术改变了旅游的世界,这个领域已往极重的信息分销成本被大大降低。用户与服务供应商之间、用户与用户之间的相同路径逐渐买通,相同的场景也在不停扩展。这促使所有的移动应用开发者都要从用户视角出发,更好地满足用户需求。

论坛时代的马蜂窝,用户之间的相同形式比力单一,主要为单纯的回帖回复等。为了以较小的成本快速满足用户需求,其时接纳的是非实时性消息的方案来实现用户之间的消息通报。随着行业和公司的生长,马蜂窝确立了「内容+生意业务」的奇特商业模式。

在用户规模不停增长及业务形态发生变化的配景下,为用户和商家提供稳定可靠的售前和售后技术支持,成为电商移动业务线的当务之急。本文由马蜂窝电商业务 IM 移动端研发团队分享了马蜂窝电商业务 IM 移动端的架构演进历程,以及在IM技术气力和资源有限的情况下所踩过的坑等。

系列文章:《从游击队到正规军(一):马蜂窝旅游网的IM系统架构演进之路》《从游击队到正规军(二):马蜂窝旅游网的IM客户端架构演进和实践总结》(* 本文)关于马蜂窝旅游网:马蜂窝旅游网是中国领先的自由行服务平台,由陈罡和吕刚建立于2006年,从2010年正式开始公司化运营。马蜂窝的景点、餐饮、旅店等点评信息均来自上亿用户的真实分享,每年资助过亿的旅行者制定自由行方案。学习交流:- 即时通讯/推送技术开发交流5群:215477170 [推荐]- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》(本文同步公布于:http://www.52im.net/thread-2796-1-1.html)二、设计思路与整体架构我们联合 B2C,C2B,C2C 差别的业务场景设计实现了马蜂窝旅游移动端中的私信、用户咨询、用户反馈等即时通讯业务;同时为了更好地为互助商家赋能,在马蜂窝商家移动端中加入与会话相关的咨询用户治理、客服治理、运营资源统计等功效。

现在 IM 涉及到的业务如下:为了实现马蜂窝旅游 App 及商家 IM 业务逻辑、公共资源的整合复用及 UI 个性化定制,将问题拆解为以下部门来解决:1)IM 数据通道与异常重连机制:解决差别业务实时消息下发以及稳定性保障;2)IM 实时消息订阅分发机制:解决消息定向发送、业务订阅消费,制止不须要的请求资源浪费;3)IM 会话列表 UI 绘制通用解决方案:解决差别消息类型的快速迭代开发和治理庞大问题。整体实现结构分为 4 个部门举行封装,划分为下图中的数据治理、消息注册分发治理、通用 UI 封装及业务治理。三、技术原理和实现历程3.1、通用数据通道对于通例业务展示数据的获取,客户端需要主动提倡请求,请求和响应的历程是单向的,且对实时性要求不高。

但对于 IM 消息来说,需要同时支持吸收和发送操作,且对实时性要求高。为支撑这种要求,客户端和服务器之间需要建立一条稳定毗连的数据通道,提供客户端和服务端之间的双向数据通信。3.1.1 数据通道基础交互原理为了更好地提高数据通道对业务支撑的扩展性,我们将所有通信数据封装为外层结构相同的数据包,使多业务类型数据使用配合的数据通道下发通信,统一分发处置惩罚,从而淘汰通道的建立数量,降低数据通道的维护成本。常见的客户端与服务端数据交互依赖于 HTTP 请求响应历程,只有客户端主动提倡请求才可以获得响应效果。

联合马蜂窝的详细业务场景,我们希望建设一种可靠的消息通道来保障服务端主动通知客户端,实现业务数据的通报。现在接纳的是 HTTP 长链接轮询的形式实现,各业务数据消息类型只需遵循约定的通用数据结构,即可实现通过数据通道下发给客户端。数据通道不必体贴数据的详细内容,只需要关注吸收与发送。

3.1.2 客户端数据通道实现原理客户端数据通道治理的焦点是维护一个业务场景请求栈,在差别业务场景切换历程中入栈差别的业务场景参数数据。每次 HTTP 长链接请求使用栈顶请求数据,可以模拟在特定业务场景 (如与差别的用户私信) 的差别处置惩罚。数据相关处置惩罚都集中封装在数据通道治理中,业务层只需在数据通道治理中注册对应的吸收处置惩罚即可获得需要的业务消息数据。

3.2、消息订阅与分发在软件系统中,订阅分发本质上是一种消息模式。非直接通报消息的一方被称为「公布者」,接受消息处置惩罚称为「订阅者」。公布者将差别的消息举行分类后分发给对应类型的订阅者,完成消息的通报。

应用订阅分发机制的优势为便于统一治理,可以添加差别的拦截器来处置惩罚消息剖析、消息过滤、异常处置惩罚机制及数据收罗事情。3.2.1 消息订阅业务层只专注于消息处置惩罚,并不体贴消息吸收分发的历程。

订阅的意义在于更好地将业务处置惩罚和数据通道处置惩罚解耦,业务层只需要订阅关注的消息类型,被动等候吸收消息即可。业务层订阅需要处置惩罚的业务消息类型,在注册后会自动监控当前页面的生命周期,并在页面销毁后删除对应的消息订阅,从而制止手动编写成对的订阅和取消订阅,降低业务层的耦合,简化挪用逻辑。订阅分发治理会凭据各业务类型维护订阅者行列用于消息吸收的分发操作。3.2.2 消息分发数据通道的焦点在于维护多消息类型各自对应的订阅者荟萃,并将剖析的消息分发到业务层。

数据通道由多业务消息共用,在每次请求收到新消息列表后,凭据各自业务类型重新拆分成多个消息列表,分发给各业务类型对应的订阅处置惩罚器,最终通报至业务层交予对应页面处置惩罚展示。3.3、会话消息列表绘制基于差别的场景,如社交为主的私信、用户服务为主的咨询反馈等,都需要会话列表的展示形式;但各场景又不完全相同,需要分析当前会话列表的共通性及可封装复用的部门,以更好地支撑后续业务的扩展。3.3.1 消息在列表展示的组成结构IM 消息列表的特点在于消息类型多、UI 展示多样化,因此需要建设各种型消息和结构的对应关系,在收到消息后凭据消息类型匹配到对应的结构添加至对应消息列表。

3.3.2 消息类型与展示结构治理原理对于差别消息类型及展示,问题的焦点在于建设消息类型、消息数据结构、消息展示结构治理的映射关系。以上三者在实现历程中通过建设映射治理表来维护,各自建设列表存储消息类型/消息体封装结构/消息展示结构治理,设置对应关系关联 3 个列表来完成查找。

3.3.3 一次收发消息 UI 绘制历程各种型消息在内容展示上各有差别,但整体会话消息展示样式可以分为 3 种,划分是吸收消息、发送消息和处于页面中间的消息样式,区别只在于内部的消息样式。所以消息 UI 的绘制可以拆分成 2 个步骤,首先是建立通用的展示容器,然后再填充各消息详细的展示样式。拆分的目的在于使各种型消息 UI 处置惩罚只需要关注特有数据。

而如通用消息如头像、名称、消息时间、是否可举报、已读未读状态、发送失败/重试状态等都可以统一处置惩罚,降低修改维护的成本,同时使各消息 UI 处置惩罚逻辑更少、更清晰,更利于新类型的扩展治理。收发到消息后,凭据消息类型判断是「发送吸收类型」还是「居中展示类型」,找到外层的结构样式,再凭据详细消息类型找到特有的 UI 样式,拼接在外层结构中,获得完整的消息卡片,然后设置对应的数据渲染到列表中,完成整个消息的绘制。四、细节优化 & 踩坑履历在实现上述 IM 系统的历程中,我们遇到了许多问题,也做了许多细节优化。在这里总结实现时需要思量的几点,以供大家借鉴。

4.1、消息去重在前面的架构中,我们使用 msg_id 来标志消息列表中的每一条消息,msg_id 是凭据客户端上传的数据,举行存储后生成的。客户端 A 请求 IM 服务器之后生成 msg_id,再通过请求返回和 Polling 分发到客户端 A 和客户端 B。

当流程建立的时候,客户端 A 和客户端 B 通过服务端分发的 msg_id 来举行当地去重。但这种方案存在以下问题:当客户端 A 因为网络泛起问题,无法接受对应发送消息的请求返回的时候,会触发重发机制。此时虽然 IM 服务器已经接受过一次客户端 A 的消息发送请求,可是因为无法确定两个请求是否来自同一条原始消息,只能再次接受,这就导致了重复消息的发生。

解决的方法是引入客户端消息标识 id。因为我们已经依附旧有的 msg_id 做了许多事情,不计划让客户端的消息 id 取代 msg_id 的职能,因此重新界说一个 random_id。random_id = random + time_stamp。

random_id 标识了唯一的消息体,由一个随机数和生成消息体的时间戳生成。当触发重试的时候,两次请求的 random_id 会是相同的,服务端可以凭据该字段举行消息去重。4.2、当地化 Push当我们在会话页或列表页的情况下,可以通过界面的变化很直观地视察到收取了新消息并更新未读数。

但从会话页或者列表页退出之后,就无法单纯地从界面上获取这些信息,这时需要有其他的机制,让用户获知当前消息的状态。系统推送与第三方推送是一个可行的选择,但本质上推送也是基于长链接提供的服务。为弥补推送不稳定性与风险,我们接纳数据通道+当地通知的形式来完善消息通知机制。通过数据通道下发的消息如需到达推送的提示效果,则携带对应的 Push 展示数据。

同时会对当前所处的页面举行判断,制止对当前页面的消息内容举行重复提醒。通过这种数据通道+当地通知展示的机制,可以在应用处于运行状态的时间内提高消息抵达率,淘汰对于远程推送的依赖,降低推送系统的压力,并提升用户体验。4.3、数据通道异常重连机制当前数据通道通过 HTTP 长链接轮询 (Polling) 实现。

差别业务场景下对 Polling 的影响如下图所示:由于用户手机所处网络请求状态纷歧,有时候会遇到网络中断或者服务端异常的情况,从而终止 Polling 的请求。为能够让用户在网络恢复后继续会话业务,需要引入重连机制。在重试机制 1.0 版本中,对于可能泛起较多重试请求的情况,接纳的是添加 60s 内一连 5 次报错延迟重试的限制。详细流程如下:在实践中发现以下问题:1)当服务端突然异常并连续凌驾 1 分钟后,客户端启动执行重试机制,并每隔 1 分钟重发一次重连请求。

这对服务器而言就相当于遭受一次短暂集中的「攻击」,甚至有可能拖垮服务器;2)当客户端断网后连忙举行重试也并不合理,因为用户恢复网络也需要一定时间,这期间的重连请求是无意义的。基于以上问题分析革新,我们设计了第二版重试机制。此次将 5 次以下请求错误的延迟时间修改为 5 - 20 秒随机重试,将客户端重试请求疏散在多个时间点制止同时请求形成对服务器对瞬时压力。

同时在客户端断网情况下也举行延迟重试。Polling 机制修改后请求量划分,相对之前请求漫衍比力匀称,不再泛起集中请求的问题。4.4、唯一会话标识4.4.1 为何引入消息线 ID消息线就是用来表现会话的谈天关系,差别消息线代表差别工具的会话,从 DB 层面来看需要一个张表来存储这种关系 uid + object_id + busi_type = 消息线 ID。

nba买球正规官方网站

在 IM 初期实现中,我们使用会话设置参数(包罗业务泉源和会话参数)来标识会话 id,有三个作用:1)查找商家 id,获取咨询泉源,举行管家分配;2)查找已存在的消息线;3)判断客户端页面状态,决议要不要下发推送,举行消息提醒。这种方式存在两个问题:1)通过业务泉源和会话参数来剖析对应的商家 id,两个参数缺失一个都市导致商家 id 剖析错误,还要种种查询数据库才气获得商家 id,影响效率;2)通过会话类型切换接口标识当前会话类型,切换页面会频繁触发网络请求;如果请求接口发生意外容易引发消息内容错误问题,严重依赖客户端的结实性。

用业务泉源和会话参数资助我们举行管家分配是不行制止的,但我们可以通过引入消息线 ID 来绑定消息线的方式,替代业务泉源和会话参数查找消息线的作用。另外针对下发推送的问题已通过上方讲述的当地推送通知机制解决。

4.4.2 何时建立消息线1)当进入会话页发消息时,检查 DB 中是否存在对应消息线,不存在则将这条消息 id 看成消息线 id 使用,存在即复用;2)当进入会话时,凭据用户 id 、业务类型 id 等检查在 DB 中是否已存在对应消息线,不存在则建立消息线,存在即复用。4.4.3 引入消息线目的1)淘汰服务端查询消息线的成本;2)移除旧版状态改变相关的接口请求,间接提高了推送触达率;3)降低移动端对于用户消息匹配的庞大度。

五、展望及近期优化5.1、数据通道实现方式升级为 WebsocketWebSocket 是一种在单个 TCP 毗连上举行全双工通信的协议。WebSocket 使得客户端和服务器之间的数据交流变得越发简朴,允许服务端主动向客户端推送数据。在 WebSocket API 中,浏览器和服务器只需要完成一次握手,两者之间就直接可以建立持久性的毗连,并举行双向数据传输。

与现在的 HTTP 轮询实现机制相比, Websocket 有以下优点:1)较少的控制开销:在毗连建立后,服务器和客户端之间交流数据时,用于协议控制的数据包头部相对较小。在不包罗扩展的情况下,对于服务器到客户端的内容,此头部巨细只有 2 至 10 字节(和数据包长度有关);对于客户端到服务器的内容,此头部还需要加上分外的 4 字节的掩码。相对于 HTTP 请求每次都要携带完整的头部,开销显著淘汰;2)更强的实时性:由于协议是全双工的,服务器可以随时主动给客户端下发数据。

相对于 HTTP 需要等候客户端提倡请求服务端才气响应,延迟显着更少;纵然是和 Comet 等类似的长轮询比力,其也能在短时间内更多次地通报数据;3)保持毗连状态:与 HTTP 差别的是,Websocket 需要先建立毗连,这就使其成为一种有状态的协议,在之后通信时可以省略部门状态信息。而 HTTP 请求可能需要在每个请求都携带状态信息(如身份认证等);4)更好的二进制支持:Websocket 界说了二进制帧,相对 HTTP,可以更轻松地处置惩罚二进制内容;5)支持扩展:Websocket 界说了扩展,用户可以扩展协议、实现部门自界说的子协议,如部门浏览器支持压缩等;6)更好的压缩效果:相对于 HTTP 压缩,Websocket 在适当的扩展支持下,可以沿用之前内容的上下文,在通报类似的数据时,可以显著地提高压缩率。为了进一步优化我们的数据通道设计,我们探索验证了 Websocket 的可行性,并举行了调研和设计:近期将对 HTTP 轮询实现方案举行替换,进一步优化数据通道的效率。5.2、业务功效的扩展计划将 IM 移动端功效模块打造成通用的即时通讯组件,能够更容易地赋予各业务 IM 能力,使各业务快速在自有产物线上添加谈天功效,降低研发 IM 的成本和难度。

现在的 IM 功效实现主要有两个组成,划分是公用的数据通道与 UI 组件。随着马蜂窝业务生长,在现有 IM 系统上另有许多可以建设和升级的偏向。好比消息类型的支撑上,扩展对短视频、语音消息、快捷消息回复等支撑,提高社交的便捷性和趣味性;对于多人场景希望增加群组,兴趣频道,多人音视频通信等场景的支撑等。

相信未来通过对更多业务功效的扩展及应用场景的探索,马蜂窝移动端 IM 将更好地提升用户体验,并连续为商家赋能。附录:更多IM架构设计方面的文章《浅谈IM系统的架构设计》《简述移动端IM开发的那些坑:架构设计、通信协议和客户端》《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》《一套原创漫衍式即时通讯(IM)系统理论架构方案》《从零到卓越:京东客服即时通讯系统的技术架构演进历程》《蘑菇街即时通讯/IM服务器开发之架构选择》《QQ1.4亿在线用户的技术挑战和架构演进之路PPT》《微信后台基于时间序的海量数据冷热分级架构设计实践》《微信技术总监谈架构:微信之道——大道至简(演讲全文)》《如何解读《微信技术总监谈架构:微信之道——大道至简》》《快速裂变:见证微信强大后台架构从0到1的演进历程(一)》《17年的实践:海量产物的技术方法论》《移动端IM中大规模群消息的推送如何保证效率、实时性?》《现代IM系统中谈天消息的同步和存储方案探讨》《IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?》《IM开发基础知识补课(三):快速明白服务端数据库读写分散原理及实践建议》《IM开发基础知识补课(四):正确明白HTTP短毗连中的Cookie、Session和Token》《WhatsApp技术实践分享:32人工程团队缔造的技术神话》《微信朋侪圈千亿会见量背后的技术挑战和实践总结》《王者荣耀2亿用户量的背后:产物定位、技术架构、网络方案等》《IM系统的MQ消息中间件选型:Kafka还是RabbitMQ?》《资深架构师干货总结:一文读懂大型漫衍式系统设计的方方面面》《以微博类应用场景为例,总结海量社交系统的架构设计步骤》《快速明白高性能HTTP服务端的负载平衡技术原理》《子弹短信鲜明的背后:云信首席架构师分享亿级IM平台的技术实践》《知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路》《IM开发基础知识补课(五):通俗易懂,正确明白并用好MQ消息行列》《微信技术分享:微信的海量IM谈天消息序列号生成实践(算法原理篇)》《微信技术分享:微信的海量IM谈天消息序列号生成实践(容灾方案篇)》《新手入门:零基础明白大型漫衍式架构的演进历史、技术原理、最佳实践》《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》《阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史》《阿里技术分享:阿里自研金融级数据库OceanBase的艰辛发展之路》《社交软件红包技术解密(一):全面解密QQ红包技术方案——架构、技术实现等》《社交软件红包技术解密(二):解密微信摇一摇红包从0到1的技术演进》《社交软件红包技术解密(三):微信摇一摇红包雨背后的技术细节》《社交软件红包技术解密(四):微信红包系统是如何应对高并发的》《社交软件红包技术解密(五):微信红包系统是如何实现高可用性的》《社交软件红包技术解密(六):微信红包系统的存储层架构演进实践》《社交软件红包技术解密(七):支付宝红包的海量高并发技术实践》《社交软件红包技术解密(八):全面解密微博红包技术方案》《社交软件红包技术解密(九):谈谈手Q红包的功效逻辑、容灾、运维、架构等》《即时通讯新手入门:一文读懂什么是Nginx?它能否实现IM的负载平衡?》《即时通讯新手入门:快速明白RPC技术——基本观点、原理和用途》《多维度对比5款主流漫衍式MQ消息行列,妈妈再也不担忧我的技术选型了》《从游击队到正规军(一):马蜂窝旅游网的IM系统架构演进之路》《从游击队到正规军(二):马蜂窝旅游网的IM客户端架构演进和实践总结》《IM开发基础知识补课(六):数据库用NoSQL还是SQL?读这篇就够了!》>> 更多同类文章 ……(本文同步公布于:http://www.52im.net/thread-2796-1-1.html)。


本文关键词:马蜂窝,旅游网,的,客户端,架构,演进,和,实践,nba买球正规官方网站

本文来源:nba买球正规官方网站-www.bjtmcw.com

产品咨询

留言框

  • 产品:

  • 您的单位:

  • 您的姓名:

  • 联系电话:

  • 详细地址:

  • 留言内容:

在线客服 联系方式 二维码

电话

0886-285794660

扫一扫,关注我们