默认
打赏 发表评论 36
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
从零开始搭建瓜子二手车IM系统(PPT) [附件下载]
微信扫一扫关注!

本次分享由即时通讯网征得封宇本人的同意后,重新整理发布,感谢封宇的无私分享。


1、内容概述


本次分享由瓜子二手车技术专家封宇分享于线下活动《滴滴技术沙龙第7期:高可用业务架构设计与平台化实践》。

经历高速成长,瓜子的员工数量已突破两万。人员规模的扩大,组织层级的加深,对内部管理形成诸多挑战。基于效率、安全等因素的考虑,瓜子决定自研消息系统用于支持内效工具“呱呱”的即时通讯功能。

瓜子IM系统的落地,解决了瓜子内部的沟通问题,并以单聊、群聊、公众号、红点提示等多种形态深入到员工工作的各个环节。随着应用的不断深化,瓜子IM系统逐渐演变为即时消息PaaS平台,支撑在线客服、车速拍等多条业务线的各类即时消息需求。

在本次分享中,封宇为大家一一讲解了他和他的团队是如何从零开发瓜子IM系统的。

另外:封宇分享于即时通讯网的《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》一文,受到了即时通讯网社区的一致好评,建议详读之。

2、人物简介


WechatIMG13.jpg
封宇:瓜子二手车技术专家,中国计算机学会专业会员。主要负责瓜子即时消息解决方案及相关系统研发工作。曾供职于58同城、华北计算技术研究所,参与到家消息系统、58爬虫系统以及多个国家级军工科研项目的架构及研发工作。

封宇分享的其它IM技术资料:


3、相关文章


浅谈IM系统的架构设计
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)
一套原创分布式即时通讯(IM)系统理论架构方案
从零到卓越:京东客服即时通讯系统的技术架构演进历程
蘑菇街即时通讯/IM服务器开发之架构选择
移动端IM中大规模群消息的推送如何保证效率、实时性?
现代IM系统中聊天消息的同步和存储方案探讨
腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面
IM消息送达保证机制实现(一):保证在线实时消息的可靠投递
IM消息送达保证机制实现(二):保证离线消息的可靠投递
如何保证IM实时消息的“时序性”与“一致性”?
一个低成本确保IM消息时序的方法探讨
IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?
IM群聊消息如此复杂,如何保证不丢不重?
谈谈移动端 IM 开发中登录请求的优化
移动端IM登录时拉取数据如何作到省流量?
浅谈移动端IM的多点登陆和消息漫游原理
完全自已开发的IM该如何设计“失败重试”机制?
通俗易懂:基于集群的移动端IM接入层负载均衡方案分享

4、演讲提纲


1)项目背景
2)问题抽象
3)系统设计
  • 核心结构图
  • session管理
  • 协议设计
  • 消息可靠传递
  • 消息投递流程
  • 拉取离线消息流程
  • 消息有序
  • 大规模群的优化
  • 高并发问题
  • 完整结构图
4)平台化演进
  • 多租户与业务隔离
  • 多终端
5)Q&A

5、讲稿截图


1.png

2.png

3.png

4.png

5.png

6.png

7.png

8.png

6、讲稿下载


从零开始搭建瓜子IM系统(滴滴技术沙龙第7期)(52im.net).pdf (1.73 MB , 下载次数: 195 , 售价: 3 金币)

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:美图海量用户的IM架构零基础演进之路(PPT) [附件下载]下一篇:极光分享:高并发海量消息推送系统架构演进(视频+PPT)[附件下载]

本帖已收录至以下技术专辑

推荐方案
评论 36
顶。。。PPT观摩中,,,,
引用:那只羊 发表于 2018-08-09 16:02
顶。。。PPT观摩中,,,,

封宇分享的东西,都是干货。遗憾的是,没有拿到这次分享录制的视频
干货,已收藏
签名: 不想上班,啦啦啦
引用:JackJiang 发表于 2018-08-09 16:35
封宇分享的东西,都是干货。遗憾的是,没有拿到这次分享录制的视频

跪求一下视频
签名: 抓狂扩扩扩扩扩扩扩扩扩扩扩扩扩扩
引用:o0oi1i 发表于 2018-08-10 15:42
跪求一下视频

我问过封宇,他说视频滴滴那边有录制,但没有公开出来,所以也搞不到
谢谢分享
很好!  谢谢分享!
学习学习
这个架构,可以优化成广域网分布式部署吗?
引用:ym_im 发表于 2018-11-29 10:49
这个架构,可以优化成广域网分布式部署吗?

别人哼哧哼哧的,不可能做的是一个局域网的应用啊
引用:JackJiang 发表于 2018-11-29 11:12
别人哼哧哼哧的,不可能做的是一个局域网的应用啊

1、接入层全国部署以后。每个接入层都会连接所有的逻辑层,因为要有全局session,每个接入会把所有的客户端状态报给所有的逻辑层。是不是很浪费啊?如果同时在线上百万的话。每个逻辑层都得维护上百万客户端的内存hash表啊。
引用:ym_im 发表于 2018-11-29 17:33
1、接入层全国部署以后。每个接入层都会连接所有的逻辑层,因为要有全局session,每个接入会把所有的客户 ...

在线上百万,总用户量过千万了,那肯定是另外一种架构了,没必要想成那样,国内能做到这样的公司,不需要我们在这里考虑,有更牛逼的人等着接手了。架构这东西够用就好,封宇的分享是基于瓜子2手车的im业务,规模没这么大
引用:JackJiang 发表于 2018-11-29 18:28
在线上百万,总用户量过千万了,那肯定是另外一种架构了,没必要想成那样,国内能做到这样的公司,不需要 ...

我现在开发的这套分布式的,用户一千二百万,并发最高40万。在考虑升级架构了。
引用:ym_im 发表于 2018-11-29 18:34
我现在开发的这套分布式的,用户一千二百万,并发最高40万。在考虑升级架构了。

你这im规模不小了。你打算怎么升级
引用:JackJiang 发表于 2018-11-29 18:36
你这im规模不小了。你打算怎么升级

现在架构是接入层全国部署,逻辑层集群部署在一起。之前机房故障,逻辑层挂掉了。现在主要是考虑去中心化了。
引用:ym_im 发表于 2018-11-29 17:33
1、接入层全国部署以后。每个接入层都会连接所有的逻辑层,因为要有全局session,每个接入会把所有的客户 ...

首先瓜子现在没有那么多同时在线用户。其次全局session是采用的redis集群存储,用的hash分库。逻辑层现在没有状态,客户端的hash路由表是从redis集群里查的。每个接入层会连接所有逻辑层,但是指会把客户端状态报给1个逻辑层。
这块的优化你有什么建议呢?
我有点疑问。

是所有的逻辑层都在本地配一个redis集群。所有客户端都是按照hash id分配到固定的逻辑服务器,但是可以连接任意接入服务器。客户端根据自己的ID被接入层上报到自己对应的逻辑层这个架构吗?

还是所有逻辑层连接一个redis集群。那样所有的逻辑层和redis集群就得在同一个局域网。这样中心化太严重了。这个机房断网,整个系统就不能用了。
引用:封宇_ynOMz 发表于 2018-11-30 11:52
首先瓜子现在没有那么多同时在线用户。其次全局session是采用的redis集群存储,用的hash分库。逻辑层现在 ...

我之前也是依赖redis比较多,但是还是比较影响性能的。最后再redis上面又增加一层内存hash,这样访问更快,递归查询。
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部