请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 50
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
楼主辛苦了
签名: 新手来看看
又学习了一波
学习一下,感谢楼主分享的资料
签名: 烦心事一大堆
引用:sunnyhui2010 发表于 2017-07-13 22:05
此方案中接入层和逻辑层是通过什么解耦的?mq还是rpc?

接入层和逻辑层是RPC框架。逻辑层内部通过Kafka解耦模块
引用:封宇_ynOMz 发表于 2017-11-23 14:31
接入层和逻辑层是RPC框架。逻辑层内部通过Kafka解耦模块

本文作者来了。。。
签名: 《微信支付代码重构带来的移动端软件架构上的思考》http://www.52im.net/thread-2958-1-1.html
引用:JackJiang 发表于 2017-11-23 14:57
本文作者来了。。。

现在经常逛这个论坛,学到很多东西。感谢站长
引用:封宇_ynOMz 发表于 2017-11-23 15:35
现在经常逛这个论坛,学到很多东西。感谢站长

给你加V了:
WX20171123-160507@2x.jpg

你开发的IM是你们瓜子二手车公司内部用的吗?有好的心得记得大家一起分享
签名: 《微信支付代码重构带来的移动端软件架构上的思考》http://www.52im.net/thread-2958-1-1.html
引用:JackJiang 发表于 2017-11-23 16:07
给你加V了:

内部用,线上用户和客服、销售沟通也用
请问拉离线消息时,如果离线期间消息特别多是怎么处理的?
引用:novo 发表于 2018-02-28 20:48
请问拉离线消息时,如果离线期间消息特别多是怎么处理的?

这两篇文章里讨论了你提到的问题,你参考一下:
移动端IM登录时拉取数据如何作到省流量?
IM消息送达保证机制实现(二):保证离线消息的可靠投递
签名: 《微信支付代码重构带来的移动端软件架构上的思考》http://www.52im.net/thread-2958-1-1.html
重复发生了,这条已经去掉
"ISO采用APNS,Android真后台保活"应该修改为"iOS采用APNS,Android真后台保活"
引用:TheBloodElf 发表于 2018-03-28 15:01
"ISO采用APNS,Android真后台保活"应该修改为"iOS采用APNS,Android真后台保活"

已改,感谢纠错!
签名: 《微信支付代码重构带来的移动端软件架构上的思考》http://www.52im.net/thread-2958-1-1.html
学习了
签名: 学习了
和我们的架构有点像,虽然并不完美,也无法支持太高的并发,但是能看出来确实是干活。我们的群聊是读扩散,写扩散用在实时的群聊中,我觉得在群成员数和群数比较多的时候,势必是灾难。
签名: 该会员没有填写今日想说内容.
引用:researchboy 发表于 2018-06-05 20:23
和我们的架构有点像,虽然并不完美,也无法支持太高的并发,但是能看出来确实是干活。我们的群聊是读扩散, ...

你回想一下QQ群是怎么慢慢从50人、200人、500人、1000人群这些做起来的了。
群聊其实并不是个很简单的问题,只是大厂经过N个版本迭代后,大家都理所当然的认为群聊理应是标配或白菜技术才对。
所以,一方面是技术优化到极致,另一方面也是软硬件基础设施堆起来的。这个事对谁来说都不容易,大厂也一样
签名: 《微信支付代码重构带来的移动端软件架构上的思考》http://www.52im.net/thread-2958-1-1.html
引用:JackJiang 发表于 2018-06-05 21:24
你回想一下QQ群是怎么慢慢从50人、200人、500人、1000人群这些做起来的了。
群聊其实并不是个很简单的问 ...

是的 非常有道理
我们刚刚做群聊,感觉里面的水很深,但是其他部门的同事,觉得群聊是微信好多年前就有的功能,应该是很基础的很简单的白菜技术,
看了本站的另一篇文章,单聊和小群写扩散,大群读扩散,是比较合理的方案
签名: 该会员没有填写今日想说内容.
引用:researchboy 发表于 2018-06-06 16:22
是的 非常有道理
我们刚刚做群聊,感觉里面的水很深,但是产品和其他部门的同事,觉得群聊是微信好多年 ...

是的,微信和qq的迭代过程是他们的事,他们已经走过的路踩过的坑,不代表你们可以跳过,并不会把迭代成果给你用啊,哈哈

目前这样的方案算是比较合理
签名: 《微信支付代码重构带来的移动端软件架构上的思考》http://www.52im.net/thread-2958-1-1.html
引用:JackJiang 发表于 2017-07-14 11:01
要实时性好肯定是RPC,但主要看你的应用场景是看重性能还是实时性

接入层与逻辑层,怎么通过RPC框架解耦的,实在想不通了。哪个算是RPC里的consumer,哪个是provider
引用:hello1234 发表于 2018-07-03 17:14
接入层与逻辑层,怎么通过RPC框架解耦的,实在想不通了。哪个算是RPC里的consumer,哪个是provider

这其实两方都有可能是对方的生产者或消费者。正确地理解是:接入层是专门用来管理客户端长连接的,客户端发出或收到的消息都是通过这个接入层来完成的,这也是socket长连接程序的特性。
签名: 《微信支付代码重构带来的移动端软件架构上的思考》http://www.52im.net/thread-2958-1-1.html
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部