Jack Jiang

我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
posts - 478, comments - 13, trackbacks - 0, articles - 1

2024年8月2日

本文来自微信团队工程师方乐明的技术分享,由InfoQ编辑发布,下文有修订和改动。

一、引言

微信红包业务量级的高速发展,对后台系统架构的可用性要求越来越高。在保障微信红包业务体验的前提下,红包后台系统进行了一系列高可用方面的优化设计。

本次分享介绍了微信红包后台系统的高可用实践经验,主要包括后台的 set 化设计、异步化设计、订单异地存储设计、存储层容灾设计与平行扩缩容等。听众可以了解到微信红包后台架构的设计细节,共同探讨高可用设计实践上遇到的问题与解决方案。

补充说明:本文对应的演讲PPT详见《微信红包系统可用性设计实践(PPT) [附件下载]》。

技术交流:

二、分享者

方乐明:现任微信支付应用产品系统负责人,主要从事微信红包、微信转账、微信群收款等支付应用产品的系统设计、可用性提升、高性能解决方案设计等,曾连续多年负责春节微信红包系统的性能优化与稳定性提升,取得良好的效果。

三、系列文章

系列文章目录:

四、微信红包介绍

微信红包从 2014 年开始发展到现在,中间经历了几年时间。在这几年的时间里,整个系统可用性产生了很大的提升。2015 年年初的时候,每天晚上九点钟是微信红包的业务高峰期,系统经常性地出现性能问题。到了今天,即使在节假日高峰期,系统也不会出现问题。

▲ 红包印象 – 产品形态(点此查看本图出处

如上图所示,微信红包的业务包含包、发、抢、拆、查询发送红包和收红包数量,其中最关键的步骤是发红包和抢红包。

微信红包是微信支付的商户,微信红包这个商户出售的是钱。发红包用户在微信红包平台使用微信支付购买一份钱,微信红包将钱发放到相对应的微信群。群里的用户抢红包得到微信零钱。这个过程中,微信红包和微信支付之间的关系是商家和第三方支付平台的关系。

微信红包和微信支付之间的交互,与普通商家与微信支付的交互一样,需要经过六个步骤。用户发红包时,进入微信红包下一笔订单,系统记录发红包用户、发红包金额、红包数量和要发送到的用微信群。然后微信红包系统请求微信支付服务器进行下单,用户使用微信支付进行支付。

支付成功后,微信支付后台系统通知微信红包后台系统支付成功结果,微信红包后台系统收到通知后推送微信红包消息到微信群。微信群里用户便可抢红包。这就是微信红包和微信支付的关系以及交互过程。

五、微信红包系统架构

5.1 微信红包的系统流程

▲ 微信红包的系统流程(点此查看本图出处

上图是微信红包系统角度上的流程,业务主流程是包、发、抢、拆四个操作,每个操作包括几个关键步骤。

包红包:系统为每个红包分配一个唯一 ID,即红包发送订单号,然后将发红包用户、红包个数、红包数额写入存储,最后去微信支付下单。

发红包:用户使用微信支付完成付款,微信红包后台系统收到微信支付系统的支付成功通知。红包系统将红包发送订单状态更新为用户已支付,并写入用户发红包记录(用户发红包记录,就是微信钱包中,查看到的用户每一年总共发出及收到的红包记录)。最后微信红包后台系统发送微信红包消息到微信群。

抢红包:指微信群里的用户收到微信红包消息后,点开红包消息。这个过程,微信红包后台系统会检查红包是否已被抢完,是否已过期,是否已经抢过。

拆红包是最复杂的业务是操作,包括:

  • 1)查询这个红包发送订单,判断用户是否可拆,然后计算本次可拆到的红包金额;
  • 2)然后写入一条抢红包记录。如果把拆红包过程,类比为一个秒杀活动的过程,相当于扣库存与写入秒杀记录的过程;
  • 3)更新库存对应于更新红包发送订单,写入秒杀记录对应于写入这个红包的领取红包记录;
  • 4)另外,还要写入用户整体的红包领取记录;
  • 5)最后请求微信支付系统给拆到红包用户转入零钱,成功后更新抢红包的订单状态为已转账成功。

5.2 微信红包的整体架构

▲ 微信红包的系统架构(点此查看本图出处

上图所示,是微信红包的系统架构。包括微信统一接入层,下面是微信红包系统 API,包括发、抢、拆、查红包详情、查红包用户列表。再下面是封装微信红包关键业务的逻辑服务;最下面一层是数据存储层,微信红包最主要的数据是订单数据,包括发红包订单和拆红包订单两部分。业务逻辑和存储服务器之间是数据接入层,它最重要的作用是封装数据库操作的领域逻辑,使得业务逻辑服务不需要感知对 MySQL 的连接管理、性能、容灾等问题。

微信红包数据的访问热度,随着时间流逝会急剧降低,也就是数据的访问时间段非常集中,一般红包发出三天后,99% 的用户不会再去点开这个红包了。因此微信红包系统采取按时间做冷热数据分离,降低数据的存储成本,同时提升了热数据的访问性能。

数据平台用于对红包数据的分析计算,比如朋友圈里的文章,统计从 某年 1 月 1 日到 2017 年 1 月一个用户总共抢红包的金额,在全国的排名情况,发红包数最多的城市等。另外一个作用就是对账,红包的订单和微信支付的订单需要对账,以保证最终资金的一致性;订单的数据和订单的 cache 需要做对账,以保证数据的完整性;订单数据和用户的收发记录需要对账,以保证用户列表完整性。

六、微信红包系统可用性实践

6.1系统可用性影响因素

系统的可用性影响因素可分成两类:

  • 一类计划外;
  • 一类计划内。

计划外包含很多因素,系统用到的所有东西都可能产生故障,都可能成功影响可用性的因素。从这个角度上来讲,可以说故障是无法避免的,系统的运作一定会产生故障,尤其是服务器有成千上万个的时候。计划内的影响因素,主要有与升级相关、运维相关的操作,以及日常的备份等。这一类影响因素,通过精细地设计方案,是可以避免对可用性造成影响的。

6.2微信红包系统可用性设计方向

基于上面两个分析结论,可以总结出微信红包后台系统的可用性的设计方向。就是在不能避免意外故障的情况下,尽可能降低出现意外故障时对可用性的影响。另一方面,绝大多数计划内的日常维护可以通过方案的设计避免影响可用性,其中平行扩容特指关于存储层的平行扩容。

下面从降低故障影响和微信红包系统的平行扩容两方面进行分析。

首先是降低意外故障的影响,重点讲解订单存储层在订单 DB 故障的情况下如何降低对红包系统可用性的影响。

6.3业务逻辑层 - 部署方案设计

首先是业务逻辑层的部署方案。业务逻辑层是无状态的,微信红包系统的业务逻辑层,部署在两个城市,即两地部署,每一个城市部署至少三个园区,即三个 IDC。并且每个服务需要保证三个 IDC 的部署均衡。另外,三个 IDC 总服务能力需要冗余三分之一,当一个 IDC 出现故障时,服务能力仍然足够。从而达到 IDC 故障不会对可用性产生影响。

6.4业务逻辑层 - 异步化设计

▲ 业务逻辑层 – 异步化(点此查看本图出处

第二是异步化设计。如上图所示,微信红包的某些步骤不实时完成也不会影响用户对红包业务可用性的体验。比如拆红包,正常的业务流程很长,但关键步骤只有订单相关的几步。至于转零钱、写红包记录等操作不需要实时。用户抢到红包时,一般不会实时去钱包查看微信零钱,而是在微信群中点开消息查看本次抢到金额和他人抢红包金额。所以拆红包时只需要从 cache 查询用户是否拆过红包,然后写入拆红包的订单记录,更新发红包订单,其他的操作都可以异步化。当然,不是每个业务都可以进行异步化设计,需要进行业务分析,判断是否存在非关键步骤之外的事情可以将其异步化,并通过异步对账保证最终一致。

▲ 订单存储层 – 早期架构(点此查看本图出处

接下来是微信红包订单存储设计。上图是 2014 年微信红包存储层的模型。业务逻辑层请求数据层操作时,使用订单号 hash 路由到订单 SERVER。订单 SERVER 与每一组 MYSQL 数据库连接。

微信红包的订单号是在发红包时系统生成唯一标识,使用序列号服务生成唯一 ID,后面拼接三位微信红包的订单分库表的标识。所以,总共可以分一百个逻辑库,每个逻辑库含有十张表。一百个逻辑库均匀地分布到十组物理 DB,每组 DB 存十个逻辑库。

这个架构的最大问题是,一组 DB 故障时,会影响其他 DB。2014-2015 年期间,微信红包量涨得特别快,扩容速度跟不上业务增长速度。一组 DB 的性能出现瓶颈时,数据操作变慢, 拆红包的事务操作在 MYSQL 排队等待。由于所有十组 DB 机器与所有的订单 SERVER 连接,导致所有的订单 SERVER 都被拖住,从而影响红包整体的可用性。这个架构的另一个问题是扩容不方便,后面会介绍。

为解决 DB 间的相互影响,需要将 DB 间相互隔离,订单存储层 SET 化。SET 化指订单 DB 和订单接入 SERVER 垂直 stick 一起。业务逻辑层访问订单时,根据订单倒数第二、三位数字找到所属订单 SET,一个 SET 的请求不能路由到其他 SET。

找到对应的订单接入服务器之后,在服务器内的多个进程中找到指定进程,让同个红包的所有拆请求串行化。当一组 DB 出现故障,只会影响该组 DB 对应的 SERVER。

这里有一个问题,DB 故障拖住某些订单 SERVER,会不会也拖住更上层业务逻辑服务?业务逻辑层为什么不一起 SET 化?业务逻辑层承载了用户维度相关的业务操作,不可以按照订单的维度分业务逻辑,例如务逻辑层会请求用户的头像、昵称等,如果继续按照订单分业务逻辑,会导致跨地域调用。

微信红包系统采取的方案是,在订单 SERVER 服务端增加快速拒绝服务的能力。SERVER 主动监控 DB 的性能情况,DB 性能下降、自身的 CPU 使用升高,或者发现其他的监控维度超标时,订单 SERVER 直接向上层报错,不再去访问 DB,以此保证业务逻辑层的可用性。

一组 DB 故障不会影响整个系统的可用性。有影响的,只有十分之一,若扩成 100 组,影响便只有一百分之一。所以通过 SET 化得到的好处是,控制 DB 连接数、隔离故障影响和分流并发。

▲ 订单存储层 – 故障自愈(点此查看本图出处

完成 SET 化之后,DB 故障仍对业务有十分之一影响,那么这十分之一该怎么解决?通过对系统进行研究分析之后,发现 DB 可以做到故障自愈。

如上图所示,所设尾号 90-99 的 SET 故障时,如果业务逻辑服务后续不再生成属于这个 SET 的订单,那后续的业务就可以逐渐恢复。

也就是在发生故障时,业务逻辑层发布一个版本,屏蔽故障号段的单号生成,就可以恢复业务。进一步想,除了人为发版本,有没有方法可以让 DB 故障时自动恢复?在 DB 故障导致业务失败时,业务逻辑层可获取到故障 DB 的号段,在发红包时,将这些故障的号段,换一个可用的号段就可恢复业务。订单号除了最后三位,前面的部分已能保证该红包唯一性,后面的数字只代表着分库表信息,故障时只需要将最后三位换另外一个 SET 便可自动恢复。

完成这个设计后,即使 DB 出现故障,业务的可用性也不会有影响。这里还有一点,新的发红包请求可避免 DB 故障的影响,但那些故障之前已发出未被领取的红包,红包消息已发送到微信群,单号已确定,拆红包时还是失败。对这种情况,由于不会有增量,采用正常的主备切换解决即可。

6.5平行扩缩容设计

▲ 平行扩缩容 – 早期方案(点此查看本图出处

上图是微信红包早期的扩缩容方式。这个扩容方式,对扩容的机器数有限制。前面讲到,红包系统按红包单号后面两个数字分多 SET,为了使扩容后数据保持均衡,扩容只能由 10 组 DB 扩容到 20 组、50 组或者 100 组。另外,这个扩容方式,过程也比较复杂。首先,数据要先从旧数据库同步复制到新扩容的 DB,然后部署 DB 的接入 SERVER,最后在凌晨业务低峰时停服扩容。

这个扩容方式的复杂性,根本原因是数据需要从旧 SET 迁到新 SET。如果新产生数据与旧数据没关系,那么就可以省掉这部分的迁移动作,不需停服输。分析发现,需要把旧数据迁出来的原因是订单号段 00-99 已全部被用,每个物理数据库包含了 10 个逻辑库。如果将订单号重新设计,预留三位空间,三位数字每一个代表独立的物理 DB,原来 10 组 DB 分别为 000-009 号段。

这种设计,缩容时,比如要缩掉 000 这组,只需在业务逻辑服务上不生成订单号为 000 的红包订单。扩容时,比如扩为 11 组,只需多生成 010 的订单号,这个数据便自动写入新 DB。当然,缩容需要一个前提条件,也就是冷热分离,缩容后数据变为冷数据,可下线热数据机器。以上就是红包的平行扩缩容方案。

▲ 改进后的平行扩容(点此查看本图出处

七、写在最后

微信红包系统的可用性实践,主要包括了部署设计、SET 化设计、异步化设计、DB 故障自愈能力建设、平行扩容设计。在完成这些设计后,微信红包系统的可用性得到了很大提升,在 近几年的春节实现了 0 故障,在平常的运行中达到 99.99% 可用性。

(原文链接:点此进入

八、更多鹅厂技术文章汇总

微信朋友圈千亿访问量背后的技术挑战和实践总结

腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)

腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)

IM全文检索技术专题(二):微信移动端的全文检索多音字问题解决方案

腾讯技术分享:Android版手机QQ的缓存监控与优化实践

微信团队分享:iOS版微信的高性能通用key-value组件技术实践

微信团队分享:iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的?

腾讯技术分享:Android手Q的线程死锁监控系统技术实践

微信团队原创分享:iOS版微信的内存监控系统技术实践

让互联网更快:新一代QUIC协议在腾讯的技术实践分享

iOS后台唤醒实战:微信收款到账语音提醒技术总结

腾讯技术分享:社交网络图片的带宽压缩技术演进之路

微信团队分享:视频图像的超分辨率技术原理和应用场景

微信团队分享:微信每日亿次实时音视频聊天背后的技术解密

腾讯信鸽技术分享:百亿级实时消息推送的实战经验

IPv6技术详解:基本概念、应用现状、技术实践(上篇)

IPv6技术详解:基本概念、应用现状、技术实践(下篇)

腾讯技术分享:GIF动图技术详解及手机QQ动态表情压缩技术实践

微信团队分享:Kotlin渐被认可,Android版微信的技术尝鲜之旅

社交软件红包技术解密(一):全面解密QQ红包技术方案——架构、技术实现等

社交软件红包技术解密(二):解密微信摇一摇红包从0到1的技术演进

社交软件红包技术解密(三):微信摇一摇红包雨背后的技术细节

社交软件红包技术解密(四):微信红包系统是如何应对高并发的

社交软件红包技术解密(五):微信红包系统是如何实现高可用性的

社交软件红包技术解密(六):微信红包系统的存储层架构演进实践

社交软件红包技术解密(九):谈谈手Q红包的功能逻辑、容灾、运维、架构等

社交软件红包技术解密(十):手Q客户端针对2020年春节红包的技术实践

社交软件红包技术解密(十一):解密微信红包随机算法(含代码实现)

社交软件红包技术解密(十三):微信团队首次揭秘微信红包算法,为何你抢到的是0.01元

(本文已同步发布于:http://www.52im.net/thread-2564-1-1.html

posted @ 2025-01-15 11:19 Jack Jiang 阅读(41) | 评论 (0)编辑 收藏

本文来自微信团队工程师方乐明的技术分享,由InfoQ编辑发布,下文收录时有修订和改动。

一、引言

每年节假日,微信红包的收发数量都会暴涨,尤以除夕为最。如此大规模、高峰值的业务需要,背后需要怎样的技术支撑?百亿级别的红包规模,如何保证并发性能与资金安全?

本文将为读者介绍微信百亿级别红包背后的高并发设计实践,内容包括微信红包系统的技术难点、解决高并发问题通常使用的方案,以及微信红包系统的所采用高并发解决方案。

技术交流:

二、分享者

方乐明:现任微信支付应用产品系统负责人,主要从事微信红包、微信转账、微信群收款等支付应用产品的系统设计、可用性提升、高性能解决方案设计等,曾连续多年负责春节微信红包系统的性能优化与稳定性提升,取得良好的效果。

三、系列文章

❶ 系列文章目录:

❷ 其它相关文章:

四、微信红包的两大业务特点

微信红包(尤其是发在微信群里的红包,即群红包),业务形态上很类似网上的普通商品“秒杀”活动。

就像下面这样:

  • 1)用户在微信群里发一个红包,等同于是普通商品“秒杀”活动的商品上架;
  • 2)微信群里的所有用户抢红包的动作,等同于“秒杀”活动中的查询库存;
  • 3)用户抢到红包后拆红包的动作,则对应“秒杀”活动中用户的“秒杀”动作。

不过除了上面的相同点之外,微信红包在业务形态上与普通商品“秒杀”活动相比,还具备自身的特点。

首先:微信红包业务比普通商品“秒杀”有更海量的并发要求。

微信红包用户在微信群里发一个红包,等同于在网上发布一次商品“秒杀”活动。假设同一时间有 10 万个群里的用户同时在发红包,那就相当于同一时间有 10 万个“秒杀”活动发布出去。10 万个微信群里的用户同时抢红包,将产生海量的并发请求。

其次:微信红包业务要求更严格的安全级别。

微信红包业务本质上是资金交易。微信红包是微信支付的一个商户,提供资金流转服务。

用户发红包时,相当于在微信红包这个商户上使用微信支付购买一笔“钱”,并且收货地址是微信群。当用户支付成功后,红包“发货”到微信群里,群里的用户拆开红包后,微信红包提供了将“钱”转入折红包用户微信零钱的服务。

资金交易业务比普通商品“秒杀”活动有更高的安全级别要求。普通的商品“秒杀”商品由商户提供,库存是商户预设的,“秒杀”时可以允许存在“超卖”(即实际被抢的商品数量比计划的库存多)、“少卖”(即实际被抢的商户数量比计划的库存少)的情况。但是对于微信红包,用户发 100 元的红包绝对不可以被拆出 101 元;用户发 100 元只被领取 99 元时,剩下的 1 元在 24 小时过期后要精确地退还给发红包用户,不能多也不能少。

以上是微信红包业务模型上的两大特点。

五、 微信红包系统的技术难点

在介绍微信红包系统的技术难点之前,先介绍下简单的、典型的商品“秒杀”系统的架构设计,如下图所示。

该系统由接入层、逻辑服务层、存储层与缓存构成:

  • 1)Proxy 处理请求接入;
  • 2)Server 承载主要的业务逻辑;
  • 3)Cache 用于缓存库存数量;
  • 4)DB 则用于数据持久化。

一个“秒杀”活动,对应 DB 中的一条库存记录。当用户进行商品“秒杀”时,系统的主要逻辑在于 DB 中库存的操作上。

一般来说,对 DB 的操作流程有以下三步:

  • 1)锁库存;
  • 2)插入“秒杀”记录;
  • 3)更新库存。

其中,锁库存是为了避免并发请求时出现“超卖”情况。同时要求这三步操作需要在一个事务中完成(所谓的事务,是指作为单个逻辑工作单元执行的一系列操作,要么完全地执行,要么完全地不执行)。

“秒杀”系统的设计难点就在这个事务操作上。商品库存在 DB 中记为一行,大量用户同时“秒杀”同一商品时,第一个到达 DB 的请求锁住了这行库存记录。在第一个事务完成提交之前这个锁一直被第一个请求占用,后面的所有请求需要排队等待。同时参与“秒杀”的用户越多,并发进 DB 的请求越多,请求排队越严重。因此,并发请求抢锁,是典型的商品“秒杀”系统的设计难点。

微信红包业务相比普通商品“秒杀”活动,具有海量并发、高安全级别要求的特点。

在微信红包系统的设计上,除了并发请求抢锁之外,还有以下两个突出难点:

首先,事务级操作量级大:

上文介绍微信红包业务特点时提到,普遍情况下同时会有数以万计的微信群在发红包。这个业务特点映射到微信红包系统设计上,就是有数以万计的“并发请求抢锁”同时在进行。这使得 DB 的压力比普通单个商品“库存”被锁要大很多倍;

其次,事务性要求严格:

微信红包系统本质上是一个资金交易系统,相比普通商品“秒杀”系统有更高的事务级别要求。

六、解决高并发问题通常使用的方案

普通商品“秒杀”活动系统,解决高并发问题的方案,大体有以下几种。

6.1方案一:使用内存操作替代实时的 DB 事务操作

如图 2 所示,将“实时扣库存”的行为上移到内存 Cache 中操作,内存 Cache 操作成功直接给 Server 返回成功,然后异步落 DB 持久化。

这个方案的优点是用内存操作替代磁盘操作,提高了并发性能。

但是缺点也很明显,在内存操作成功但 DB 持久化失败,或者内存 Cache 故障的情况下,DB 持久化会丢数据,不适合微信红包这种资金交易系统。

6.2方案二:使用乐观锁替代悲观锁

所谓悲观锁,是关系数据库管理系统里的一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作对某行数据应用了锁,那只有当这个事务把锁释放,其他事务才能够执行与该锁冲突的操作。对应于上文分析中的“并发请求抢锁”行为。

所谓乐观锁,它假设多用户并发的事务在处理时不会彼此互相影响,各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前,每个事务会先检查在该事务读取数据后,有没有其他事务又修改了该数据。如果其他事务有更新的话,正在提交的事务会进行回滚。

商品“秒杀”系统中,乐观锁的具体应用方法,是在 DB 的“库存”记录中维护一个版本号。在更新“库存”的操作进行前,先去 DB 获取当前版本号。在更新库存的事务提交时,检查该版本号是否已被其他事务修改。如果版本没被修改,则提交事务,且版本号加 1;如果版本号已经被其他事务修改,则回滚事务,并给上层报错。

这个方案解决了“并发请求抢锁”的问题,可以提高 DB 的并发处理能力。

但是如果应用于微信红包系统,则会存在下面三个问题:

  • 1)如果拆红包采用乐观锁:那么在并发抢到相同版本号的拆红包请求中,只有一个能拆红包成功,其他的请求将事务回滚并返回失败,给用户报错,用户体验完全不可接受;
  • 2)如果采用乐观锁:将会导致第一时间同时拆红包的用户有一部分直接返回失败,反而那些“手慢”的用户,有可能因为并发减小后拆红包成功,这会带来用户体验上的负面影响;
  • 3)如果采用乐观锁的方式:会带来大数量的无效更新请求、事务回滚,给 DB 造成不必要的额外压力。

基于以上原因,微信红包系统不能采用乐观锁的方式解决并发抢锁问题。

七、微信红包系统的高并发解决方案

综合上面的分析,微信红包系统针对相应的技术难点,采用了下面几个方案,解决高并发问题。

7.1系统垂直 SET 化,分而治之

微信红包用户发一个红包时,微信红包系统生成一个 ID 作为这个红包的唯一标识。接下来这个红包的所有发红包、抢红包、拆红包、查询红包详情等操作,都根据这个 ID 关联。

红包系统根据这个红包 ID,按一定的规则(如按 ID 尾号取模等),垂直上下切分。切分后,一个垂直链条上的逻辑 Server 服务器、DB 统称为一个 SET。

各个 SET 之间相互独立,互相解耦。并且同一个红包 ID 的所有请求,包括发红包、抢红包、拆红包、查详情详情等,垂直 stick 到同一个 SET 内处理,高度内聚。通过这样的方式,系统将所有红包请求这个巨大的洪流分散为多股小流,互不影响,分而治之,如下图所示。

这个方案解决了同时存在海量事务级操作的问题,将海量化为小量。

7.2逻辑 Server 层将请求排队,解决 DB 并发问题

红包系统是资金交易系统,DB 操作的事务性无法避免,所以会存在“并发抢锁”问题。但是如果到达 DB 的事务操作(也即拆红包行为)不是并发的,而是串行的,就不会存在“并发抢锁”的问题了。

按这个思路,为了使拆红包的事务操作串行地进入 DB,只需要将请求在 Server 层以 FIFO(先进先出)的方式排队,就可以达到这个效果。从而问题就集中到 Server 的 FIFO 队列设计上。

微信红包系统设计了分布式的、轻巧的、灵活的 FIFO 队列方案。其具体实现如下:

首先,将同一个红包 ID 的所有请求 stick 到同一台 Server。

上面 SET 化方案已经介绍,同个红包 ID 的所有请求,按红包 ID stick 到同个 SET 中。不过在同个 SET 中,会存在多台 Server 服务器同时连接同一台 DB(基于容灾、性能考虑,需要多台 Server 互备、均衡压力)。

为了使同一个红包 ID 的所有请求,stick 到同一台 Server 服务器上,在 SET 化的设计之外,微信红包系统添加了一层基于红包 ID hash 值的分流,如下图所示。

其次,设计单机请求排队方案。

将 stick 到同一台 Server 上的所有请求在被接收进程接收后,按红包 ID 进行排队。然后串行地进入 worker 进程(执行业务逻辑)进行处理,从而达到排队的效果,如下图所示。

最后,增加 memcached 控制并发。

为了防止 Server 中的请求队列过载导致队列被降级,从而所有请求拥进 DB,系统增加了与 Server 服务器同机部署的 memcached,用于控制拆同一个红包的请求并发数。

具体来说,利用 memcached 的 CAS 原子累增操作,控制同时进入 DB 执行拆红包事务的请求数,超过预先设定数值则直接拒绝服务。用于 DB 负载升高时的降级体验。

通过以上三个措施,系统有效地控制了 DB 的“并发抢锁”情况。

7.3双维度库表设计,保障系统性能稳定

红包系统的分库表规则,初期是根据红包 ID 的 hash 值分为多库多表。随着红包数据量逐渐增大,单表数据量也逐渐增加。而 DB 的性能与单表数据量有一定相关性。当单表数据量达到一定程度时,DB 性能会有大幅度下降,影响系统性能稳定性。采用冷热分离,将历史冷数据与当前热数据分开存储,可以解决这个问题。

处理微信红包数据的冷热分离时,系统在以红包 ID 维度分库表的基础上,增加了以循环天分表的维度,形成了双维度分库表的特色。

具体来说,就是分库表规则像 db_xx.t_y_dd 设计,其中,xx/y 是红包 ID 的 hash 值后三位,dd 的取值范围在 01~31,代表一个月天数最多 31 天。

通过这种双维度分库表方式,解决了 DB 单表数据量膨胀导致性能下降的问题,保障了系统性能的稳定性。同时,在热冷分离的问题上,又使得数据搬迁变得简单而优雅。

综上所述:微信红包系统在解决高并发问题上的设计,主要采用了 SET 化分治、请求排队、双维度分库表等方案,使得单组 DB 的并发性能提升了 8 倍左右,取得了很好的效果。

八、本文小结

微信红包系统是一个高并发的资金交易系统,最大的技术挑战是保障并发性能与资金安全。

这种全新的技术挑战,传统的“秒杀”系统设计方案已不能完全解决。在分析了业界“秒杀”系统解决方案的基础上,微信红包采用了 SET 化、请求排队串行化、双维度分库表等设计,形成了独特的高并发、资金安全系统解决方案,并在平时节假日、春节红包雨实践中充分证明了可行性,取得了显著的效果。以2017 鸡年除夕夜为例,微信红包收发峰值达到 76 万每秒,收发微信红包 142 亿个,微信红包系统的表现稳定,实现了除夕夜系统零故障。

九、更多鹅厂技术文章汇总

微信朋友圈千亿访问量背后的技术挑战和实践总结

腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)

腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)

IM全文检索技术专题(二):微信移动端的全文检索多音字问题解决方案

腾讯技术分享:Android版手机QQ的缓存监控与优化实践

微信团队分享:iOS版微信的高性能通用key-value组件技术实践

微信团队分享:iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的?

腾讯技术分享:Android手Q的线程死锁监控系统技术实践

微信团队原创分享:iOS版微信的内存监控系统技术实践

让互联网更快:新一代QUIC协议在腾讯的技术实践分享

(本文已同步发布于:http://www.52im.net/thread-2548-1-1.html

posted @ 2025-01-13 11:39 Jack Jiang 阅读(39) | 评论 (0)编辑 收藏

本文由腾讯技术团队原创分享于鹅厂黑板报,下文有排版优化。

1、写在前面

直至现在,「微信鸿蒙版」这五个字,依然被赋予着太多意义。

这是一款产品,也不仅仅是一款产品。开发它的本质,是让两个高速前进,相互影响的复杂系统,彼此磨合和熟悉,像是执行一场空中加油任务。

不管外界如何评价和鞭策,这款产品本身,依然需要研发团队一个键一个键敲出来,从内核,到架构,到内测,到公测,再到一轮一轮的 debug,他们要在不到一年的时间里,走完微信14 年的路。

回顾鹅厂所做过的产品里,也许从未有过一款,被如此放在放大镜下凝视。每一次上架,每一个 bug,乃至于每一个里程碑,几乎都预定当天热搜。

站在正式版发布的1 月 9 日,或许这一切都可以风轻云淡地说:the show must go on。但这过去的 295 天里,他们的经历,我们认为值得记录下来,分享给关心微信鸿蒙版的用户朋友们。

2、2024年3月,集结

鹅厂指派了从塞班(Symbian)时期就负责微信开发工作的团队,来主导微信鸿蒙版。从塞班到智能手表、车机、Linux PC 端的微信,这个团队在内部素以擅长攻克不同环境、不同语言的开发工作著称。

同样很重要的一点是,得益于智能手表端微信的研发工作,微信和华为的两个团队是老相识,这也让双方的对接更加顺畅紧密起来。从三月贯穿到四月,两边通过拉通会、分享会学习鸿蒙系统研发框架,不定时组织技术专题讨论。

双方都很清楚,这不是一场三天两夜就能解决的小规模战斗,而是旷日持久的兵团级战役。兵马未动,粮草先行,敲下第一行代码之前,还有许许多多的工作需要准备。

3、2024年4月,基建

万丈高楼平地起,基建是最重要的第一步。

搞基建,“三通一平”(通电/通路/通水/土地平整)是基本要求,进取一些,可以做到“五通一平”(加入通讯/排污),再进一步,还有“七通一平”(加入通气/有线电视),乃至于“十通一平”(加入宽带/铁路/暖气)。通得越多,越有利于后期扩展和长远发展。

经过塞班、手机、手表等各种终端上的长期打磨,这个团队积累了一套名为Alita(阿丽塔)的跨平台内核。这也为鸿蒙版微信的基建打下了基础。这个阶段的重中之重是,快速熟悉鸿蒙系统,移植基础库,让 Alita 内核能够在鸿蒙系统上运行起来,和华为一边沟通、一边验证推进。

4、2024年5月,架构

接下来考验的是架构能力。开发团队需要设计好鸿蒙微信客户端的架构、编写好各模块文档,支撑各业务进场后能够高效开发。

这一步的难点,在于充分预判到业务之间的复杂解耦,既要降低各业务之间的依赖性,又要提高整体的稳定性,还要留出高可扩展性,属于典型的“我全都要”难题。

这就好比从零开始建设一座城市,要预估到这座百年之后超级都市的人口规模、交通状况、人居需求、产业结构、商业发展等因素,以及提前平衡这些因素之间的关系,需要具备极大的前瞻视角。

技术团队继续摇人,招聘也快马加鞭推进。TAPD(腾讯敏捷产品研发平台)流程图里,他们的首个目标是做出一个基础版本,保证用户能实现收发消息、语音通话等最基础、也是最重要的功能。

5、2024年6月,磨合

进入了真正的手搓环节。flutter(跨平台应用程序开发框架)、liteapp(专为移动端设计的跨平台开发框架)等,都是这个阶段的关键工作。

为了这桌“年夜饭”,技术小哥们一边在厨房切菜烧饭,一边去客厅招呼各方沏茶倒水,让支付和VoIP(语音通话技术)等基础能力陆续凑上一桌。

除了内外部密切的技术沟通,微信和华为团队对彼此的技术标准保持了互相尊重。以相册选图发送功能为例,在 Android 系统上,选图需要获取整个相册权限,也就是说应用可以访问用户的所有照片。在鸿蒙上的选图功能,为了保障用户隐私,微信采用的是 Picker 控件的方式,相册照片的展示和选择逻辑都由 Picker 控件提供,微信只能读取到用户勾选的照片。

6、第一个里程碑:bug 如约而至

赶在6月21日前,团队做好了第一个内部体验版本,包含收发消息、通话功能。和2011年1月21日发布的 iOS和安卓版的微信1.0版本相比,多了语音消息发送。

你可能会不以为然:大动干戈这么久,就整了个这毛坯房?

其实这里蕴含的开发思路,是验证最小可用的原则,本质上是对第一阶段研究鸿蒙语言和系统的成果验收。重要的是把基本功练好,才能为后续的开枝散叶打好底子。

但即便是如此普通的版本,也出了个闪退型 bug,最后查出来是系统的底层 API 问题:同样的代码逻辑,在 iOS 和安卓上能用,但在鸿蒙上行不通。两边团队为此绞尽脑汁,交了两个星期的学费,最后还是靠着某位技术小哥灵光一现想到的。

这个 bug也像是一场结业考试,经此一役,开发进入了快节奏。

微信集合了众多产品功能,各功能间又有复杂的交互和依赖关系,比如小程序的开发就涉及到与支付功能的打通,而支付能力又需要与基础会话功能打通。在完成基建的前提下,基础、支付、小程序……能进场的业务模块都陆续进了场。一个共同的目标是——10月8号鸿蒙公测那天,做出一个新版本。这个版本,将新增微信支付、朋友圈等功能。

7、2024年10月8日:喜欢您来

10月8日,微信鸿蒙原生版开启内测邀请,尝鲜版本包含基础社交通讯音视频通话、朋友圈、微信支付的二维码收/付款等功能。

内测开启,意味着微信和其他所有适配原生鸿蒙的第三方App一样,从内测到应用尝鲜再到公测,走上了鸿蒙系统第三方软件开发的三部曲。

为什么要限量内测而不是一口气开放下载呢?

在全新的平台上,要支撑海量用户、高并发通讯需求,同时涉及支付、小程序、视频等多个大功能模块,还要满足极高频使用下的稳定性,是很大的挑战。

所以,用内测 → 找bug → 修bug → 加大内测的方式,是一个更符合软件开发规律的方式。

经历了4天紧张的测试和debug,包括微信支付在内的多个功能经过严格测试流程后,合入大版本,10 月 12 日,微信鸿蒙原生版正式开始公测。

8、2024年10月~11 月:这都能遇到灰产啊啊啊

公测放量过程中,有一次实际登陆人数不到放量总数的十分之一?某平台上竟然有人公然售卖测试名额?

一系列插曲打破了原定的放量节奏,双方共同排查后发现,原来有人把安装包拿去二手平台牟利。应用商店完善机制后,把漏洞补上。

安装包都能拿来卖,也堪称是国产软件开发史上浓墨重彩的一笔。

微信鸿蒙版在尝鲜专区上线了2万测试名额,但后台显示,登录数据一直较低,我们和华为一同复盘发现,因为有人用脚本去抢名额,触发了应用商店的安全机制,同时扰乱了应用商店的计数逻辑,导致大概90% 的放量被拦截,最终实际下载的用户只有 10%左右。

又是浓墨重彩的一笔......

如何让用户尽可能体验到微信测试版本?

在基本保障尝鲜专区不断档的情况下,11 月 6 日,双方紧急协商,华为将微信鸿蒙版的测试名额大幅扩容,微信再次邀请扩容后的用户分批有序参与内测,共同完善新版本的各种体验。

在不断收集用户反馈、历经数次迭代后,目前的版本已经可以使用视频号、聊天引用、发文件等功能,所有鸿蒙用户也都可以直接下载,更多功能在持续上线。

9、2025年1月9日:不止是微信

吸收了广大用户的反馈和多轮debug后,鸿蒙版微信顺利结束公测,1月9日正式版本上线。你除了能稳定下载和使用微信外,还可以用到 QQ、腾讯视频、腾讯新闻、QQ 音乐等App。

自今年起,腾讯20多款产品通过敏捷开发,实现鸿蒙系统的适配工作,更多腾讯的产品适配也在路上。

一个发生在2024年10月29日的插曲,某种程度上,可以反映微信鸿蒙版开发团队的工作情形和协作流程:

19:20,项目组微信支付团队发现,即将要上架的最新尝鲜版的微信,小部分用户转账入口出现bug,点击后无反应。

20:15,客服团队同步后台客诉情况。

20:57,微信支付团队初步定位,有问题的代码是今日合入导致的,疑似是LiteApp(跨端的框架,微信转账是鸿蒙第一个使用这个框架的功能)的问题。

21:31,进一步定位问题,发现在一些极端情况下, LiteApp的文件缓存写入被系统提示权限不足,联系华为技术团队一起定位。

21:47,支付技术团队完成最新内测版微信的修复,合入后,提交版本给测试团队。

22:32,支付技术团队复盘问题,提出后续改进措施。

22:41,微信基础技术团队向华为应用商店提审新版本内测包。

22:54,向华为应用商店提审尝鲜版。

23:30,最新尝鲜版微信通过审核,上架尝鲜专区,转账问题修复。

微信公众平台曾有一句 slogan 深入人心:再小的个体,也有自己的品牌。同样的,再小的问题,放在微信上,都会被亿量级地扩大。

我们知道,永远等不来“完美交付”这一天。灰度测试、持续迭代,让产品在和用户的互动中得到改进,是腾讯一直以来的产品理念。

感谢微信用户、鸿蒙用户始终跟我们站在一起,7x24小时反馈bug、提出优化意见。如果把新产品开发比做一场足球赛,那希望你们一直都在,做我们敏捷开发“球队”的第12人。

10、微信的其它故事

技术往事:微信估值已超5千亿,雷军曾有机会收编张小龙及其Foxmail

QQ和微信凶猛成长的背后:腾讯网络基础架构的这些年

2017微信数据报告:日活跃用户达9亿、日发消息380亿条

腾讯开发微信花了多少钱?技术难度真这么大?难在哪?

技术往事:“QQ群”和“微信红包”是怎么来的?

开发往事:深度讲述2010到2015,微信一路风雨的背后

开发往事:微信千年不变的那张闪屏图片的由来

开发往事:记录微信3.0版背后的故事(距微信1.0发布9个月时)

一个微信实习生自述:我眼中的微信开发团队

为什么说即时通讯社交APP创业就是一个坑?

微信七年回顾:历经多少质疑和差评,才配拥有今天的强大

前创始团队成员分享:盘点微信的前世今生——微信成功的必然和偶然

即时通讯创业必读:解密微信的产品定位、创新思维、设计法则等

QQ现状深度剖析:你还认为QQ已经被微信打败了吗?

[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗?

QQ和微信止步不前,意味着即时通讯社交应用创业的第2春已来?

那些年微信开发过的鸡肋功能,及其带给我们的思考

读懂微信:从1.0到7.0版本,一个主流IM社交工具的进化史

同为IM社交产品中的王者,QQ与微信到底有什么区别

社交应用教父级人物的张小龙和马化腾的同与不同

专访马化腾:首次开谈个人经历、管理心得、技术创新、微信的诞生等

一文读懂微信之父张小龙:失败天才、颠覆者、独裁者、人性操控师


(本文已同步发布于:http://www.52im.net/thread-4776-1-1.html

posted @ 2025-01-10 11:13 Jack Jiang 阅读(24) | 评论 (0)编辑 收藏

本文由转转王棕生分享,原题“IM系列(一):转转IM系统架构探秘”,下文进行了排版和内容优化。

1、引言

转转是二手电商平台,在这个平台上,人人可以是买家,人人也可以是卖家。转转从最初的信息模式升级为一个闭环的交易模式,IM打通了买家与卖家之间的通道。本文描述了转转IM为整个平台提供的支撑能力,给出了系统的整体架构设计,分析了系统架构的特性。

2、系列文章

本文是系列文章中的第1篇,本系列文章的大纲如下:

3、本文作者

王棕生:转转架构平台部高级研发工程师,负责IM系统、推送系统和分布式存储系统。

4、系统能力定义

转转IM需要提供如下的支撑能力:

1)有的用户习惯使用APP、有的用户习惯免安装的小程序;还有的用户习惯于在“58同城”APP上搜索二手;所以IM需要支持APP、小程序、M端等各种终端类型,以及由转转平台衍生出的其他垂类APP。

2)IM是转转平台中的一个独立系统,需要向平台中的其他系统(如客服系统、风控系统)提供“联系人”和“私信”等IM能力。

3)在转转平台的各种运营活动中,需要借助于IM通道将商品消息、订单消息、交易消息及活动通知等实时的发送给用户。

总之:IM为转转平台提供一个可靠和稳定的通道,为用户与用户之间、业务系统与用户之间、平台与用户之间打造一个可以即时通讯的环境。

5、系统架构概览

转转IM系统架构设计如下图所示,自上而下包括四层:用户层、入口层、逻辑层和原子存储层。

转转IM系统架构设计图:

6、系统架构之“用户层”

用户层是IM服务的调用者,用户层支撑各类业务应用,包括APP、小程序、M端、平台运营类业务系统和ZZRPC。

APP基于TCP协议与IM服务端进行消息传输,小程序和M端则是通过HTTP协议。

ZZRPC是转转平台使用Java语言自研的RPC框架,而转转IM系统是使用C++语言进行研发的,所以IM需要通过适配支持ZZRPC服务的相互调用。

7、系统架构之“入口层”

入口层是IM系统的入口网关,包括:

  • 1)Entry
  • 2)Http-Entry
  • 3)转转自研的分布式消息中间件ZZMQ;
  • 4)IMUI。

Entry:负责维护与APP之间的TCP连接,把APP发送的业务请求包向后直接转发到逻辑层进行处理。Entry逻辑较为简单,不参与具体的业务处理,这样设计的原因是为了避免Entry因业务改造升级进行模块重启,而丢失与APP之间的TCP连接,影响大量用户。

Http-Entry:是HTTP版的Entry实现,Http-Entry负责维护的是与小程序和M端之间通过HTTP协议模拟的“长连接”。

HTTP“长连接”的实现原理是:小程序发送http_request到Http-Entry,Http-Entry会hold住连接不返回、不释放;当产生了该用户的私信数据时或hold住连接超过一定时间(如15秒)时,Http-Entry则返回http_response到小程序;小程序收到http_response时需要立即再次发送http_request到Http-Entry......。

ZZMQ:是转转自研的分布式消息队列,接收平台各个运营类业务系统生产的系统消息、广播消息和推送类消息,然后由IM逻辑模块进行消费处理。ZZMQ解耦了平台业务系统和IM系统

IMUI:用于IM系统适配ZZRPC的调用;IMUI作为ZZRPC服务的提供者,接收ZZRPC客户端的请求后,按照IM系统的内部协议格式同步访问逻辑层,再将逻辑层的操作结果按ZZRPC协议进行封装,然后返回到ZZRPC的客户端。

8、系统架构之“逻辑层”

逻辑层包括Logic和Extlogic两个模块组件:

  • 1)Logic负责实现IM系统核心的和轻量级的业务逻辑,如用户登录、获取未读数、发送私信等;
  • 2)非核心的和重量级的业务由Extlogic进行实现;
  • 3)Logic和Extlogic两个逻辑模块通过ZZMQ进行解耦。

例如:在私信逻辑处理流程中,Logic接收私信和用户在线时的私信推送,而对于离线私信Logic则会通过ZZMQ通知Extlogic进行离线消息的召回逻辑处理。

9、系统架构之“原子存储层”

IM需要持久化存储的数据包括私信消息、系统消息和联系人等。

这些数据通过传统的关系型数据库MySQL和NewSQL数据库TiDB进行保存:

  • 1)TiDB是分布式数据库,具有天然的弹性扩容特性;
  • 2)MySQL通过通用的分库分表策略来应对存储和查询负载。

Das接收逻辑层对持久化数据的读写请求,将请求放入本地队列中,然后按顺序对数据库进行同步读写操作。

ZZRedis是转转自研的分布式缓存系统,负责对用户的在线信息进行缓存。

Jtransit与IMUI类似,用于适配ZZRPC服务;Jtransit作为ZZRPC服务的调用,接收逻辑层的请求后,按照ZZRPC协议格式访问平台其他系统提供的服务,获取数据后封装成IM系统的协议数据返回到逻辑层。

10、架构特性1:伸缩性

对转转IM系统架构设计,从伸缩性、高可用、可靠性、可扩展性和高性能分别进行分析。

当转转并发访问的用户量不断增加,IM系统资源紧张时,需要通过增加机器进行水平弹性扩容,主要是通过服务管理平台控制中心进行实施的。入口层、逻辑层和原子层服务之间相互调用的关系如下表所示。

Entry和Http-Entry会作为调用方调用Logic的服务,Logic和Extlogic会作为调用方调用Das的服务和Entry与Http-Entry的服务,这些服务之间的关系通过控制中心进行管理。

首先:

  • 1)服务方组件与控制中心建立TCP长连接,将服务内容包括本实例ip、端口、服务接口等等注册到控制中心;
  • 2)调用方组件与控制中心建立TCP长连接,从控制中心轮询服务列表;
  • 3)服务方组件增加机器弹性扩容时,新的实例会注册到控制中心,进而被调用方实时拉取到。

另外:

  • 1)App通过域名连接Entry时会首先访问TGW,由TGW转发请求到Entry,所以增加Entry实例时需要在TGW进行注册;
  • 2)小程序到Http-Entry的HTTP请求都是由Nginx进行中转,所以增加Http-Entry机器需要在Nginx上进行配置;
  • 3)Extlogic作为ZZMQ的消费者,可以自由增加实例。

存储层扩容:

  • 1)数据库MySQL通过分库和分表的方式进行扩容;
  • 2)分布式数据库TiDB以及分布式缓存ZZRedis;
  • 3)还有分布式消息队列ZZMQ自身具有天然的弹性伸缩特性。

11、架构特性2:高可用

1)入口层高可用:入口层Entry和Http-Entry的可用性分别由TGW和Nginx进行探活和迁移。

2)Logic高可用:Logic的可用性由入口层实例进行控制;为了保证同一用户消息的顺序性,Entry和Http-Entry会将同一个用户的请求通过哈希算法打到相同的Logic实例;若一索引号为x的Logic实例挂掉以后,Entry和Http-Entry会在重试后将请求打到索引号为(x+p)%n的Logic实例上(n为Logic实例数目,p的取值区间为[1,n) );注意p的取值不能固定,否则很容易将瞬时流量打到固定的Logic实例,引起雪崩效应。

3)Extlogic高可用:Extlogic负责消费消息队列ZZMQ中的消息,挂掉任意一个实例后,不影响业务的正常处理。

4)Das高可用:Das的高可用由Logic和Extlogic进行控制,原理与Logic高可用一致,在挂掉任意一个Das实例后,Logic和Extlogic会将请求打到索引号为(x+p)%n的Das实例上。

5)存储层高可用:MySQL通过一主两备模式保证其高可用,在主库挂掉以后,其中的一个备库变为主库继续对Das提供服务;分布式数据库TiDB、分布式缓存ZZRedis,分布式消息队列ZZMQ自身具有天然的高可用特性。

12、架构特性3:可靠性

程序的正确处理保证系统的可靠性,影响IM系统可靠性的因素主要是瞬时高峰导致的逻辑层Logic实例的系统资源被用光和原子层Das对数据库的访问超时。

1)Logic可靠性:逻辑层实例的系统资源被用光发生在业务的相互影响;例如瞬时大量用户登录IM系统时,Logic大部分或全部线程被调度用于处理用户登录业务,而没有足够的资源去处理私信等业务。提高Logic可靠性的方案,可以根据微服务思想对Logic按功能职责进行拆分,如拆分成Login_Logic、Msg_Logic、Contact_Logic等。

2)Das可靠性:对数据库的访问超时发生在数据库负载较高时,例如推送千万级广播系统消息时,会有大量的更新操作落到数据库上,此时数据库响应较慢或超时;因为Das对数据库的操作是同步的,所以会造成Das内部队列请求的堆积,其他业务请求也会被堆积而导致超时。提高Das可靠性的方案,可以根据业务类型在Das内部分别创建不同的请求队列,从而避免业务的相互影响。

13、架构特性4:可扩展性和高性能

1)可扩展性:转转IM系统架构的可扩展性体现在逻辑层,逻辑层Logic和Extlogic通过消息队列ZZMQ进行解耦,定制类的功能需求在Extlogic中进行实现,避免对核心业务Logic的影响。

ZZMQ除了解耦Logic和Extlogic外,还对平台的业务系统和IM系统进行解耦。

2)高性能:分析IM系统架构,入口层和逻辑层主要是计算模块,原子存储层主要是IO模块,系统的性能瓶颈集中在数据库端。提升性能方案有:通过增强机器配置、增加机器、研究和新的存储方式,如用户联系人可以通过KList引擎进行存储。

14、本文小结

转转IM为用户与用户之间、客服与用户之间、平台与用户之间打造了一个高效和可靠的通讯通道。

按微服务私信和分层模式对IM系统架构进行分布式设计,架构中每个组件模块的功能职责明确。

具体的功能职责如下:

  • 1)Entry负责维护TCP连接;
  • 2)Http-Entry负责维护HTTP连接;
  • 3)Logic负责处理核心的轻量级业务,Logic要求服务稳定;
  • 4)Extlogic负责处理非核心的重量级业务,Extlogic要求服务可扩展;
  • 5)Das负责对数据库进行读写访问;
  • 6)IMUI和Jtransit负责对平台的RPC框架ZZRPC进行适配;
  • 7)MySQL、TiDB和ZZRedis负责持久化和缓存数据;
  • 8)ZZMQ负责对平台的业务系统和IM系统,以及Logic和Extlogic之间进行解耦。

转转IM的系统架构具有伸缩性、高可用、可靠性、功能扩展性和高性能。

15、参考资料

[1] 浅谈IM系统的架构设计

[2] 简述移动端IM开发的那些坑:架构设计、通信协议和客户端

[3] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

[4] 一套原创分布式即时通讯(IM)系统理论架构方案

[5] 从零到卓越:京东客服即时通讯系统的技术架构演进历程

[6] 蘑菇街即时通讯/IM服务器开发之架构选择

[7] 现代IM系统中聊天消息的同步和存储方案探讨

[8] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[9] 马蜂窝旅游网的IM系统架构演进之路

[10] 瓜子IM智能客服系统的数据架构设计(整理自现场演讲,有配套PPT)

[11] 阿里钉钉技术分享:企业级IM王者——钉钉在后端架构上的过人之处

[12] 一套亿级用户的IM架构技术干货(上篇):整体架构、服务拆分等

[13] 从新手到专家:如何设计一套亿级消息量的分布式IM系统

[14] 闲鱼亿级IM消息系统的架构演进之路

[15] 基于实践:一套百万消息量小规模IM系统技术要点总结

[16] 一套十万级TPS的IM综合消息系统的架构实践与思考

[17] vivo直播系统中IM消息模块的架构实践

[18] 一套分布式IM即时通讯系统的技术选型和架构设计

[19] 微信团队分享:来看看微信十年前的IM消息收发架构,你做到了吗

[20] 携程技术分享:亿级流量的办公IM及开放平台技术实践

(本文已同步发布于:http://www.52im.net/thread-4764-1-1.html

posted @ 2025-01-09 12:42 Jack Jiang 阅读(33) | 评论 (0)编辑 收藏

     摘要: 1、HarmonyChat是什么?HarmonyChat是一个简洁的鸿蒙NEXT上的基于WebSocket协议的聊天客户端 ,它基于MobileIMSDK通信库, 有完善的网络通信通力、简洁的聊天界面UI、合理的代码拆分和逻辑实现,非常适合学习研究或直接用于简单的鸿蒙NEXT单页聊天项目中 。HarmonyChat的源码下载请见本文:“5、源码的开源仓库地址”。2...  阅读全文

posted @ 2025-01-02 11:21 Jack Jiang 阅读(46) | 评论 (0)编辑 收藏

相关链接:

一、理论知识准备

您需要对鸿蒙Next和ArkTS开发有所了解:

您需要对WebSocket技术有所了解:

HTML5的标准WebSocket协议文档、API手册:

鸿蒙Next的WebSocket文档和手册:

小提示:鸿蒙Next中的WebSocket API跟标准HTML5中的WebSocket接口及用法略有不同,但主要API都能一一对应,相差不大。

二、开发工具准备

1)DevEco-Studio:

JackJiang 使用的版本号如上图所示,为了方便直接引用工程,建议你也使用此版或较新版本

2)一站式下载地址:鸿蒙官网下载地址 点此进入。(需要注册成为开发者才能下载哟!

3)DevEco-Studio效果预览:

三、SDK 文件用途说明

3.1文件概览

纯ArkTS实现,无任何第3方库依赖,更无本地原生代码混编:

MobileIMSDK-鸿蒙端SDK本身只是ets文件源码的集合,自带的Demo代码只是为了方便随时测试SDK代码,目的主要是用于演示SDK的API调用,Demo代码不属于SDK框架的一部分。

大致的目录说明:

3.2详细说明

SDK 各模块/文件作用说明:

四、主要API接口和用途说明

* 主要API文档地址是:http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/

1)ClientCoreSDK.getInstance().loginHasInit:

  • 用途:是否已经完成过首次登陆。
  • 说明 :用户一旦从自已的应用中完成登陆IM服务器后,本方法就会一直返回true(直到退出登陆IM)。
  • 返回值:{boolean},true表示已完成首次成功登陆(即已经成功登陆过IM服务端了,后面掉线时不影响此标识),否则表示尚未连接IM服务器。

2)ClientCoreSDK.getInstance().connectedToServer:

  • 用途:是否在线。
  • 说明 :表示网络连接是否正常。
  • 返回值:{boolean},true表示网络连接正常,否则表示已掉线,本字段只在this._logined=true时有意义(如果都没有登陆到IM服务器,怎么存在在线或掉线的概念呢)。

3)ClientCoreSDK.getInstance().currentLoginInfo:

4)ClientCoreSDK.getInstance().init(eventHub: common.EventHub): void:

  • 用途:初始化SDK核心。
  • 说明:不同于MobileIMSDK的iOS和Java客户端,本方法需要由开发者调用,以确保MobileIMSDK核心已被初始化完成。
  • 本方法被调用后, #isInitialed() 将返回true,否则返回false。

5)ClientCoreSDK.getInstance().release(): void:

  • 用途:保释放MobileIMSDK框架资源统一方法。
  • 说明 :本方法建议在退出登陆(或退出APP时)时调用。调用时将尝试关闭所有MobileIMSDK框架的后台守护线程并同设置核心框架init=false、loginHasInit=false、connectedToServer=false。

6)LocalDataSender.getInstance().sendLogin(loginInfo: PLoginInfo | undefined): number:

  • 用途:发送登陆(连接)信息给服务端。
  • 说明 :不同于其它IM框架,本框架的登录和连接高度封装在了一个sendLogin方法中,无需单独再去connect服务器,大大简化了SDK的使用。loginInfo登陆信息各字段定义见:http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1697

7)LocalDataSender.getInstance().sendLoginout(): number:

  • 用途:发送注销登陆信息。
  • 说明:此方法的调用将被本库理解为退出库的使用,本方法将会额外调用资源释放方法 ClientCoreSDK#release() ,以保证资源释放。本方法调用后,除非再次进行登陆过程,否则核心库将处于初始未初始化状态。

8)LocalDataSender.getInstance().sendCommonDataPlain(dataContentWidthStr: string, to_user_id: string, QoS: boolean = true, fingerPrint: string = '', typeu: number = -1): number:

  • 用途:向某人发送一条消息。
  • 参数dataContentWidthStr:要发送的数据内容(字符串方式组织)。
  • 参数to_user_id:要发送到的目标用户id。
  • 参数QoS :true表示需QoS机制支持,否则不需要。
  • 参数fingerPrint:QoS机制中要用到的指纹码(即消息包唯一id),可设为null,生成方法见 Protocal.genFingerPrint()。
  • 参数typeu:应用层专用字段——用于应用层存放聊天、推送等场景下的消息类型。注意:此值为-1时表示未定义。MobileIMSDK框架中,本字段为保留字段,不参与框架的核心算法,专留作应用层自行定义和使用。
  • 返回值:0表示数据发出成功,否则返回的是错误码,see ErrorCode。

9)LocalDataSender.getInstance().sendCommonData(p: Protocal): number:

  • 用途:通用数据协议包的发送根方法。
  • 参数p:{Protocal} 要发送的消息协议包对象,Protocal详情请见“/module/mb_constants.js”下的createCommonData函数说明。
  • 返回值:0表示数据发出成功,否则返回的是错误码,see ErrorCode。

10)SocketEvent.SOCKET_EVENT_ON_RECIEVE_MESSAGE事件通知:

11)SocketEvent.SOCKET_EVENT_ON_LOGIN_RESPONSE事件通知:

  • 用途:本地用户的登陆结果回调事件通知(此事件发生时表示客户端已登陆/连接或重连完成)。
  • 推荐用法:开发者可在此事件中处理登录连接和掉线重连响应反馈。
  • 参数1: {PLoginInfoResponse}:API文档详见:http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1434

12)SocketEvent.SOCKET_EVENT_ON_LINK_CLOSE事件通知:

  • 用途:与服务端的通信断开的回调事件通知(此事件发生时表示客户端已掉线)。
  • 该消息只有在客户端连接服务器成功之后网络异常中断之时触发。导致与与服务端的通信断开的原因有(但不限于):无线网络信号不稳定、WiFi与2G/3G/4G/5G等同开情况下的网络切换、手机系统的省电策略等。
  • 推荐用法 :开发者可在此通知中处理掉线时的界面状态更新等,比如设置将界面上的“在线”文字更新成“离线”。

13)SocketEvent.SOCKET_EVENT_PING事件通知:

  • 用途:本地发出心跳包后的回调通知(本回调并非MobileIMSDK-鸿蒙端核心逻辑,开发者可以不需要实现!)。
  • 推荐用法 :开发者可在此回调中处理底层网络的活动情况。

14)SocketEvent.SOCKET_EVENT_PONG事件通知:

  • 用途:收到服务端的心跳包反馈的回调通知(本回调并非MobileIMSDK-鸿蒙端核心逻辑,开发者可以不需要实现!)。
  • 推荐用法 :开发者可在此回调中处理底层网络的活动情况。

15)SocketEvent.SOCKET_EVENT_KICKOUT事件通知:

16)SocketEvent.SOCKET_EVENT_ON_ERROR_RESPONSE事件通知:

17)SocketEvent.SOCKET_EVENT_RECONNECT_ATTEMPT事件通知:

  • 用途:“自动重连尝试中”事件(本回调并非MobileIMSDK-鸿蒙端核心逻辑,开发者可以不需要实现!)。
  • 参数 code :{numeric}:0:已停止,1:持续运行中,2:单次脉搏

18)SocketEvent.SOCKET_EVENT_MESSAGE_LOST事件通知:

  • 用途:消息未送达的回调事件通知。
  • 发生场景:比如用户刚发完消息但网络已经断掉了的情况下,表现形式如:就像手机qq或微信一样消息气泡边上会出现红色图标以示没有发送成功)。
  • 建议用途:应用层可通过回调中的指纹特征码找到原消息并可以UI上将其标记为“发送失败”以便即时告之用户。
  • 参数1:{Array}:由框架的QoS算法判定出来的未送达消息列表。

19)SocketEvent.SOCKET_EVENT_MESSAGE_BE_RECIEVED事件通知:

  • 用途:消息已被对方收到的回调事件通知。
  • 说明 :目前,判定消息被对方收到是有两种可能:1) 对方确实是在线并且实时收到了;2) 对方不在线或者服务端转发过程中出错了,由服务端进行离线存储成功后的反馈(此种情况严格来讲不能算是“已被收到”,但对于应用层来说,离线存储了的消息原则上就是已送达了的消息:因为用户下次登陆时肯定能通过HTTP协议取到)。
  • 建议用途:应用层可通过回调中的指纹特征码找到原消息并可以UI上将其标记为“发送成功”以便即时告之用户。
  • 参数1:{String}:已被收到的消息的指纹特征码(唯一ID),应用层可据此ID找到原先已发的消息并可在UI是将其标记为”已送达“或”已读“以便提升用户体验。

五、如何引入SDK库文件

5.1方法一:源码形式

第一步:先将整个sdk源码module复制到您的鸿蒙工程中:

第二步:配置您的工程,确保正确引用了MobileIMSDK鸿蒙SDK的源码module:

 

5.2方法二:.har包形式

第一步:先将MobileIMSDK鸿蒙端SDK的.har包放入您的鸿蒙Next主module中(比如新建的libs目录下):

第二步:配置您的工程,确保正确引用了MobileIMSDK鸿蒙SDK的.har包:

六、如何调用SDK代码

6.1第一步:设置ws/wss连接URL

设置您自已部署的MobileIMSDK服务端IP或域名的示例详见Demo中的 IMClientManager.ets 文件):

提示:MobileIMSDK的服务端Demo部署指南请见 http://www.52im.net/thread-63-1-1.html

6.2第二步:初始化SDK

调用ClientCoreSDK中的init()方法进行初始化(示例详见Demo中的I MClientManager.ets 文件):

6.3第三步:注册框架事件

注册MobileIMSDK框架级的事件监听(示例详见Demo中的 IMClientManager.ets 文件):

6.4第四步:调用登录方法(框架内部会自动启动connect全过程)

调用登录方法(示例详见Demo中的 LoginPage.ets 文件):

提示:不同于其它IM框架,本框架的登录和连接高度封装在了一个sendLogin方法中,无需单独再去connect服务器,大大简化了SDK的使用。

七、Demo运行效果和功能说明

八、Demo运行方法

8.1重要说明

特别说明:MobileIMSDK的鸿蒙端工程(包括Demo代码),不依赖任何第3方库,也不存在任何Native代码混编,完全使用ArkTS、ArkUI官方标准API实现,所以你在拿到MobileIMSDK的鸿蒙端工程后直接开箱即可运行,切莫搞复杂、不要私自加戏!

8.2配置要连接的MobileIMSDK服务器IP

注意:下图中登陆连接的IP地址请设置为您自已的MobileIMSDK服务器地址哦。

友情提示: MobileIMSDK的服务端该怎么部署就不是本手册要讨论的内容了,你可以参见《即时通讯框架MobileIMSDK的Demo使用帮助:Server端》。

▲ 配置要连接的服务器IP(以上代码详见IMClientManager.ets文件

8.3启动模拟器

注意:如果没有新建模拟器可以自已新建一个。另外也可以使用支持鸿蒙Next的真机,打开“开发者模式”并插入USB线即可使用。

 

▲ 点击绿色箭头,立即启动模拟器!

8.4一键运行

如下图所示,点击绿色“运行”按钮后,将自动在模拟器或真机里显示自带的Demo界面了:

8.5运行效果

1)Demo的登陆界面运行截图:

2)Demo的主界面运行截图:

3)Demo运行的同时,可以查看详细的log输出(方便调试):

九、引用资料

[1] 鸿蒙Next官方开发资料

[2] MobileIMSDK开源框架的API文档

[3] MobileIMSDK开源IM框架源码Github地址点此

[4] MobileIMSDK-鸿蒙Next端发布公告

[5] MobileIMSDK-鸿蒙Next端详细介绍

[6] MobileIMSDK-鸿蒙Next端开发手册* 精编PDF版

[7] MobileIMSDK的Server端Demo使用帮助

posted @ 2024-12-30 12:08 Jack Jiang 阅读(46) | 评论 (0)编辑 收藏

一、基本介绍

MobileIMSDK-鸿蒙端是一套基于鸿蒙Next(纯血鸿蒙)系统的IM即时通讯客户端库:

  • 1)超轻量级(编译后库文件仅50KB)、无任何第3方库依赖(开箱即用);
  • 2)纯ArkTS编写、无Native代码、高度提炼、简单易用;
  • 3)基于鸿蒙Next标准WebSocket  API,简洁优雅;
  • 4)可运行于任何支持鸿蒙Next的平台;
  • 5)能与 MobileIMSDK的各种客户端完美互通;
  • 6)可应用于鸿蒙Next中的消息推送、客服聊天、企业OA、IM等场景。

二、与MobileIMSDK的关系

MobileIMSDK-鸿蒙端是基于鸿蒙Next标准WebSocketAPI的 MobileIMSDK配套客户端库。

以下是MobileIMSDK的最新通信架构图:

MobileIMSDK是一套专为移动端开发的原创开源IM通信层框架:

  • 1)历经10年、久经考验;
  • 2)超轻量级、高度提炼,lib包50KB以内;
  • 3)精心封装,一套API同时支持UDP、TCP、WebSocket三种协议(可能是全网唯一开源的);
  • 4)客户端支持iOS、Android、标准Java、H5(暂未开源)、微信小程序(暂未开源)、Uniapp(暂未开源)、鸿蒙Next(Demo工程源码)new;
  • 5)服务端基于Netty,性能卓越、易于扩展;
  • 6)可与姊妹工程 MobileIMSDK-Web 无缝互通实现网页端聊天或推送等;
  • 7)可应用于跨设备、跨网络的聊天APP、企业OA、消息推送等各种场景。

PS:MobileIMSDK一直在持续开发和升级中,本鸿蒙客户端是MobileIMSDK工程的最新成果。

三、设计目标

直接使用鸿蒙Next的WebSocket API开撸,有以下问题和劣势:

  • 1)功能有限:没有心跳保活、断线重连、消息送达保证(重传和去重)等即时通讯关键算法和逻辑;
  • 2)API 简陋:在如此有限的API接口下,能逻辑清晰且健壮地实现并组合心跳保活、断线重连、消息送达保证等算法,需要相当高的技术掌控力;
  • 3)逻辑耦合:经验欠缺的开发人员,会将WebSocket通信逻辑与前端ArkUI界面代码混在一起,使得UI界面的编写、维护、改版都非常困难。

针对以上问题,而MobileIMSDK-鸿蒙端库将让开发者专注于UI应用层的开发,网络通信层的专业代码交由SDK开发人员,从而解偶UI前端和通信层的逻辑耦合性,大大降低技术复杂度和应用门槛。

MobileIMSDK-鸿蒙端库的设计目标是为您的开发带来以下便利:

  • 1)界面与通信解偶:UI界面与网络通信层代码解耦,UI界面的重构、维护、改版都非常容易和优雅;
  • 2)轻量级和兼容性:受益于坚持使用鸿蒙Next的标准WebSocket API,简洁轻量,无需任何额外库依赖;
  • 3)核心内聚和收敛:得益于长期的提炼和经验积累,SDK核心层高度封装,开发者无需理解复杂算法即可简单上手。
  • 4)纯 ArkTS 实现:纯ArkTS编写,无重量级框架和库依赖(更无Native代码),可干净利落地对接各种既有系统;
  • 5)跨平台运行能力:受益于鸿蒙系统的跨端特性,理论上本SDK可运行于任何支持鸿蒙Next的平台上。

四、技术亮点

  • 1)超级轻量纯净:超轻量级——纯ArkTS编写且无任何第3方库依赖,编译后库文件仅50KB;
  • 2)高内聚易使用:高度提炼——简单易用,所有核心类皆设计为单例——到手即用、高度容错;
  • 3)跨端支持好:基于鸿蒙Next的标准WebSocket API(无Native代码依赖),理论上可很好地运行于任何支持最新鸿蒙的平台上;
  • 4)断网恢复能力:拥有网络状况自动检测、断网自动治愈的能力;
  • 5)送达保证机制:完善的QoS消息送达保证机制(自动重传、消息去重、状态反馈等),不漏过每一条消息;
  • 6)通信协议封装:实现了一个对上层透明的即时通讯通信协议模型;
  • 7)身份认证机制:实现了简单合理的身份认证机制;
  • 8)完善的log信息:在开发调试阶段,确保每一个算法关键步骤都有日志输出,让您的运行调试更为便利;
  • 9)界面代码解耦:实现了UI界面代码与SDK网络通信代码解偶,防止界面代码跟IM核心代码混在一起,不利于持续升级、重用和维护;
  • 10)多端协议兼容:实现了与MobileIMSDK各种客户端完全兼容的协议模型。

五、文件组成

完整工程文件概览:

 

SDK代码文件用途说明:

精编注释级的源码:

六、Demo功能说明

点击可看大图 ▲

七、实际运行效果

1)Demo 的登陆界面运行截图(点击可看大图 ▼

2)Demo 的主界面运行截图(点击可看大图 ▼):

3)Demo 运行的同时,可以查看详细的 log 输出(方便调试

八、详尽开发者手册

① 开发者手册网页版):点此进入 

② 开发者手册PDF精编版):点此进入 * 推荐

九、相关资料

[1] 鸿蒙Next官方开发资料

[2] MobileIMSDK开源框架的API文档

[3] MobileIMSDK开源IM框架源码Github地址点此

[4] MobileIMSDK-鸿蒙Next端发布公告

[5] MobileIMSDK-鸿蒙Next端开发手册* 推荐

posted @ 2024-12-23 11:31 Jack Jiang 阅读(49) | 评论 (0)编辑 收藏

     摘要: 本文由小白debug分享,原题“能 ping 通,TCP 就一定能连通吗?”,下文进行了排版和内容优化。1、引言平时,我们想要知道,自己的机器到目的机器之间,网络通不通,一般会执行ping命令。一般对于状况良好的网络来说,你能看到它对应的loss丢包率为0%,也就是所谓的能ping通。如果看到丢包率100%,也就是ping不通。▲ ping正常▲ p...  阅读全文

posted @ 2024-12-19 11:29 Jack Jiang 阅读(54) | 评论 (0)编辑 收藏

本文由转转QA刘宝成分享,原题“抓包工具wireshark的使用”,下文进行了排版和内容优化。

1、引言

跟网络通信有关的应用场景下(比如Web系统、IM聊天应用、消息推送系统等),经常要用到网络抓包工具,用以验证客户端和服务器之间收发的数据包是否正确。以IM聊天系统为例,TLS/SSL加密开启到底有没有成功?加密效果怎么样?端到端加密后的聊天内容安全强度够不够?等等这些疑问,都需要通过网络抓包抓出样本来分析和验证。

Wireshark是一款开源和跨平台的抓包工具。它通过调用操作系统底层的API,直接捕获网卡上的数据包,因此捕获的数据包详细、功能强大。但Wireshark本身稍显复杂,本文将以用抓包实例,手把手带你一步步用好Wireshark,并真正理解抓到的数据包的各项含义。

 
 

2、系列文章

本文是系列文章中的第16篇,本系列文章的大纲如下:

网络编程懒人入门(一):快速理解网络通信协议(上篇)

网络编程懒人入门(二):快速理解网络通信协议(下篇)

网络编程懒人入门(三):快速理解TCP协议一篇就够

网络编程懒人入门(四):快速理解TCP和UDP的差异

网络编程懒人入门(五):快速理解为什么说UDP有时比TCP更有优势

网络编程懒人入门(六):史上最通俗的集线器、交换机、路由器功能原理入门

网络编程懒人入门(七):深入浅出,全面理解HTTP协议

网络编程懒人入门(八):手把手教你写基于TCP的Socket长连接

网络编程懒人入门(九):通俗讲解,有了IP地址,为何还要用MAC地址?

网络编程懒人入门(十):一泡尿的时间,快速读懂QUIC协议

网络编程懒人入门(十一):一文读懂什么是IPv6

网络编程懒人入门(十二):快速读懂Http/3协议,一篇就够!

网络编程懒人入门(十三):一泡尿的时间,快速搞懂TCP和UDP的区别

网络编程懒人入门(十四):到底什么是Socket?一文即懂!

网络编程懒人入门(十五):外行也能读懂的网络硬件设备功能原理速成

网络编程懒人入门(十六):手把手教你使用网络编程抓包神器Wireshark(* 本文)

3、Wireshak的安装和基本使用

安装:直接通过官方下载对应的安装包即可 https://www.wireshark.org/download.html

使用:

如上图所示:

  • 1)左上角为几个最常用的按钮:开始捕获、停止捕获、重新捕获、捕获选项;
  • 2)中间为捕获过滤器,用于过滤需要捕获的数据包;
  • 3)捕获过滤器下面可以选择需要捕获的网络连接。

下图是用Wireshark捕获的数据包:

可以看到,数据包结构是与OSI的七层模型相对应的,会详细显示每层的信息。

更多Wireshak的基本用法和手册,可以详读以下两篇:

  1. 理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程
  2. 网络通讯数据抓包和分析工具 Wireshark 使用教程(中文) [附件下载]

4、快速理解Wireshak的过滤器

由于Wireshark直接捕获底层网络数据包,导致其捕获的数据包数量通常较大。为了便于筛选数据包,Wireshark提供了两种过滤器。

4.1捕获过滤器

用于设置什么样的数据包保存在捕获结果中,避免产生过大的日志文件。

需要在开始捕获之前设置,相对简单:

捕获过滤器语法如上,一般用于过滤协议、IP、端口等基本信息。

例如:

  • 1)显示目的TCP端口为8080的包:tcp dst port 8080
  • 2)显示来源IP地址为192.168.171.201的封包:ip src host 192.168.171.201

4.2显示过滤器

用于在捕获日志中查找数据包,可以在捕获过程中或者捕获后随时更改。

功能更加强大和复杂:

显示过滤器语法如上,比捕获过滤器更为强大,可以针对不同协议,过滤不同的字段。

例如:

  • 1)源地址是192.168.171.0网段的数据包:ip.src == 192.168.171.0/24
  • 2)所有的HTTP POST请求:http.request.method== "POST"
  • 3)显示包含TCP SYN标志的包:tcp.flags.syn == 0×02
  • 4)URL中包含baidu的http请求:http.request.uri contains "baidu"

5、用什么例子来动手学习Wireshak?

本来想借用RainbowChat 这种IM聊天中的TLS/SSL数据包来的分析来实战Wireshak,但考虑到IM通常都是私有协议,不利于理解。

因而接下来的内容将以HTTPS为例,来详细讲解如何借助Wireshak抓出的数据包(正好也顺验证之前那么多跟TLS/SSL加密有关的文章),详细理解和学习Wireshak的使用,同进加深对HTTPS协议本身的理解。

6、什么是HTTPS

SSL/TLS:SSL (Secure Sockets Layer),最初由Netscape公司设计,后来逐渐演变为TLS(Transport Layer Security Protocol),即“传输层安全协议”。

该协议工作在TCP层之上,应用层之下。在TCP连接完成后,进行通信双方的身份认证,并协商一些跟加密相关的工作。完成协商之后,就可以对双方发送的信息进行加密/解密了。

HTTPS:可以理解为HTTP over SSL/TLS。即在SSL/TLS协议之上运行HTTP协议,以保证通信的安全性。

更多深入的学习,可以从下面这几篇精选的资料开始:

  1. 如果这样来理解HTTPS原理,一篇就够了
  2. 你知道,HTTPS用的是对称加密还是非对称加密?
  3. 为什么要用HTTPS?深入浅出,探密短连接的安全性
  4. 一分钟理解 HTTPS 到底解决了什么问题
  5. 一篇读懂HTTPS:加密原理、安全逻辑、数字证书等

7、HTTPS的SSL/TLS握手过程

SSL/TLS的握手过程主要需要解决两个问题:

  • 1)证明通信双方身份的真实性;
  • 2)协商后续通信过程中使用的密钥;

如下图所示:左侧是一个简单的握手流程,右侧为对应的抓包结果,我们可以对比分析一下SSL/TLS的握手过程。

1)C:ClientHello

客户端发送协议版本号、sessionid、随机数、加密算法列表、扩展字段等信息:

2)S:ServerHello

与客户端类似,不同之处在于确定了所使用的加密算法等:

3)S:Certificate

服务端向客户端发送自己的CA证书。客户端通过证书信任链查看该证书的真实性,以验证服务端的身份。其实SSL/TLS协议还支持客户端的CA证书验证,不过在实际中使用较少。

4)S:ServerKey Exchange

服务端根据之前选择的加密算法,传输密钥协商需要的参数。从之前的报文可以看到,这里选择的是EC-DH算法。

5)S:ServerHello Done

该报文表示服务端发送完成。

6)C:ClientKey Exchange

同理,客户端也要根据之前选择的加密算法,传输相应的参数。

7)C:ChangeCipher Spec

经过上述步骤,客户端和服务器双方已经完成了身份认证,并且交换了生成密钥的全部参数。双方会根据对应的算法,各自生成加密密钥,然后就可以进行加密通信了。这个报文表示切换到密文模式,后续消息都通过加密传输。

8)C:Finished

客户端表示握手完成。这里会发送一段Verify Data,是使用新生成的密钥加密后的一段信息。双方通过该信息验证加密算法、密钥是否有效。

9)S:Change Cipher Spec

10)S:Finished

服务段也会发送对应的两条消息作为回应,不再赘述。

8、解密HTTPS报文

握手完成之后,就可以查看客户端发出的HTTP请求了。但我们看到的只是一段加密后的字符串?那么如何对HTTPS报文进行解密呢?

要想解密HTTPS报文,就必须要获取到加密密钥。Chrome、Firefox等浏览器支持将访问网站时使用的密钥输出到文件中。仅需要配置环境变量SSLKEYLOGFILE 即可。

如下:

然后需要将该密钥文件导入到Wireshark中。打开编辑-首选项,选择Protocol-SSL,填写刚才设置的文件路径。

现在,就可以通过Wireshark查看HTTPS请求中的具体信息了!

9、参考资料

[1] TCP/IP详解 - 第17章·TCP:传输控制协议

[2] 理论经典:TCP协议的3次握手与4次挥手过程详解

[3] 理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程

[4] 网络通讯数据抓包和分析工具 Wireshark 使用教程(中文) [附件下载]

[5] 如果这样来理解HTTPS原理,一篇就够了

[6] 你知道,HTTPS用的是对称加密还是非对称加密?

[7] 为什么要用HTTPS?深入浅出,探密短连接的安全性

[8] 一分钟理解 HTTPS 到底解决了什么问题

[9] 一篇读懂HTTPS:加密原理、安全逻辑、数字证书等

[10] IM聊天系统安全手段之通信连接层加密技术

[11] IM聊天系统安全手段之传输内容端到端加密技术

[12] 传输层安全协议SSL/TLS的Java平台实现简介和Demo演示

[13] 微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解

[14] 手把手教你为基于Netty的IM生成自签名SSL/TLS证书


(本文已同步发布于:http://www.52im.net/thread-4752-1-1.html

posted @ 2024-12-12 11:24 Jack Jiang 阅读(73) | 评论 (0)编辑 收藏

     摘要: 本文由转转技术团队刘筱雨分享,原题“一文读懂浏览器本地存储:Web Storage”,下文进行了排版和内容优化。1、引言鉴于目前浏览器技术的进步(主要是HTML5的普及),在Web网页端IM聊天应用的技术选型阶段,很多开发者都会纠结到底该不该像原生移动端IM那样将聊天记录缓存在浏览器的本地,还是像传统Web端即时通讯那样继续存储在服务端?本文将为你简洁明了地讲清楚浏览器本地...  阅读全文

posted @ 2024-11-28 11:00 Jack Jiang 阅读(75) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第44 期。

[-1-]  微信朋友圈千亿访问量背后的技术挑战和实践总结

[链接] http://www.52im.net/thread-1569-1-1.html

[摘要] 朋友圈的数据是永远存储的,而且随着业务的快速发展,存储容量、带宽和设备的消耗大量增加,尤其重大节日带来的使用量增长,更加剧了消耗,也给运维人员的保障带来了巨大压力。


[-2-] 腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)

[链接] http://www.52im.net/thread-1559-1-1.html

[摘要] 本次文章跟大家分享如何在保障质量(指的是图片质量、音视频质量)前提下所做的带宽和网络流量压缩,进而达到运营成本的优化。


[-3-] 腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)

[链接] http://www.52im.net/thread-1560-1-1.html

[摘要] 本文接上篇《腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》,继续腾讯公司分享如何在保障质量(指的是图片质量、音视频质量)前提下所做的带宽和网络流量压缩,进而达到运营成本的优化。


[-4-] IM全文检索技术专题(二):微信移动端的全文检索多音字问题解决方案

[链接] http://www.52im.net/thread-1545-1-1.html

[摘要] 本文重点讲述微信安卓客户端在SQLite FTS5的基础上,多音字问题的解决方案。


[-5-] 腾讯技术分享:Android版手机QQ的缓存监控与优化实践

[链接] http://www.52im.net/thread-1524-1-1.html

[摘要] 对于Android应用来说,内存向来是比较重要的性能指标。内存占用过高,会影响应用的流畅度,甚至引发OOM,非常影响用户体验。因此,内存优化也向来是行业内的重点工作项和难点工作项。


[--] 微信团队分享:iOS版微信的高性能通用key-value组件技术实践

[链接] http://www.52im.net/thread-1461-1-1.html

[摘要] 本文要分享的是iOS版微信内部正在推广和使用的一个高性能通用key-value 组件的技术实践过程,该组件在微信内部被命名为MMKV(以下简称MMKV)。


[-7-] 微信团队分享:iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的?

[链接] http://www.52im.net/thread-1449-1-1.html

[摘要] 一般来说,特殊字符闪退是系统漏洞引起,只要更新系统就行。但大部分用户不愿意更新系统,而苹果也不一定第一时间解决问题。另外后台可以拦截恶意文本传递,但对于本地已下发的消息,后台没有办法让它删除。所以客户端还是要做些保护预防特殊字符闪退。


[-8-] 腾讯技术分享:Android手Q的线程死锁监控系统技术实践

[链接] http://www.52im.net/thread-1442-1-1.html

[摘要] 本文将详细介绍Android版手Q中这套线程卡死监控系统设计思路以及技术实践总结。


[-9 -]  微信团队原创分享:iOS版微信的内存监控系统技术实践

[链接] http://www.52im.net/thread-1422-1-1.html

[摘要] 二期版本以Instruments的Allocations为参考,着重四个方面优化,分别是数据收集、存储、上报及展现。


[-10-] 让互联网更快:新一代QUIC协议在腾讯的技术实践分享

[链接] http://www.52im.net/thread-1407-1-1.html

[摘要] 本文主要介绍 QUIC 协议在腾讯内部及腾讯云上的实践和性能优化,新一代的互联网协议需要大家一起努力推动,你准备好了吗?


[-11 -] iOS后台唤醒实战:微信收款到账语音提醒技术总结

[链接] http://www.52im.net/thread-1404-1-1.html

[摘要] 本文借此总结了iOS平台上的APP后台唤醒和语音合成、播放等一系列技术开发过程中遇到的坑和小技巧,希望与您分享。


[-12 -] 腾讯技术分享:社交网络图片的带宽压缩技术演进之路

[链接] http://www.52im.net/thread-1391-1-1.html

[摘要] 为了进一步降低运营带宽成本,减小用户访问流量及提升页面加载速度,社交网络 CDN运维紧跟行业图片优化趋势,创新引入WebP、SharpP、自适应分辨率、Guetzli等图像压缩技术到现网,经过三年多的多部门联合攻关,已逐渐形成一套覆盖全图片类型(JPEG、JPG、PNG、WebP、GIF)多场景的图片压缩运营体系,适用于各类型终端,每年节约外网带宽几百G。


[-13 -] 微信团队分享:视频图像的超分辨率技术原理和应用场景

[链接] http://www.52im.net/thread-1377-1-1.html

[摘要] 本文试着讲述超分辨率技术的正确打开方式,浅谈视频图像的超分辨率技术的基本概念和应用场景等问题。


[-14 -] 微信团队分享:微信每日亿次实时音视频聊天背后的技术解密

[链接] http://www.52im.net/thread-1311-1-1.html

[摘要] 本文将为大家介绍微信实时音视频聊天在不同发展阶段的各个关键视频技术环节采用的方案,同时分享在实时音视频聊天中的视频编码器研发的方法和经验。


👉52im社区本周新文:《Web端IM聊天消息该不该用浏览器本地存储?一文即懂!》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2024-11-27 11:06 Jack Jiang 阅读(72) | 评论 (0)编辑 收藏

     摘要: 本文由得物技术WWQ分享,原题“基于IM场景下的Wasm初探:提升Web应用性能”,下文进行了排版和内容优化。1、什么是WasmWasm,全称 WebAssembly,官网描述是一种用于基于堆栈的虚拟机的二进制指令格式。Wasm被设计为一个可移植的目标,用于编译C/C++/Rust等高级语言,支持在Web上部署客户端和服务器应用程序。简单的来说,Wasm就是使用C...  阅读全文

posted @ 2024-11-21 12:56 Jack Jiang 阅读(77) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第 43 期。

[-1-] 直播系统聊天技术(一):百万在线的美拍直播弹幕系统的实时推送技术实践之路

[链接] http://www.52im.net/thread-1236-1-1.html

[摘要] 直播弹幕指直播间的用户,礼物,评论,点赞等消息,是直播间交互的重要手段。美拍直播弹幕系统从 2015 年 11 月到现在,经过了三个阶段的演进,目前能支撑百万用户同时在线。比较好地诠释了根据项目的发展阶段进行平衡演进的过程。这三个阶段分别是快速上线、高可用保障体系建设、长连接演进。具体我将在正文中展开,请继续往下阅读。


[-2-] 直播系统聊天技术(二)阿里电商IM消息平台,在群聊、直播场景下的技术实践

[链接] http://www.52im.net/thread-3252-1-1.html

[摘要] 本文来自淘宝消息业务团队的技术实践分享,分析了电商IM消息平台在非传统IM应用场景下的高发并、强互动群聊和直播业务中的技术特点,总结并分享了在这些场景下实现大量多对多实时消息分发投递的一些架构方面的设计实践。


[-3-] 直播系统聊天技术(三):微信直播聊天室单房间1500万在线的消息架构演进之路

[链接] http://www.52im.net/thread-3376-1-1.html

[摘要] 本文将回顾微信直播聊天室单房间海量用户同时在线的消息组件技术设计和架构演进,希望能为你的直播聊天互动中的实时聊天消息架构设计带来启发。


[-4-] 直播系统聊天技术(四):百度直播的海量用户实时消息系统架构演进实践

[链接] http://www.52im.net/thread-3515-1-1.html

[摘要] 本文主要分享的是百度直播的消息系统的架构设计实践和演进过程。


[-5-] 直播系统聊天技术(五):微信小游戏直播在Android端的跨进程渲染推流实践

[链接] http://www.52im.net/thread-3594-1-1.html

[摘要] 微信小游戏出于性能和安全等一系列考虑,运行在一个独立的进程中,在该环境中不会初始化视频号直播相关的模块。这就意味着小游戏的音视频数据必须跨进程传输到主进程进行推流,给我们实现小游戏直播带来了一系列挑战。


[-6-] 直播系统聊天技术(六):百万人在线的直播间实时聊天消息分发技术实践

[链接] http://www.52im.net/thread-3799-1-1.html

[摘要] 本文将基于融云在直播技术实践的背景,分享了单直播间百万用户在线量的实时消息分发的技术经验总结,希望带给你启发。


[-7-] 直播系统聊天技术(七):直播间海量聊天消息的架构设计难点实践

[链接] http://www.52im.net/thread-3835-1-1.html

[摘要] 本文将主要从高可用、弹性扩缩容、用户管理、消息分发、客户端优化等角度,分享直播间海量聊天消息的架构设计技术难点的实践经验。


[-8-] 视频直播技术干货(十一):超低延时视频直播技术的演进之路

[链接] http://www.52im.net/thread-4587-1-1.html

[摘要] 本文将带您了解超低延时视频直播技术的优化和演进历程。


[-9 -]  视频直播技术干货(十二):从入门到放弃,快速学习Android端直播技术

[链接] http://www.52im.net/thread-4714-1-1.html

[摘要] 本文详细介绍了Android端直播技术的全貌,涵盖了从实时音视频采集、编码、传输到解码与播放的各个环节。文章还探讨了直播中音视频同步、编解码器选择、传输协议以及直播延迟优化等关键问题。希望本文能为你提供有关Andriod端直播技术的深入理解和实践指导。


[-10-] 海量实时消息的视频直播系统架构演进之路(视频+PPT)[附件下载]

[链接] http://www.52im.net/thread-1562-1-1.html

[摘要] 本次主要分享的是融云视频直播互动平台的实时消息可靠性的设计方案,支撑无上限消息并发的架构演进,单机吞吐性能的优化历程。


[-11 -] YY直播在移动弱网环境下的深度优化实践分享(视频+PPT)[附件下载]

[链接] http://www.52im.net/thread-1379-1-1.html

[摘要] 本次分享介绍了 YY 直播针对质量较差网络(简称弱网)的环境,基于数据分析,在客户端和云端所采取的一系列技术手段。 同时,就如何改善上下行网络环境,也给出自己的一些解决方案。


[-12 -] 从0到1:万人在线的实时音视频直播技术实践分享(视频+PPT) [附件下载]

[链接] http://www.52im.net/thread-213-1-1.html

[摘要] 本次分享由“跟谁学”CTO带来,介绍跟谁学的团队是怎样在很短的时间内,构建了一个支持万人实时音视频直播的在线教室。


[-13 -] 在线音视频直播室服务端架构最佳实践(视频+PPT) [附件下载]

[链接] http://www.52im.net/thread-196-1-1.html

[摘要] 本期演讲嘉宾将为大家带来金山视频云在社交直播场景的支撑技术架构和优化方案。


👉52im社区本周新文:《Wasm在即时通讯IM场景下的Web端应用性能提升初探》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2024-11-20 11:34 Jack Jiang 阅读(83) | 评论 (0)编辑 收藏

     摘要: 本文由携程技术团队Aaron分享,原题“干货 | 携程弱网识别技术探索”,下文进行了排版和内容优化。1、引言网络优化一直是移动互联网时代的热议话题,弱网识别作为移动端弱网优化的第一步,受到的关注和讨论也是最多的。本文从方案设计、代码开发到技术落地,详尽的分享了携程在移动端弱网识别方面的实践经验,如果你也有类似需求,这篇文章会是一个不错的实操指南。技术交流:- 移动端IM开发...  阅读全文

posted @ 2024-11-14 11:14 Jack Jiang 阅读(77) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第42 期。

[-1-] 实时音频的混音在视频直播中的技术原理和实践总结

[链接] http://www.52im.net/thread-1904-1-1.html

[摘要] 今天,我们就来聊一聊混音技术在视频直播应用中的实现原理、方案等,及其在创新玩法中的实践应用。


[-2-] 七牛云技术分享:使用QUIC协议实现实时视频直播0卡顿!

[链接] http://www.52im.net/thread-1406-1-1.html

[摘要] 不做任何开发,就能实现弱网环境下实现实时视频直播零卡顿,听上去是不是天方夜谭?看完这篇文章你就知道,我们是如何做到的。


[-3-] 近期大热的实时直播答题系统的实现思路与技术难点分享

[链接] http://www.52im.net/thread-1369-1-1.html

[摘要] 我们首先分析一下直播答题和传统直播在技术上的不同,然后深度解释一下直播答题解决方案的海量并发派题和收题。


[-4-] P2P技术如何将实时视频直播带宽降低75%?

[链接] http://www.52im.net/thread-1289-1-1.html

[摘要] 那整个系统是怎么设计的?使用了哪些技术来达成目标?接下来我来重点分享一下架构设计和技术细节。


[-5-] 网易云信实时视频直播在TCP数据传输层的一些优化思路

[链接] http://www.52im.net/thread-1254-1-1.html

[摘要] 网易云信的实时视频直播目前使用了TCP进行传输,且基于此,从编码动态适配、发送队列调整、协议优化、socket等做了全流程的优化,确保在限带宽、丢包、时延、抖动,无论单项还是复杂网络,都有非常不错的实际体验。


[--] 首次披露:快手是如何做到百万观众同场看直播仍能秒开且不卡顿的?

[链接] http://www.52im.net/thread-1033-1-1.html

[摘要] 快手拥有5亿注册用户,单个直播间人数峰值已经超过180万,他们针对海量用户,基于大数据技术,在首屏和流畅度优化上做了大量的探索与实践。快手直播是如何设计全链路质量监控方案、如何搭建大数据处理Pipeline 、如何解决开播跳帧、首屏卡顿优化等问题的?本文干货满满,全面解密快手直播大数据技术架构与优化实践。


[-7-] 浅谈实时音视频直播中直接影响用户体验的几项关键技术指标

[链接] http://www.52im.net/thread-953-1-1.html

[摘要] 这两年互联网领域的一个热门关键词就是实时音视频直播,从刚开始的游戏直播和秀场娱乐开始,实时音视频直播带来了远超传统互动的用户体验,现在实时音视频直播已逐渐深入当今主流的互联网应用形态里。我们将逐一分析和总结实时音视频直播中的这几个重要技术指标。


[-8-] 技术揭秘:支持百万级粉丝互动的Facebook实时视频直播

[链接] http://www.52im.net/thread-541-1-1.html

[摘要] 在这篇文章中,我们将粗略地看一下我们在每次发布时解决的问题,我还将向你解释我们为负载均衡和 RTMP 实现问题所选择的解决方案。


[--]  移动端实时视频直播技术实践:如何做到实时秒开、流畅不卡

[链接] http://www.52im.net/thread-530-1-1.html

[摘要] 本次分享将为大家揭开移动端实时音视频直播核心技术的神秘面纱。


[-10-] 实现延迟低于500毫秒的1080P实时音视频直播的实践分享

[链接] http://www.52im.net/thread-528-1-1.html

[摘要] 实时视频直播是很多技术团队及架构师关注的问题,在实时性方面,大部分直播是准实时的——存在 1-3 秒延迟。本文由袁荣喜分享其将1080P高清实时视屏直播延迟控制在 500ms 的背后的技术挑战以及实践结论等,期待与各同行共同讨论、学习和进步。


[-11 -] 浅谈开发实时视频直播平台的技术要点

[链接] http://www.52im.net/thread-475-1-1.html

[摘要] 现在大大小小的公司,甚至个人开发者,都想开发自己的直播网站或App,本文会帮你理清,开发视频直播平台,你需要注意哪些技术要点。


[-12 -] 海量用户IM聊天室的架构设计与实践

[链接] http://www.52im.net/thread-4404-1-1.html

[摘要] 本文将分享网易云信针对海量用户IM聊天室的架构设计与应用实践,希望能带给你启发。


[-13 -] 微信团队分享:详解iOS版微信视频号直播中因帧率异常导致的功耗问题

[链接] http://www.52im.net/thread-4507-1-1.html

[摘要] 功耗优化一直是 app 性能优化中让人头疼的问题,尤其是在直播这种用户观看时长特别久的场景。怎样能在不影响主体验的前提下,进一步优化微信iOS端视频号直播的功耗占用,本文给出了一个不太一样的答案。


👉52im社区本周新文:《移动端弱网优化专题(十四):携程APP移动网络优化实践(弱网识别篇)》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2024-11-13 11:58 Jack Jiang 阅读(74) | 评论 (0)编辑 收藏

     摘要: 本文由微信后台Astra项目团队分享,原题“Ray在微信AI计算中的大规模实践”,下文进行了排版和内容优化。1、引言微信存在大量AI计算的应用场景,主要分为三种:流量分发、产品运营和内容创作。流量分发场景中的 AI 计算主要用于搜索、广告、推荐场景的核心特征生产,产品运营相关的 AI 计算主要用于产品功能相关和内容运营相关(低质、优质、生态建设),由于大模型的兴起,AIGC...  阅读全文

posted @ 2024-11-07 11:07 Jack Jiang 阅读(89) | 评论 (0)编辑 收藏

     摘要: 本文来自微信团队工程师张文瑞的技术分享,由InfoQ编辑发布,下文有修订和改动。原文地址:infoq.cn/article/1-billion-bonus-from-the-clouds,感谢原作者的分享。一、引言与传统意义上的红包相比,手机端的红包似乎更符合现在年轻一代的习惯。这其中,以春节发红包最为流行。以微信为例,除夕全天微信用户红包总发送量可以达到百亿个,红包峰值收发量为比百万个/秒。本文...  阅读全文

posted @ 2024-11-06 11:52 Jack Jiang 阅读(70) | 评论 (0)编辑 收藏

     摘要: 本文由LearnLHC分享,原始出处:blog.csdn.net/LearnLHC/article/details/115268028,本文进行了排版和内容优化。1、引言熟悉网络编程的(尤其搞实时音视频聊天技术的)同学们都有个约定俗成的主观论调,一提起UDP和TCP,马上想到的是UDP没有TCP可靠,但UDP肯定比TCP高效。说到UDP比TCP高效,理由是什么呢?事实真是这样吗?跟着本文咱们一探究...  阅读全文

posted @ 2024-10-30 11:31 Jack Jiang 阅读(73) | 评论 (0)编辑 收藏

关于MobileIMSDK

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架,超轻量级、高度提炼,一套API优雅支持 UDP 、TCP 、WebSocket 三种协议,支持 iOS、Android、H5、标准Java、小程序、Uniapp,服务端基于Netty编写。

工程开源地址是:

关于RainbowChat

► 详细产品介绍:http://www.52im.net/thread-19-1-1.html
► iOS端更新记录:http://www.52im.net/thread-2735-1-1.html
► 全部运行截图:iOS端全部运行截图 (另:Android端运行截图 点此查看
► 在线体验下载:App Store安装地址 (另:Android端下载体验 点此查看

 

RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品,解决了大量的屏幕适配、细节优化、机器兼容问题(可自行下载体验:专业版下载安装)。

RainbowChat可能是市面上提供im即时通讯聊天源码的,唯一一款同时支持TCP、UDP两种通信协议的IM产品(通信层基于开源IM聊天框架 MobileIMSDK 实现)。

v9.1 版更新内容

此版更新内容更多历史更新日志):

  • 1)[bug] 解决了与Web产品互通时,收到撤回被引用消息的指令时会崩溃的问题;
  • 2)[bug] 解决了“查换用户”界面中精确查找时,输入内容时会导致底部按钮等控件显示高度被错误改变的问题;
  • 3)[bug] 解决了聊天输入框中自定义表情和数字、英文混输时,表情图标会消失的问题;
  • 4)[优化] 更换了位置消息中的高德地图AppKey,解决每日调用量限制问题;
  • 5)[优化] 优化了首页“消息”列表中单聊类型未正确同步时的收发消息和点击后的处理逻辑;
  • 6)[优化] 聊天消息自动识别电话、网址、邮箱等内容,点击自动跳转到系统功能;
  • 7)[优化] 优化了首页“消息”列表中同一好友和陌生人会话不能自动合并的问题。

部分功能运行截图(更多截图点此查看):

posted @ 2024-10-29 12:23 Jack Jiang 阅读(71) | 评论 (0)编辑 收藏

     摘要: 1、引言当你在浏览器输入 qq.com 按下回车键,到页面呈现在你面前,整个过程发生了什么?我以前思考过这个问题,从最前面的浏览器到最后的 db 都梳理的一遍,触发了一次技术顿悟,将很多散落的知识点贯通起来了。本文将抛弃千篇一律的计网知识理论,从现实的互联网技术实践角度,一步步为你分享一次网络请求背后的技术秘密。 技术交流:- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端I...  阅读全文

posted @ 2024-10-24 11:34 Jack Jiang 阅读(117) | 评论 (0)编辑 收藏

一、关于RainbowChat-Web

RainbowChat-Web是一套Web网页端IM系统,是RainbowChat的姊妹系统(RainbowChat是一套基于开源IM聊天框架 MobileIMSDK (Github地址)  的产品级移动端IM系统)。

二、v7.2 版更新内容

此版更新内容更多历史更新日志):

  • 1)[bug] [前端]      - 解决了加载首页聊天记录时,存在极小概率出现消息重复的问题;
  • 2)[bug] [前端]      - 解决了Firefox浏览器中右键无法复制文本消息的问题;
  • 3)[bug] [服务端]   - 升级了MobileIMSDK-Web库,解决了服务端QoS机制C2S消息路径时去重逻辑未起效的问题;
  • 4)[优化] [前端]     - 解决了引用的名片消息不会显示默认头像的问题;
  • 5)[优化] [前端]     - 重构了相关的类名、文件名等;
  • 6)[优化] [服务端]  - 优化了离线消息处理效率(异步化、无锁队列、批量处理、事务合并);
  • 7)[优化] [服务端]  - 优化了聊天记录处理效率(异步化、无锁队列、批量处理、事务合并);
  • 8)[优化] [服务端]  - 优化了“接口1008-26-8”,使按时间戳加载的消息在客户端不发生重复;
  • 9)[优化] [服务端]  - 修改了离线消息、聊天记录异步定时器实现,使之运行更健壮;
  • 10)[重构] [服务端] - 重构了通用http服务端工程、MQ工程目录名等;

三、主要功能特性截图

主要功能特性截图(更多运行截图运行视频

posted @ 2024-10-21 14:20 Jack Jiang 阅读(45) | 评论 (0)编辑 收藏

     摘要: 本文由陆业聪分享,原题“一文掌握直播技术:实时音视频采集、编码、传输与播放”,本文进行了排版和内容优化。1、引言从游戏、教育、电商到娱乐,直播技术的应用场景无处不在。随着移动端的网速越来越快,直播技术的普及和发展将更加迅速。本文详细介绍了Android端直播技术的全貌,涵盖了从实时音视频采集、编码、传输到解码与播放的各个环节。文章还探讨了直播中音视频同步、编解码器选择、传输...  阅读全文

posted @ 2024-10-17 11:10 Jack Jiang 阅读(67) | 评论 (0)编辑 收藏

关于RainbowChat

RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品,解决了大量的屏幕适配、细节优化、机器兼容问题(可自行下载体验:专业版下载安装)。

* RainbowChat可能是市面上提供im即时通讯聊天源码的,唯一一款同时支持TCP、UDP两种通信协议的IM产品(通信层基于开源IM聊天框架  MobileIMSDK 实现)。

► 详细产品介绍:http://www.52im.net/thread-19-1-1.html
► 版本更新记录:http://www.52im.net/thread-1217-1-1.html
► 全部运行截图:Android端iOS端
► 在线体验下载:专业版(TCP协议)专业版(UDP协议)      (关于 iOS 端,请:点此查看

关于MobileIMSDK

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架,超轻量级、高度提炼,一套API优雅支持UDP 、TCP 、WebSocket 三种协议,支持iOS、Android、H5、小程序、Uniapp、标准Java平台,服务端基于Netty编写。

工程开源地址:

v11.7 版更新内容

此版更新内容更多历史更新日志):

(1)Android端主要更新内容:

  • 1)[优化] 优化了首页“消息”列表中单聊类型未正确同步时的收发消息和点击后的处理逻辑;
  • 2)[优化] 优化了首页“消息”列表中同一好友和陌生人会话不能自动合并的问题;

(2)服务端主要更新内容:

  • 1)[优化] 大幅提升群聊性能(改进离线消息存储方式等:异步提交、批量处理);
  • 2)[优化] 升级了mysql驱动至最新版8.4.0;
  • 3)[优化] 优化了离线消息处理性能(异步化、无锁队列、批量处理、事务合并);
  • 4)[优化] 优化了聊天记录处理性能(异步化、无锁队列、批量处理、事务合并);
  • 5)[优化] 优化了“接口1008-26-8”,使得与Web产品联合部署明web前端按时间戳加载的消息不与客户端发生重复;
  • 6)[优化] 修改了离线消息、聊天记录异步定时器实现,使之运行更健壮;
  • 7)[优化] 加好友成功后将成功通知保存至离线消息和消息记录。

部分功能运行截图更多截图点此查看):

posted @ 2024-10-16 10:16 Jack Jiang 阅读(57) | 评论 (0)编辑 收藏

     摘要: 本文由百度技术团队分享,引用自百度Geek说,原题“百度Android IM SDK组件能力建设及应用”,本文进行了排版和内容优化。1、引言移动互联网时代,随着社交媒体、移动支付、线上购物等行业的快速发展,对即时通讯功能的需求不断增加。对于各APP而言,接入IM SDK(即时通讯软件开发工具包)能够大大降低开发成本、提高开发效率,快速构建自己的IM系统。本文主要介绍了百度公...  阅读全文

posted @ 2024-10-10 12:35 Jack Jiang 阅读(74) | 评论 (0)编辑 收藏

     摘要: 本文来自微信团队工程师张文瑞的技术分享,由“极客邦科技Geekbang”编辑发布,下文有修订和改动。一、开场白谢谢大家!我是来自腾讯WXG技术架构部的张文瑞,今天下午跟大家分享的主题是:微信团队是如何从0到1实现“有把握”的微信春晚摇一摇红包系统的。回忆一下春晚的活动,有什么样的活动形式呢?当时我们是直接复用客户端摇一摇入口,专门给春晚摇一摇定制了一...  阅读全文

posted @ 2024-10-10 10:18 Jack Jiang 阅读(138) | 评论 (0)编辑 收藏

     摘要: 1、前言在猴年新春的时候,腾讯当时推出了新春广告片(点击观看视频),作为《弹指间 心无间》的延续。片中通过春节期间发送QQ红包让家人打车回家团聚,让我们感受到了“最温暖的红包,给最爱的人”那种弹指间的感动。而就在这弹指一挥间,此次腾讯新春广告片距离2011年腾讯发布《弹指间 心无间》“亲情篇”已经好几年过去了。在这几年的时间里,腾讯QQ从音频、视频、...  阅读全文

posted @ 2024-09-29 12:18 Jack Jiang 阅读(91) | 评论 (0)编辑 收藏

本文由萤火架构分享,原题“localhost和127.0.0.1的区别是什么?”,原文链接“juejin.cn/post/7321049446443417638”,下文进行了排版和内容优化。

1、引言

继《你真的了解127.0.0.1和0.0.0.0的区别?》、《深入操作系统,彻底搞懂127.0.0.1本机网络通信》之后,这是整理收录的第3篇有关本机网络的网络编程基础文章。以下是正文内容。

今天在网上逛的时候看到一个问题,没想到大家讨论的很热烈,就是标题中这个:

前端同学本地调试的时候,应该没少和localhost打交道吧,只需要执行 npm run 就能在浏览器中打开你的页面窗口,地址栏显示的就是这个 http://localhost:xxx/index.html。

可能大家只是用,也没有去想过这个问题。联想到我之前合作过的一些开发同学对它们俩的区别也没什么概念,所以我觉得有必要普及下。

 
 

2、系列文章

本文是该系列文章中的第 4 篇:

网络编程入门如此简单(一):假如你来设计网络,会怎么做?

网络编程入门如此简单(二):假如你来设计TCP协议,会怎么做?

网络编程入门如此简单(三):什么是IPv6?漫画式图文,一篇即懂!

网络编程入门如此简单(四):一文搞懂localhost和127.0.0.1》(* 本文)

3、localhost是什么呢?

localhost是一个域名,和大家上网使用的域名没有什么本质区别,就是方便记忆。

只是这个localhost的有效范围只有本机,看名字也能知道:local就是本地的意思。

张三和李四都可以在各自的机器上使用localhost,但获取到的也是各自的页面内容,不会相互打架。

4、从域名到程序

要想真正的认清楚localhost,我们还得从用户是如何通过域名访问到程序说起。

以访问百度为例。

1)当我们在浏览器输入 baidu.com 之后,浏览器首先去DNS中查询 baidu.com 的IP地址。

为什么需要IP地址呢?打个比方,有个人要寄快递到你的公司,快递单上会填写:公司的通讯地址、公司名称、收件人等信息,实际运输时快递会根据通信地址进行层层转发,最终送到收件人的手中。网络通讯也是类似的,其中域名就像公司名称,IP地址就像通信地址,在网络的世界中只有通过IP地址才能找到对应的程序。(请详读《什么是公网IP和内网IP?NAT转换又是什么鬼?》)

DNS就像一个公司黄页,其中记录着每个域名对应的IP地址,当然也有一些域名可能没做登记,就找不到对应的IP地址,还有一些域名可能会对应多个IP地址,DNS会按照规则自动返回一个。我们购买了域名之后,一般域名服务商会提供一个域名解析的功能,就是把域名和对应的IP地址登记到DNS中。(请详读《理论联系实际,全方位深入理解DNS》)

这里的IP地址从哪里获取呢?每台上网的电脑都会有1个IP地址,但是个人电脑的IP地址一般是不行的,个人电脑的IP地址只适合内网定位,就像你公司内部的第几栋第几层,公司内部人明白,但是直接发给别人,别人是找不到你的。

如果你要对外部提供服务,比如百度这种,你就得有公网的IP地址,这个IP地址一般由网络服务运营商提供,比如你们公司使用联通上网,那就可以让联通给你分配一个公网IP地址,绑定到你们公司的网关服务器上,网关服务器就像电话总机,公司内部的所有网络通信都要通过它,然后再在网关上设置转发规则,将网络请求转发到提供网络服务的机器上。

2)有了IP地址之后,浏览器就会向这个IP地址发起请求,通过操作系统打包成IP请求包,然后发送到网络上。

网络传输有一套完整的路由协议,它会根据你提供的IP地址,经过路由器的层层转发,最终抵达绑定该IP的计算机。

3)计算机上可能部署了多个网络应用程序,这个请求应该发给哪个程序呢?

这里有一个端口的概念,每个网络应用程序启动的时候可以绑定一个或多个端口,不同的网络应用程序绑定的端口不能重复,再次绑定时会提示端口被占用。

通过在请求中指定端口,就可以将消息发送到正确的网络处理程序。但是我们访问百度的时候没有输入端口啊?这是因为默认不输入就使用80和443端口,http使用80,https使用443。我们在启动网络程序的时候一定要绑定一个端口的,当然有些框架会自动选择一个计算机上未使用的端口。

5、localhost和127.0.0.1的区别是什么?

有了前面的知识储备,我们就可以很轻松的搞懂这个问题了。

localhost是域名,上文已经说过了。

127.0.0.1 呢?是IP地址,当前机器的本地IP地址,且只能在本机使用,你的计算机不联网也可以用这个IP地址,就是为了方便开发测试网络程序的。

我们调试时启动的程序就是绑定到这个IP地址的。

这里简单说下,我们经常看到的IP地址一般都是类似 X.X.X.X 的格式,用"."分成四段。其实它是一个32位的二进制数,分成四段后,每一段是8位,然后每一段再转换为10进制的数进行显示。

那localhost是怎么解析到127.0.0.1的呢?经过DNS了吗?没有。每台计算机都可以使用localhost和127.0.0.1,这没办法让DNS来做解析。

那就让每台计算机自己解决了。每台计算机上都有一个host文件,其中写死了一些DNS解析规则,就包括 localhost 到 127.0.0.1 的解析规则,这是一个约定俗成的规则。

如果你不想用localhost,那也可以,随便起个名字,比如 wodehost,也解析到 127.0.0.1 就行了。

甚至你想使用 baidu.com 也完全可以,只是只能自己自嗨,对别人完全没有影响。

PS:以下两篇可以深入进行阅读:

  1. 你真的了解127.0.0.1和0.0.0.0的区别?
  2. 深入操作系统,彻底搞懂127.0.0.1本机网络通信

6、域名的等级划分

localhost不太像我们平常使用的域名,比如 www.juejin.cn 、baidu.com、csdn.net, 这里边的 www、cn、com、net都是什么意思?localhost为什么不需要?

域名其实是分等级的,按照等级可以划分为顶级域名、二级域名和三级域名...

1)顶级域名(TLD):

顶级域名是域名系统中最高级别的域名。它位于域名的最右边,通常由几个字母组成。顶级域名分为两种类型:通用顶级域名和国家顶级域名。常见的通用顶级域名包括表示工商企业的.com、表示网络提供商的.net、表示非盈利组织的.org等,而国家顶级域名则代表特定的国家或地区,如.cn代表中国、.uk代表英国等。

2)二级域名(SLD):

二级域名是在顶级域名之下的一级域名。它是由注册人自行选择和注册的,可以是个性化的、易于记忆的名称。例如,juejin.cn 就是二级域名。我们平常能够申请到的也是这种。目前来说申请 xxx.com、xxx.net、xxx.cn等等域名,其实大家不太关心其顶级域名com\net\cn代表的含义,看着简短好记是主要诉求。

3)三级域名(3LD):

三级域名是在二级域名之下的一级域名。它通常用于指向特定的服务器或子网。例如,在blog.example.com中,blog就是三级域名。www是最常见的三级域名,用于代表网站的主页或主站点,不过这只是某种流行习惯,目前很多网站都推荐直接使用二级域名访问了。

域名级别还可以进一步细分,大家可以看看企业微信开放平台这个域名:developer.work.weixin.qq.com,com代表商业,qq代表腾讯,weixin代表微信,work代表企业微信,developer代表开发者。这种逐层递进的方式有利于域名的分配管理。

按照上边的等级定义,我们可以说localhost是一个顶级域名,只不过它是保留的顶级域,其唯一目的是用于访问当前计算机。

7、多网站共用一个IP和端口

上边我们说不同的网络程序不能使用相同的端口,其实是有办法突破的。

以前个人博客比较火的时候,大家都喜欢买个虚拟主机,然后部署个开源的博客程序,抒发一下自己的感情。为了挣钱,虚拟主机的服务商会在一台计算机上分配N多个虚拟主机,大家使用各自的域名和默认的80端口进行访问,也都相安无事。这是怎么做到的呢?

如果你有使用Nginx、Apache或者IIS等Web服务器的相关经验,你可能会接触到主机头这个概念。主机头其实就是一个域名,通过设置主机头,我们的程序就可以共用1个网络端口。

首先在Nginx等Web程序中部署网站时,我们会进行一些配置,此时在主机头中写入网站要使用的域名。

然后Nginx等Web服务器启动的时候,会把80端口占为己有。

然后当某个网站的请求到达Nginx的80端口时,它会根据请求中携带的域名找到配置了对应主机头的网络程序。

然后再转发到这个网络程序,如果网络程序还没有启动,Nginx会把它拉起来。

8、私有IP地址

除了127.0.0.1,其实还有很多私有IP地址,比如常见的 192.168.x.x。

这些私有IP地址大部分都是为了在局域网内使用而预留的,因为给每台计算机都分配一个独立的IP不太够用,所以只要局域网内不冲突,大家就可劲的用吧。你公司可以用 192.168.1.1,我公司也可以用192.168.1.1。

但是如果你要访问我,就得通过公网IP进行转发。

大家常用的IPv4私有IP地址段分为三类:

  • 1)A类:从10.0.0.0至10.255.255.255;
  • 2)B类:从172.16.0.0至172.31.255.255;
  • 3)C类:从192.168.0.0至192.168.255.255。

这些私有IP地址仅供局域网内部使用,不能在公网上使用。

除了上述三个私有的IPv4地址段外,还有一些保留的IPv4地址段:

1)用于本地回环测试的127.0.0.0至127.255.255.255地址段,其中就包括题目中的127.0.0.1,如果你喜欢也可以给自己分配一个127.0.0.2的IP地址,效果和127.0.0.1一样。

2)用于局域网内部的169.254.0.0至169.254.255.255地址段,这个很少接触到,如果你的电脑连局域网都上不去,可能会看到这个IP地址,它是临时分配的一个局域网地址。

这些地址段也都不能在公网上使用。

近年来,还有一个现象,就是你家里或者公司里上网时,光猫或者路由器对外的IPv4地址也不是公网IP了,这时候获得的可能是一个类似 100.64.x.x 的地址,这是因为随着宽带的普及,运营商手里的公网IP也不够了,所以运营商又加了一层局域网,而100.64.0.0 这个网段是专门分给运营商做局域网用的。

如果你使用阿里云等公有云,一些云产品的IP地址也可能是这个,这是为了将客户的私有网段和公有云厂商的私有网段进行有效的区分。

其实还有一些不常见的专用IPv4地址段,完整的IP地址段定义可以看这里:www.iana.org/assignments

