话说要是自己实现一套 IM 的功能难度大吗？
source link: https://www.v2ex.com/t/855128
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
想自己做一个 IM 的包实现起来难度大吗？
MQTT 协议，java ，netty+socket
特别想问一下，就是这个"语音消息" 不是语音通话，一条条的语音消息，这个是怎么实现的呀？还有像聊天记录的存储格式了，有没有热心 v 友能给一些思路或者一些开源的参考~
ps： 语音消息，问了一个大佬，他说发语音消息的时候，先录音成.mp3 文件到本地，然后发送到另一端，另一端接收播放这个.mp3 ，这....
第 1 条附言 · 15 小时 21 分钟前
帖子的标题确实是我范围给的太大了！其实我只是想讨论一些IM功能的实现方式；
一套完整的IM的难度确实是取决于你想要实现功能的多少，承载多少用户量；
但是后者对我来说目前可以是不考虑的，如果功能都实现不了其他的就毫无意义~
所以只是想讨论一个功能的多种实现方式吧；
举个例子，假如要做一个APP，功能就对标实物对讲机，进入APP的所有用户，可以选择频道，在一个频道内，某一个用户发语音，频道内所有人都能听到而且是实时的；
上面我只是举例，IM的功能是很丰富的，但是你自己的产品的核心功能是你自己来决定的，可能我要做的SDK最主要的就是语音的实现，上面的需求会有很多种实现方式，但是作为核心的话要考虑低开销，高实时的性能问题，像文本 图片等功能在这里可能起到一个可有可无的需求；
 |
sadfQED2 21 小时 23 分钟前 via Android 大学 cs 专业学生，应该绝大多数人都写过 im 聊天软件吧
|
 |
XiLingHost 21 小时 23 分钟前 你可以把声音用 opus 之类的编码器进行编码，然后传二进制报文过去
|
 |
murmur 21 小时 21 分钟前 作业级别的语音消息真的可以这么做，以前没有 4g 网的时候要各种考虑压缩，现在的网速发个 mp3 问题也不大
|
 |
cutepeer 21 小时 18 分钟前 一般都用云服务了啦，接入 sdk ，消息云同步啥的都替你做好，云平台还能加审核过滤功能，你需要做的只是维护用户间的关系。全部自己实现的话就要维护太多东西了
|
 |
pubby 21 小时 16 分钟前 “ps： 语音消息，问了一个大佬，他说发语音消息的时候，先录音成.mp3 文件到本地，然后发送到另一端，另一端接收播放这个.mp3 ，这....”
难道不是这样吗？ 当然发送到另一端的可以是 mp3 文件，也可以是把文件存服务器，只发个播放地址过去。 |
 |
TimPeake 21 小时 12 分钟前 忽然想起了 ‘像寻’公众号事件 ， “”程序员都知道， 自己实现一套 IM 至少 2 个月以上“”
|
1 |
darkengine 21 小时 7 分钟前 语音消息就是录制好的 mp3 上传到服务器，发链接给对方，这个思路没毛病啊
|
 |
godleon 21 小时 4 分钟前 |
 |
lakehylia 21 小时 1 分钟前 语音消息可以用电信的标准，一般用 AMR 。
|
 |
lizy0329 20 小时 58 分钟前 0-1 难度不大 1-100 难度非常大
|
 |
janus77 20 小时 57 分钟前 这种宽泛的问题肯定看实际情况啊，毕业设计和商业产品不一样，服务端和客户端不一样，包含功能的多少也可以有变化（比如撤回、引用回复、发语音、表情包、视频、文件等）
你什么都没说我只能当成 “找外包 1000 做一个微信” 来看待了 |
 |
codehz 20 小时 56 分钟前 语音消息这么做也没啥问题，不过一般来说会有专门的格式编码——不需要多余的元数据，压缩算法专门针对（非即时的）语音场景
（另外二进制比文本效率高这说法槽点多到不知道从哪里开始说比较好（（（（ |
|
darkengine 20 小时 56 分钟前 @godleon
就像 2 楼说的是不是 可以编辑为 2 进制传输，这效率不是高太多了 ------------- 不要一开始就考虑优化。而且 2 楼提到的 opus 一般用在实时语音领域，需求里一条条的语音消息，完全没必要上这个增加复杂度。 |
|
XiLingHost 20 小时 55 分钟前 @yukiww233 mp3 的问题不是在于授权协议吗
|
 |
zsdroid 20 小时 53 分钟前 语音不用 mp3 ，用 amr ，体积小。语音消息有损压缩也没事。
还有长链接存储问题： 长链接无法存到数据库 /redis 中。那服务器 1 的用户给服务器 2 的用户发送信息，1 是找不到 2 下用户的 channel ，故无法直接发送信息。 |
 |
bruce0 20 小时 40 分钟前 我的理解啊 做个能用的不难, 但是做个好用的 就是没有上限的了, 也就是挺难的
|
 |
unnamedhao 20 小时 32 分钟前 看承载量，10 个人用跟 10 亿人用的难度差别还是很大的
|
 |
lonewolfakela 20 小时 15 分钟前 @XiLingHost #18 mp3 的专利不是已经过期了么
|
 |
tigerstudent 20 小时 13 分钟前 opus 调用不麻烦，能压缩到原音频的十分之一
|
 |
keppelfei 19 小时 35 分钟前 实现一套不难，最最简单的 websocket 就能搞一套，难得是集群扩展承载力。
|
 |
libook 19 小时 29 分钟前 可以把语音数据部分和传输部分解耦，不管啥格式的数据都可以在传输通道里走，这样你可以先上 MVP 方案用现成的编码格式，比如 mp3 ，等核心部分都搞定了，再看看是不是要替换语音编码。
除非你现在已经把 IM 核心功能都搞定了，就剩语音了。 |
 |