9、IPv6  

你可能也听说过IPv6,因为IPv4可分配的地址太少了,不够用,使用IPv6甚至可以为地球上的每一粒沙子分配一个IP。只是喊了很多年,大家还是喜欢用IPv4,这里边原因很多,这里就不多谈了。

IPv6地址类似于:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX。

它是128位的,用":"分成8段,每个X是一个16进制数(取值范围:0-F),IPv6地址空间相对于IPv4地址有了极大的扩充。比如:2001:0db8:3c4d:0015:0000:0000:1a2f:1a2b 就是一个有效的IPv6地址。(请详读《什么是IPv6?漫画式图文,一篇即懂!》)

10、参考资料  

[1] 你真的了解127.0.0.1和0.0.0.0的区别?

[2] 深入操作系统,彻底搞懂127.0.0.1本机网络通信

[3] 什么是IPv6?漫画式图文,一篇即懂!

[4] 一文读懂什么是IPv6

[5] IPv6技术详解:基本概念、应用现状、技术实践(上篇)

[6] 什么是公网IP和内网IP?NAT转换又是什么鬼?

[7] 深入操作系统,一文搞懂Socket到底是什么

[8] 面视必备,史上最通俗计算机网络分层详解

[9] 通俗讲解,有了IP地址,为何还要用MAC地址?

[10] 理论联系实际,全方位深入理解DNS


(本文已同步发布于:http://www.52im.net/thread-4702-1-1.html

posted @ 2024-09-26 10:23 Jack Jiang 阅读(87) | 评论 (0)编辑 收藏

     摘要: 1、前言微信——腾讯战略级产品,创造移动互联网增速记录,10个月5000万手机用户,433天之内完成用户数从零到一亿的增长过程,千万级用户同时在线,摇一摇每天次数过亿...在技术架构上,微信是如何做到的?日前,在腾讯大讲堂在中山大学校园宣讲活动上,腾讯广研助理总经理、微信技术总监周颢在两小时的演讲中揭开了微信背后的秘密。周颢把微信的成功归结于腾讯式的“三位一体&...  阅读全文

posted @ 2024-09-25 11:17 Jack Jiang 阅读(151) | 评论 (0)编辑 收藏

► 相关链接:

一、技术准备

您是否已对Web端即时通讯技术有所了解?

您需要对WebSocket技术有所了解:

WebSocket标准文档、API手册:

二、开发工具准备

1)WebStorm:

(JackJiang 使用的版本号如上图所示,建议你也使用此版或较新版本)

2)一站式下载地址:WebStorm官方下载地址点此进入

三、工程文件用途说明

3.1文件概览

纯原生JS实现,无任何重框架依赖:

MobileIMSDK-H5端SDK本身只是JS文件源码的集合,本工程中自带的前端Demo的目的只是为了方便随时测试MobileIMSDK-H5端的SDK代码而已,在此工程中的使用也仅仅只涉及了一个主Demo页面而已。

工程目录说明:

3.2详细说明

SDK 各模块/文件作用说明:

四、主要 API 接口

4.1主要 API 接口概览

如下图所示:所有 SDK 接口均由/mobileimsdk/mobileimsdk-client-sdk.js 提供。,接口设计跟MobileIMSDK 的APP版一样,均为高内聚和低侵入的回调方式传入SDK处理逻辑,无需(也不建议)开发者直接修改sdk级代码。

▲ 图上为浏览器端SDK的对外接口文件位置

▲ 图上为浏览器SDK为开发者提供的回调接口

▲ 图上浏览器端SDK的对外接口文件全图

4.2主要 API 接口用途说明

1)IMSDK.isLogined():

  • 用途:是否已经完成过首次登陆。
  • 说明 :用户一旦从自已的应用中完成登陆IM服务器后,本方法就会一直返回true(直到退出登陆IM)。
  • 返回值:{boolean},true表示已完成首次成功登陆(即已经成功登陆过IM服务端了,后面掉线时不影响此标识),否则表示尚未连接IM服务器。

2)IMSDK.isOnline():

  • 用途:是否在线。
  • 说明 :表示网络连接是否正常。
  • 返回值:{boolean},true表示网络连接正常,否则表示已掉线,本字段只在this._logined=true时有意义(如果都没有登陆到IM服务器,怎么存在在线或掉线的概念呢)。

3)IMSDK.getLoginInfo():

  • 用途:返回登陆时提交的登陆信息(用户名、密码/token等)。
  • 说明 :格式形如:{loginUserId:'',loginToken:''},此返回值的内容由调用登陆函数 loginImpl()时传入的内容决定。字段定义详见:PLoginInfo
  • 返回值:{boolean},true表示网络连接正常,否则表示已掉线,本字段只在this._logined=true时有意义(如果都没有登陆到IM服务器,怎么存在在线或掉线的概念呢)。

4)IMSDK.sendData(p, fnSucess, fnFail, fnComplete):

  • 用途:向某人发送一条消息。
  • 参数p:{Protocal} 要发送的消息协议包对象,Protocal详情请见“/module/mb_constants.js”下的createCommonData函数说明。
  • 返回值:{int} 0表示成功,否则表示错误码,错码详见“/module/mb_constants.js”下的MBErrorCode对象属性说明。

5)IMSDK.disconnectSocket():

  • 用途:客户端主动断开客户端socket连接。
  • 说明 :当开发者登陆IM后,需要退出登陆时,调用本函数就对了,本函数相当于登陆函数 loginImpl()的逆操作。

6)IMSDK.setDebugCoreEnable(enable):

  • 用途:是否开启MobileIMSDK-H5端核心算法层的log输入,方便开发者调试。
  • 参数enable :{boolean} true表示开启log输出,否则不输出,开发者不调用本函数的话系统默认是false(即不输出log)。

7)IMSDK.setDebugSDKEnable(enable):

  • 用途:是否开启MobileIMSDK-H5端框架层的log输入,方便开发者调试。
  • 参数enable :{boolean} true表示开启log输出,否则不输出,开发者不调用本函数的话系统默认是false(即不输出log)。

8)IMSDK.setDebugPingPongEnable(enable):

  • 用途:是否开启MobileIMSDK-H5端框架层的底层网络WebSocket心跳包的log输出,方便开发者调试。
  • 参数enable :{boolean} true表示开启log输出,否则不输出,开发者不调用本函数的话系统默认是false(即不输出log)。
  • 注意:必须 setDebugEnable(true) 且 setDebugPingPongEnable(true) 时,心跳log才会真正输出,方便控制。
  • 返回值:true表示开启log输出,否则不输出,开发者不调用本函数的话系统默认是false(即不输出log)。

9)IMSDK.loginImpl(varloginInfo, wsUrl):

  • 用途:登陆/连接MobileIMSDK服务器时调用的方法。
  • 说明 :登陆/连接MobileIMSDK服务器由本函数发起
  • 参数varloginInfo:{PLoginInfo} 必填项,登陆要提交给Websocket服务器的认证信息,不可为空,对象字段定义见:PLoginInfo
  • 参数wsUrl:{string} 必填项:要连接的Websocket服务器地址,不可为空,形如:wss://yousite.net:3000/websocket。

10)IMSDK.callback_onIMLog(message, toConsole):

  • 用途:由开发者设置的回调方法:用于debug的log输出。
  • 推荐用法 :开发者可在此回调中按照自已的意图打印MobileIMSDK微信小程序端框架中的log,方便调试时使用。
  • 参数1: {String}:必填项,字符串类型,表示log内容。
  • 参数2: {boolean}:选填项,true表示输出到console,否则默认方式(由开发者设置的回调决定)。

11)IMSDK.callback_onIMData(p, options):

  • 用途:由开发者设置的回调方法:用于收到聊天消息时在UI上展现出来(事件通知于收到IM消息时)。
  • 推荐用法:开发者可在此回调中处理收到的各种IM消息。
  • 参数1: {Protocal}:详情请见“/module/mb_constants.js”下的Protocal类定义)。

12)IMSDK.callback_onIMAfterLoginSucess():

  • 用途:由开发者设置的回调方法:客户端的登陆请求被服务端成功认证完成后的回调(事件通知于 登陆/认证 成功后)。
  • 推荐用法 :开发者可在此回调中进行登陆IM服务器成功后的处理。

13)IMSDK.callback_onIMAfterLoginFailed(isReconnect):

  • 用途:由开发者设置的回调方法:客户端的登陆请求被服务端认证失败后的回调(事件通知于 登陆/认证 失败后)。
  • 说明 :登陆/认证失败的原因可能是用户名、密码等不正确等,但具体逻辑由服务端的 callBack_checkAuthToken回调函数去处理。
  • 推荐用法:开发者可在此回调中提示用户登陆IM服务器失败。。
  • 参数1: {boolean}:true表示是掉线重连后的认证失败(在登陆其间可能用户的密码信息等发生了变更),否则表示首次登陆时的认证失败。

14)IMSDK.callback_onIMReconnectSucess():

  • 用途:由开发者设置的回调方法:掉线重连成功后的回调(事件通知于掉线重连成功后)。
  • 推荐用法 :开发者可在此回调中处理掉线重连成功后的界面状态更新等,比如设置将界面上的“离线”文字更新成“在线”。

15)IMSDK.callback_onIMDisconnected():

  • 用途:由开发者设置的回调方法:网络连接已断开时的回调(事件通知于与服务器的网络断开后)。
  • 推荐用法 :开发者可在此回调中处理掉线时的界面状态更新等,比如设置将界面上的“在线”文字更新成“离线”。

16)IMSDK.callback_onIMPing():

  • 用途:由开发者设置的回调方法:本地发出心跳包后的回调通知(本回调并非MobileIMSDK-H5端核心逻辑,开发者可以不需要实现!)。
  • 推荐用法 :开发者可在此回调中处理底层网络的活动情况。

17)IMSDK.callback_onIMPong():

  • 用途:由开发者设置的回调方法:收到服务端的心跳包反馈的回调通知(本回调并非MobileIMSDK-H5端核心逻辑,开发者可以不需要实现!)。
  • 推荐用法 :开发者可在此回调中处理底层网络的活动情况。

18)IMSDK.callback_onIMShowAlert(alertContent):

  • 用途:由开发者设置的回调方法:框架层的一些提示信息显示回调(本回调并非MobileIMSDK-H5端核心逻辑,开发者可以不需要实现!)。
  • 说明 :开发者不设置的情况下,框架默认将调用wx.showModal()显示提示信息,否则将使用开发者设置的回调——目的主要是给开发者自定义这种信息的UI显示,提升UI体验,别无它用】。
  • 参数1:{String}:必填项,文本类型,表示提示内容。

19)IMSDK.callback_onIMKickout(kickoutInfo):

  • 用途:由开发者设置的回调方法:收到服务端的“踢出”指令(本回调并非MobileIMSDK-H5端核心逻辑,开发者可以不需要实现!)。
  • 参数1 :{PKickoutInfo}:非空,详见:PKickoutInfo

20)IMSDK.callback_onMessagesLost(lostMessages):

  • 用途:由开发者设置的回调方法:消息未送达的回调事件通知。
  • 发生场景 :比如用户刚发完消息但网络已经断掉了的情况下,表现形式如:就像手机qq或微信一样消息气泡边上会出现红色图标以示没有发送成功)。
  • 建议用途:应用层可通过回调中的指纹特征码找到原消息并可以UI上将其标记为“发送失败”以便即时告之用户。
  • 参数1:{Array}:由框架的QoS算法判定出来的未送达消息列表。

21)IMSDK.callback_onMessagesBeReceived(theFingerPrint):

  • 用途:由开发者设置的回调方法:消息已被对方收到的回调事件通知。
  • 说明 :目前,判定消息被对方收到是有两种可能:1) 对方确实是在线并且实时收到了;2) 对方不在线或者服务端转发过程中出错了,由服务端进行离线存储成功后的反馈(此种情况严格来讲不能算是“已被收到”,但对于应用层来说,离线存储了的消息原则上就是已送达了的消息:因为用户下次登陆时肯定能通过HTTP协议取到)。
  • 建议用途:应用层可通过回调中的指纹特征码找到原消息并可以UI上将其标记为“发送成功”以便即时告之用户。
  • 参数1:{String}:已被收到的消息的指纹特征码(唯一ID),应用层可据此ID找到原先已发的消息并可在UI是将其标记为”已送达“或”已读“以便提升用户体验。

五、前端开发指南

5.1如何引入SDK文件到您的前端工程中?

很简单:只需要将第2节中提到的SDK所有JS文件复制到您的Uniapp工程下即可。

SDK内容见下图:

5.2如何在代码中调用SDK?

第一步:在你的网页中引用SDK的js文件(具体例子详见Demo中的index.html文件)

第二步:直接在你的JS文件中编写回调配置代码(具体例子详见Demo中的index.js文件)

第三步:在你的JS文件中调用IM的登陆方法即可(具体例子详见Demo中的index.js文件)

注意:上图中登录连接的IP地址请设置为您的MobileIMSDK服务器地址哦。

六、Demo运行方法(在WebStorm中直接预览)

6.1重要说明

特别说明:MobileIMSDK的H5端(包括Demo在内),全部是静态的HTML+JS资源,可以通过WebStorm自带的HTML页面预览功能,直接自动加载到电脑的浏览器中运行和预览。

6.2预览方法

1)在Demo中的index.html文件中,移动鼠标,会在右上角出现如下图所示的浮出菜单:

2)点击右上角浮出菜单上相应的浏览器就可以自动预览了这里以我电脑上已安装的Edge浏览器为例):

七、Demo运行方法(在Web服务器中部署并访问)

7.1重要说明

特别说明:MobileIMSDK的H5端(包括Demo在内),全部是静态的HTML+JS资源,对于服务端是没有任何依赖的,只需要保证浏览器端能加载到即可,可以把它们放置在Tomcat、Apache、IIS、Nginx等等传统Web服务器中即可,无需任何动态运行环境。

7.2安装Tomcat

提示:以下Demo的部署,以Java程序员最常用和Tomcat为例(Apache、IIS、Nginx等依此类推)。

Tomcat的安装就没什么好说的,直接官网下载对应的版本即可:https://tomcat.apache.org/download-90.cgi

7.3配置要连接的MobileIMSDK服务器IP

注意:下图中登陆连接的IP地址请设置为您的MobileIMSDK服务器地址哦。

友情提示: MobileIMSDK的服务端该怎么部署就不是本手册要讨论的内容了,你可以参见《即时通讯框架MobileIMSDK的Demo使用帮助:Server端》。

▲ 配置要连接的服务器IP(以上代码详见demo/index.js 文件)

7.4部署Demo

说“部署”有点扯蛋,因为Demo(包括SDK)在内,全是HTML静态内容,只需要直接复制到任何一种Web服务器即可。

以下是复制到Tomcat服务器网页目录后的截图:

7.5启动Tomcat

提示:本手册中仅以启Tomcat为例,Apache、IIS、Nginx等Web服务器的启动请自动百度。

运行startup.bat启动Tomcat:

7.6Demo的运行效果预览

八、Demo功能预览和说明

九、Demo运行效果实拍图

1)Demo在手机端浏览器中的真机实拍图:

2)Demo在电脑端浏览器中的真机实拍图:

十、更多Demo运行效果截图

1)Demo在PC端浏览器运行效果:

2)Demo在手机端浏览器运行效果:

3)Demo在PC端各主流浏览器的运行效果:

十一、常见问题(FAQ)

11.1为什么浏览控制台下有些log不显示?

原因是浏览器控制台下的日志级别默认进行了过滤,勾选所有日志级别,就能看到SDK的详细日志输出了。

勾选所有的日志输出级别:

然后就能看到SDK中详细的日志输出了(就像下图这样),方便调试和研究:

十二、引用资料

[1] WebSocket 标准API手册

[2] MobileIMSDK开源框架的API文档

[3] MobileIMSDK开源IM框架源码Github地址点此

[4] MobileIMSDK-H5端基本介绍

[5] MobileIMSDK-H5端的开发手册(* 精编PDF版)

[6] MobileIMSDK的Demo使用帮助:Server端

[7] WebSocket从入门到精通,半小时就够!

posted @ 2024-09-19 13:14 Jack Jiang 阅读(70) | 评论 (0)编辑 收藏

一、基本介绍

MobileIMSDK的H5端是一套纯JS编写的基于标准WebSocket的即时通讯库:
  • 1)超轻量级、极少依赖;
  • 2)纯JS编写、高度提炼,简单易用;
  • 3)基于标准WebSocket协议,客户端兼容性好;
  • 4)支持运行于iOS、Android等移动端浏览器和各种PC端浏览器;
  • 5)能与 MobileIMSDKGithub托管链接)的各种APP原生代码客户端完美互通;
  • 6)可应用于手机端/PC端的网页聊天应用、企业OA、Web端等即时通讯场景。

二、与MobileIMSDK的关系

MobileIMSDK-H5端 是基于标准HTML5的WebSocket协议的 MobileIMSDK配套客户端库。

以下是MobileIMSDK的通信架构图:

MobileIMSDK是一套专为移动端开发的原创开源IM通信层框架:

  • 1)历经8年、久经考验;
  • 2)超轻量级、高度提炼,lib包50KB以内;
  • 3)精心封装,一套API同时支持UDP、TCP、WebSocket三种协议(可能是全网唯一开源的);
  • 4)客户端支持iOS、Android、标准Java、H5(暂未开源)、微信小程序(暂未开源)、Uniapp:new:(暂未开源);
  • 5)服务端基于Netty,性能卓越、易于扩展;
  • 6)可与姊妹工程 MobileIMSDK-Web 无缝互通实现网页端聊天或推送等;
  • 7)可应用于跨设备、跨网络的聊天APP、企业OA、消息推送等各种场景。

PS: MobileIMSDK一直在持续开发和升级中,新Uniapp端是MobileIMSDK工程的最新成果。

三、与MobileIMSDK-Web的关系

MobileIMSDK-Web也是一套纯JS编写的Web端即时通讯框架(含服务端)。

MobileIMSDK-Web框架与MobileIMSDK-H5端的相同点:
  • 1)都是Web端即时通讯框架;
  • 2)都是纯JS编写;
  • 3)都可以运行在手机、pc端的浏览器或web容器内。
MobileIMSDK-Web框架与MobileIMSDK-H5端的不同点:
  • 1)MobileIMSDK-Web可以兼容不支持HTML5的旧版浏览器或容器,而MobileIMSDK-H5端必须运行在当前主流的HTML5浏览器或容器;
  • 2)MobileIMSDK-Web需依赖于socket.io这种第3方通信层库,而MobileIMSDK-H5端无任何额外依赖。
我该如何选型?
  • 选择一:如果您的应用必须兼容旧版浏览器(包括旧版IE等)
    那唯一的选择就是MobileIMSDK-Web,因为它存在的主要价值就是为了兼容旧版浏览器;
  • 选择二:如果您的应用只需运行在现今主流的HTML5浏览器或容器
    那么建议您优先使用MobileIMSDK的H5端,必竟直接调用标准HTML5的WebSocket API,要简洁、轻量多了,也没有第3方依赖。

四、设计目标

直接使用原生的WebSocket有以下问题和劣势:
  • 1)功能有限:没有提供心跳保活、断线重连、送达保证(重传和去重)等即时通讯关键算法和逻辑;
  • 2)API 简陋:在如此有限的标准API下,能逻辑清晰和健壮地实现并组合心跳保活、断线重连、送达保证等算法,需要相当高的技术掌控力
  • 3)逻辑耦合:经验欠缺的开发人员,会将WebSocket通信代码与前端UI界面代码混在一起,使得UI界面的编写、维护、改版都非常困难。
针对以上问题,而MobileIMSDK-H5端库将让开发者专注于UI应用层的开发,网络通信层的专业代码交由SDK开发人员,从而解偶UI前端和通信层的逻辑耦合性,大大降低技术复杂性。

总结一下,MobileIMSDK-H5端库的设计目标是为您的Web端IM带来以下便利:
  • 1)前端与通信解偶:前端UI与网络通信代码解耦,UI界面的重构、维护、改版都非常容易和优雅;
  • 2)轻量级和兼容性:受益于标准WebSocket,可很好地运行于现今主流的H5浏览器上,且无需额外依赖;
  • 3)核心内聚和收敛:得益于长期的提炼和经验积累,SDK核心层高度封装,开发者无需理解复杂算法即可简单上手。
  • 4)纯JS轻量级实现:纯JS编写,无Angular、EmberJS、VUE等各种重量级前端框架依赖,方便对接各种既有系统;

五、技术亮点

  • 1)轻量易使用:超轻量级——纯JS编写且极少依赖,高度提炼——简单易用;
  • 2)兼容性很好:基于标准WebSocket,可很好地运行于现今主流的H5浏览器上,且无需额外依赖;
  • 3)断网恢复能力:拥有网络状况自动检测、断网自动治愈的能力;
  • 4)送达保证机制:完善的QoS消息送达保证机制(自动重传、消息去重、状态反馈等),不漏过每一条消息;
  • 5)支持多种设备:支持运行于iOS、Android等移动端浏览器和各种PC端浏览器;
  • 6)通信协议封装:实现了一个对上层透明的即时通讯通信协议模型;
  • 7)身份认证机制:实现了简单合理的身份认证机制;
  • 8)完善的log信息:在开发调试阶段,确保每一个算法关键步骤都有日志输出,让您的运行调试更为便利;
  • 9)前端代码解耦:实现了UI前端代码与sdk网络通信代码解偶,防止前端代码跟IM核心代码混在一起,不利于持续升级、重用和维护;
  • 10)多端协议兼容:实现了与MobileIMSDK各APP端完全兼容的协议模型;

六、文件组成

SDK代码文件概览:

SDK代码文件用途说明:

七、Demo功能预览和说明

八、Demo运行效果实拍图

1)Demo在手机端浏览器中的真机实拍图:

2)Demo在电脑端浏览器中的真机实拍图:

八、更多Demo运行效果截图

1)Demo在PC端浏览器运行效果:

 

2)Demo在手机端浏览器运行效果(点击可看大图 ▼):

3)Demo在PC端主流浏览器的运行效果(点击可看大图 ▼):

十、详尽开发者手册

① MobileIMSDK-H5端的详细介绍:点此查看 👈
② MobileIMSDK-H5端的开发手册(网页版):点此查看 👈
 MobileIMSDK-H5端的开发手册(精编PDF版):点此查看 👈 (* 推荐
④ MobileIMSDK-开源框架的详细介绍:https://gitee.com/jackjiang/MobileIMSDK (Github托管链接)👈

十一、相关资料

[1] HTML5 WebSocket API 文档
[2] MobileIMSDK开源框架的API文档
[3] MobileIMSDK开源IM框架源码Github地址点此
[4] MobileIMSDK-Web框架基础介绍

posted @ 2024-09-18 10:36 Jack Jiang 阅读(71) | 评论 (0)编辑 收藏

     摘要: 本文由得物技术厉飞雨、GavinX分享,原题“得物App白屏优化系列|网络篇”,下文进行了排版和内容优化。1、引言图片加载作为重中之重的App体验指标,端侧的白屏问题则是其中最为严重、也是最为常见的问题之一。想象一下如果你在浏览交易商品、社区帖子等核心场景下,图片无法完成加载是多么糟糕的体验。如上图所示,通过线上白屏问题归因,我们看到网络问题导致比例最高,占比达81.97%...  阅读全文

posted @ 2024-09-12 11:02 Jack Jiang 阅读(82) | 评论 (0)编辑 收藏

     摘要: 【来源申明】本文引用了微信公众号“鲜枣课堂”的《老司机揭秘手机定位技术,这下彻底明白啦!》文章内容。为了更好的内容呈现,下文在引用和收录时内容有改动,转载时请注明原文来源信息,尊重原作者的劳动。1、系列文章引言1.1适合谁来阅读?本系列文章尽量使用最浅显易懂的文字、图片来组织内容,力求通信技术零基础的人群也能看懂。但个人建议,至少稍微了解过网络通信方面的知识后再看,会更有收...  阅读全文

posted @ 2024-09-11 12:07 Jack Jiang 阅读(90) | 评论 (0)编辑 收藏

     摘要: 【来源申明】本文引用了微信公众号“鲜枣课堂”的《坐高铁手机没信号?原因远比你想的要复杂!》文章内容。为了更好的内容呈现,本文在引用和收录时内容有改动,转载时请注明原文来源信息,尊重原作者的劳动。1、系列文章引言1.1适合谁来阅读?本系列文章尽量使用最浅显易懂的文字、图片来组织内容,力求通信技术零基础的人群也能看懂。但个人建议,至少稍微了解过网络通信方面的知识后再看,会更有收...  阅读全文

posted @ 2024-09-06 12:02 Jack Jiang 阅读(87) | 评论 (0)编辑 收藏

本文由携程技术Jim分享,原题“日访问过亿,办公IM及开放式平台在携程的实践”,下文进行了排版和内容优化。

1、引言

携程内部的办公IM项目最早在2016年立项,经历了初期简单办公场景下的纯IM服务,到支持简单办公组件的IM应用,又演变为一体化办公集成平台,进而演变为目前集成IM功能的开放式企业效率平台。

本文总结了携程办公IM这些年的发展历程及未来的演进方向,并着重从高可用、高性能和可扩展的角度,探讨开放式平台的技术实现及发展方向。

 
 

2、关于作者

Jim:携程高级研发经理,关注Java & Go技术栈后端研发。目前致力于TripPal开放平台的高可用、开放化进程及核心衍生服务。

3、什么是IM

IM(Instant Message)即时消息,是一种通过网络提供实时消息传输的在线沟通技术。

在移动互联网时代,IM的使用变得越来越广泛,通过各种技术手段使得用户之间的交流成本变的极低,沟通效率和用户体验有极大的提升。而且IM的出现极大地改变了目前互联网应用的形态,多数互联网应用只要做到了一定规模,一定会有自身IM的需求,而不是单纯地仅仅依托第三方(例如微信、云信等)。

PS:关于什么是IM,您也可详读专题文章《零基础IM开发入门(一):什么是IM系统?》。

4、 携程办公IM的发展历程

早期携程使用微软的IM软件lync和自研的纯IM软件CtripTeam来支持企业内的沟通需求,这些软件在维护性、拓展性和可用性上都或多或少存在一些缺陷。同时随着互联网的发展,也逐渐不适合日益增长的办公需求和用户体验。

2017年左右,使用基于ejabberd+erlang的自研IM服务的Cchat项目应运而生,该项目的主要目标是在采用自研IM的基础上,实现IM与办公的结合。在完善IM服务的基础上,支持了一些常规的办公场景,如电话、假单、考勤、OA等,通常采用嵌入外部页面、跳转外部地址等方式提供服务。这个改造项目奠定了携程办公IM继续发展的基础。

随着项目的深入,最初的系统交互模式及服务管理模式逐渐不适用越来越复杂的办公场景及服务治理需求。于是在2019年上马了TripPal的改造项目,在结合公司国际化战略的基础上,倾力打造小程序平台,服务号等基础服务。在梳理、优化原有服务的同时,打造了诸多衍生服务。

2020年中开始,在继续推进企业内办公一站式平台的基础上,我们需要支持更多的外部场景,实际需求促使我们向开放式平台转型,这在服务整体架构、安全性、扩展性等方面都提出了新的要求及挑战。

5、携程TripPal开放平台总体架构

5.1Gateway网关层

这一层是所有请求调用流量的入口,主要功能如下:

  • 1)服务路由;
  • 2)集中式限流、风控、日志监控等功能;
  • 3)调用IDS (Identity Service) 验证请求的合法性。

第 3)步中验证通过后,可以将用户ID、Token等基本信息,通过 HttpHeader 的方式向后端服务透传,后端服务可以直接使用UserID,也可以再次对Token进行认证

5.2IDS (Identity Service) 服务

IDS同时支持多种不同类型的访问令牌的鉴权,同时还负责令牌的颁发,以及RBAC+模块级别的接口控权。

另外,针对开放小程序,TripPal提供两种认证方式:

1)常规的Oauth第三方模式接入:

2)另一种是基于Oauth+开放平台签名的第三方认证,对于接入方相对简单:

5.3微服务层

这一层是整个系统的业务层,具体包含三种类型的微服务:

  • 1)TripPal开放平台内部系统微服务:只有在特定用户认证和权限验证通过之后,外部才能访问;
  • 2)开放平台对外提供的OpenAPI:采用Oauth+RBAC的方式控制权限;
  • 3)自研小程序后端服务:根据安全需要,所有使用Oauth+模块权限的第一方小程序服务端。

目前TripPal自身的核心微服务应用达到28个,提供全集团的多端(C端、B端)基础服务能力,服务全公司超过500个业务应用,在线C端用户均值超过2万,日访问量超过亿。

6、 TripPal的IM服务

目前TripPal使用完全自研的基于Java实现的类ejabberd架构,底层采用的XMPP协议进行通讯。

Tips:

XMPP全称是ExtensibleMessageing and Presence Protocol,可扩展消息与存在协议。是目前网络上开源,最灵活,应用最广泛的一种即时消息通信协议。

1999年Jeremie Miller,首先提出了Jabber,一种为实现即时消息和存在的开放技术,后续基于这个协议,开发了一个开源的服务实现jabberd。后续,IETF国际标准组织介入,成立Extensible Messageing and Presence Protocol(XMPP)工作组,并开始标准化工作。

2000年,jabberd服务器1.0版本发布,那时Jabber协议的基本特点(基于XML的流,消息,存在,联系人列表等)都被固定下来。

2004年,IETF出版了RFC 3902和RFC3921,定义了XMPP的核心功能,成为推荐标准。

后续在2011年,IETF出版了RFC6120和RFC 6121,更新了XMPP的核心定义,替代了之前的RFC 3920和3921。

目前XMPP协议被XMPP Standards Foundation负责管理运作,集中于在IETF定义的基础XMPP规范之上,如何开发开放的协议扩展。

IM服务端做了大量的系统性的优化,从底层的数据库调优、底层通讯服务升级,到上层消息、群、群成员等核心功能的大幅改造。

底层通讯服务由之前的erlang完整迁移至java技术栈,服务可靠性、弹性伸缩、安全性和性能获得了提升。同时对上层偏业务的服务进行了改造,极大地提升了接口响应,服务稳定性也得到了提升,为整个产品的研发提供了重要支撑。

目前这套自研的IM 3.0服务在生产环境稳定运行,整体资源消耗比2.0时期有较大下降。

7、 TripPal办公衍生服务

7.1概述

在实际的企业办公场景下,尤其是大型企业复杂组织架构和管理模式的场景下,TripPal逐渐摸索出了自己的一套行之有效且契合携程场景的办公智能应用,如搜索中台,消息卡片,智能审批中台,角色服务,工作流引擎等。

本文简单介绍其中3个服务。

7.2智能审批中台

智能审批中台在集成携程自有的审批系统的同时也集成了自研的智能审批配置服务,该服务支持用户自定义整个审批单及审批流的全部细节。

 

7.3角色服务

角色服务在灵活定义角色范围及基础角色的基础上,支持用户灵活调整,动态管理,且自动接入审批中台,同时打通应用对接渠道。

整个角色服务在产品定义上分为如下表4个主要概念:

7.4在线文档

在线文档服务主要提供文档的在线协作能力,支持用户同时/实时的查看、编辑、保存和分享的能力。同时结合IM实现通知和反馈等功能。

技术实现上,在线文档是采用CRDT算法实现的无冲突merge(LastWrite Wins)、多端最终一致的分布式方案,同时兼具高可用、可容错的特性,在服务器发生故障时,允许Shift至另一台机器上继续执行,即使服务端完全宕机,客户端依然能够离线工作。

8、 TripPal高可用的实践

目前TripPal部署在3个机房,分为公有云1个机房及私有云2个机房。

总体架构在应用多机房部署、数据层跨机房DRC的基础上,采用就近访问的原则进行服务访问,其中一旦发生任意2个机房全挂的情况,都能保证系统内的核心应用仍能提供服务。

其中公有云机房的一期部署方案已经完成,二期部署方案和测试计划预计于7月完成,届时可以和大家分享一下混合云方案的一些细节和历程。

9、 开放平台的未来架构及演进方向

9.1概述

开放平台主要面向两类群体,开发者和用户。

所以主要有两个方向:

1)一是便捷开发,主要围绕降低开发者门槛、较低研发成本,打通不同开发者、应用之间的壁垒,实现生态共享。

2)另一方面,针对实际用户,在提高用户体验、数据安全的同时,实现用户服务能力整合和主动发现。

9.2开发者

在这方面,目前主流开放平台已经对开发者提供了强大的支持。

主要形式分为以下3种。

1)前端信任:

前端信任的目的是通过减少或杜绝开发者后端跟开放平台OpenAPI交互的方式,来降低开发者接入门槛,减少工作量。主要的做法是通过权限控制、签名、加密等手段使得小程序能够在前端拿到可信数据。

2)低代码(Low-Code):

由于大量的互联网业务属于简单交互或模型化交互,以此为出发点,基于构建合理模型、简单业务函数等形式,可以允许开发者通过拖拽组件、简单伪业务代码等形式提供编程入口,可以大幅度降低开发者的研发门槛和成本,打破用户和开发者界线,提高开放平台整体生态的活力。

3)ServerLess:

基于云原生的ServerLess结合低代码,开放开发者的云端编程入口,同时提供云端基础组件,允许开发者无需部署实际的后端应用服务,极大降低的开发者的运营维护门槛。

9.3用户层面

目前业界主流开放平台在对用户本身的服务能力整合和挖掘上,投入的都比较少,也没有比较成熟的实践,我们认为在这方面可以围绕两个点展开。

一方面:第三方应用治理模式向商城化的转型。常规开放平台的应用治理和推广,基本是应用方独立管理和推广,但是随着应用数量的大幅度增加,以及应用方单方面推广难度较大等原因,亟需开放平台从生态整体角度进行支持和治理。这样可以在安全性、可维护性、便捷性等维度上对应用进行正向反馈,实现开放平台应用生态的可持续性和能力共享。同时,在特定场景下,结合用户分析、大数据及AI,提高用户主动或被动的应用发现能力。

另一方面:构建符合应用间开放协议的软件联盟,打破应用壁垒,围绕服务集成、开放应用的核心原则,使得不同的互联网业务或行为在一定程度上实现数据/能力共享。一般情况下,一个复杂互联网业务通常由多个异构子业务/子应用构成,这样,通过应用拆分、开放共享等形式,在一定程度上使复杂的互联网业务更加精细化、轻量化、可扩展。

9.4开放平台标准化、互通

目前国内外各大互联网公司、机构和组织都搭建了多种开放平台,用于提供各种各样的信息服务,在可以预见的未来,各个平台之间会有一个整合、标准化、互通的可能性。

那么构建标准开放协议,使得开放平台向底层沉淀的过程则至关重要。

10、 本文小结

通过实现基本IM开放平台架构,以及各种衍生服务,我们总结出了IM开放平台的一些核心能力。

主要是:

  • 1)服务集成:根据不同的业务场景集成并提供相应场景下的基础服务能力;
  • 2)开放应用:提供第三方接入能力;
  • 3)高性能、高可用。

11、参考资料

[1] 零基础IM开发入门(一):什么是IM系统?

[2] 从零到卓越:京东客服即时通讯系统的技术架构演进历程

[3] 瓜子IM智能客服系统的数据架构设计(整理自现场演讲,有配套PPT)

[4] 从游击队到正规军(一):马蜂窝旅游网的IM系统架构演进之路

[5] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[6] 浅谈IM系统的架构设计

[7] 简述移动端IM开发的那些坑:架构设计、通信协议和客户端

[8] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

[9] 一套原创分布式即时通讯(IM)系统理论架构方案

[10] 一套亿级用户的IM架构技术干货(上篇):整体架构、服务拆分等

[11] 从新手到专家:如何设计一套亿级消息量的分布式IM系统

[12] 企业微信的IM架构设计揭秘:消息模型、万人群、已读回执、消息撤回等

[13] 阿里IM技术分享(三):闲鱼亿级IM消息系统的架构演进之路

[14] 基于实践:一套百万消息量小规模IM系统技术要点总结

[15] 跟着源码学IM(十):基于Netty,搭建高性能IM集群(含技术思路+源码)

[16] 一套十万级TPS的IM综合消息系统的架构实践与思考

[17] 直播系统聊天技术(八):vivo直播系统中IM消息模块的架构实践

[18] 融云技术分享:全面揭秘亿级IM消息的可靠投递机制

[19] 得物从0到1自研客服IM系统的技术实践之路

[20] 一套分布式IM即时通讯系统的技术选型和架构设计

[21] 微信团队分享:来看看微信十年前的IM消息收发架构,你做到了吗


(本文已同步发布于:http://www.52im.net/thread-4690-1-1.html

posted @ 2024-08-29 15:45 Jack Jiang 阅读(83) | 评论 (0)编辑 收藏

     摘要: 【来源申明】本文引用了微信公众号“网优雇佣军”的《是谁偷走了我家的手机信号?》文章内容。为了更好的内容呈现,下文在引用和收录时内容有改动,转载时请注明原文来源信息,尊重原作者的劳动。1、系列文章引言1.1适合谁来阅读?本系列文章尽量使用最浅显易懂的文字、图片来组织内容,力求通信技术零基础的人群也能看懂。但个人建议,至少稍微了解过网络通信方面的知识后再看,会更有收获。如果您大...  阅读全文

posted @ 2024-08-21 17:53 Jack Jiang 阅读(92) | 评论 (0)编辑 收藏

     摘要: 本文由得物技术厉飞雨分享,原题“得物App弱网诊断探索之路”,下文进行了排版和内容优化。1、引言随着得物用户规模和业务复杂度不断提升,端上网络体验优化已逐步进入深水区。为了更好地保障处于弱网状态下得物App用户的使用体验,我们在已有的网络体验大盘、网络诊断工具的基础上研发了弱网诊断能力。该工具能够高效实时诊断用户真实网络环境,同时给出精确网络质量分级,为后续App各业务场景...  阅读全文

posted @ 2024-08-15 11:08 Jack Jiang 阅读(104) | 评论 (0)编辑 收藏

     摘要: 本文来自腾讯手Q基础架构团队杨萧玉、邱少雄、张自蹊、王褚重天、姚伟斌的分享,原题“QQ 客户端性能稳定性防劣化系统 Hodor 技术方案”,下文进行了排版和内容优化。1、引言接上篇《首次公开,最新手机QQ客户端架构的技术演进实践》。防劣化是比较经典的技术话题,手 Q 的防劣化系统从 2021 年 10 月开始投入研发,从 0 到 1 迭代了将近三年的时间,已经达到了业界先进...  阅读全文

posted @ 2024-08-02 10:38 Jack Jiang 阅读(64) | 评论 (0)编辑 收藏

Jack Jiang的 Mail: jb2011@163.com, 联系QQ: 413980957, 微信: hellojackjiang