wxlwsy 19 小时 20 分钟前 计算机上，除开算法问题， 其他问题不难， 难的是如何落地。
|
 |
DrX 18 小时 11 分钟前 做一个能简单互相发消息的 IM 系统不难，假设这个难度是 1 。
在这个基础上做出一个不但要能发消息，还要用起来比较顺手的，已经非常困难了，非常多的细节需要考虑。关于这个我就举个例子：发送者可以自由发送五花八门各种格式的视频，接受者要能直接点看。这个别看就一句话，实际上做起来非常非常非常困难，基本上你需要集成一整套视频编码、解码、播放系统进去。这一步难度大约是 100 。 然后再在用起来比较顺手的基础上，做一套能支持海量用户的系统，这个就不是普通公司能完成的事情了，这个难度大约是 10000 。 |
 |
markgor 17 小时 52 分钟前 可是一套 IM 不止是发语音。
|
 |
beimenjun 17 小时 40 分钟前 做出来的 IM 是给一个人用的还是给一百万人用的，不是同一个级别的难度。
玩具你随便弄弄，弄成点对点都可以说是 IM 吧。 正儿八经的 IM ，服务端要考虑服务的拓展性、性能、灾备、安全性、合规。 落到移动客户端，这个问题可能还涉及客户端的耗电、内存使用、流量使用、数据状态的同步、各类错误处理。 |
 |
xiangyuecn 17 小时 25 分钟前 别问，问就是 上传+下载
|
 |
oppoic 17 小时 12 分钟前 关键问题是满足多大用户量。
如果只是几个人发发消息，用 ajax 轮询服务端也做了是吧 |
 |
yufeng0681 16 小时 17 分钟前 一个 IM 系统的讨论，偏离到语音消息的传送细节了。
有空去看看 GSMA 国际规范 RCS ，里面讲述的内容大于 IM ， 但是能更好的帮助你了解 IM 系统 |
 |
jstony 14 小时 56 分钟前 这么说吧，当年学校机房里写了个 im ，可以同学之间聊天，类似飞鸽传书，同一年，qq 第一版面市。
|
 |
pengtdyd 13 小时 2 分钟前 答：自己写个 IM 难度几乎为 0 ，重点是有人用。
|
 |
dudubaba 12 小时 12 分钟前 不难啊，就像现有的卖 IM 服务的企业根本不是卖技术本身，而是卖数据存储的，流量带宽大了贼贵。
|
 |
littlewing 12 小时 4 分钟前 功能做出来不难，难的是优化和用户体验，还有承载用户量
|
 |
stillyu 9 小时 27 分钟前 感觉会这么问的，不像是程序员
IM 可能没做过，但商城每个工作了的程序员都做过吧？ 自己做的商城和淘宝比，工作量和难度不都心里有数了吗？ ps：商品详情，问了一个大佬，他说编辑商品详情的时候，先编辑成.doc 文件存在本地，然后在商品详情编辑框粘贴上去，页面显示这个内容，这... |
 |
firechat 8 小时 12 分钟前 以我的经验给你几点建议吧
1. 格式用 amr ，amr 的好处是对人声处理的特别好，压缩比特别高，基本上每秒小于 1KB 。 2. 发送语音有 2 个种办法，一种是上传到一个服务器，把链接发送给对方，对方播放再下载；另外一种是直接放到消息体内直接发送给对方。如果是对讲语音，用第二种方式。 3. 对接的话不需要考虑存储，对方不在就直接丢掉。如果只有对讲可以不用考虑离线消息和消息存储。当然如果有其它类型的消息则必须实现了。 4. 不要从 0 开始写，现在有开源的 MQTT 服务和客户端，一个频道就是一个 topic 就行，再加上抢麦的功能，这种网上有很多抢红包的例子，比较类似。 5. 要逐步实现，不要贪大求全，上来就高并发微服务。先功能再优化。 另外感觉你问得太笼统了，如果做好一个通用型的 IM 是非常困难的，你基本上在这里得不到答案。你可以详细说一下问题和需求。 |
 |
nicevar 7 小时 43 分钟前 有一段时间做 IM 的扎堆，基本上都挂了，从头到尾自己做意义不大，直接上 XMPP 之类的就行了
|
|
XiLingHost 7 小时 4 分钟前 建议做一个用户体验好的 xmpp 客户端
|
 |
mingl0280 6 小时 26 分钟前 大，而且大到坑爹。
你举例的那个操作，要坑死你 1. 网络不好的带宽有限，移动网络的容易不在网，丢包网络的切换的时候丢了几个包，怎么办？实时性做到哪个程度？没听到的能不能回溯？ 2. 一个频道要承载多少人？网络协议走可靠的还是不可靠的？服务器要预备多少带宽？有没有 fallback 到 p2p 功能？如果 fallback 怎么打洞？ 3. 客户端要多少个平台？ Android 底下的设备要适配多少？ Apple 的呢？桌面的呢？ 4. 你这个系统准备有多少容灾，是不是个人部署，要不要考虑部署的合规性？ 还有具体的技术细节一箩筐…… |
 |
documentzhangx66 13 分钟前 1.作业级别的一点都不难，语音视频什么的无脑开源协议，甚至 mp4 、rtmp 等等。
2.如果要自己设计音频视频协议，那就麻烦很多，需要从数学原理开始进行优化，不然未压缩的 raw 音频与视频数据量，尺寸会大到离谱。 3.最麻烦的是给所有人用的量级，这就不是技术问题了。你需要有足够的资金，拿来买带宽、服务器、甚至机房。 |
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK