共计 5328 个字符，预计需要花费 14 分钟才能阅读完成。
本文由作者 jinglijun 编写批改，出处链接：https://blog.csdn.net/justinj…
OpenIMgithub 开源地址：
https://github.com/OpenIMSDK/…
OpenIM 官网：https://www.rentsoft.cn
OpenIM 官方论坛：https://forum.rentsoft.cn/
对微信、陌陌等进行了剖析，收回来分享一下（工夫有些久了）电量：对于挪动设施最大的瓶颈就是电量了。因为用户不可能随时携带电源，充电宝。所以必须思考到电量问题。那就要查看咱们工程是不是有后盾运行，心跳包发送工夫是不是正当。
网络： 这个也是 IM 最外围的内容了，咱们要做到在任何网络下等顺畅聊天那就不容易了，好多公司都用的 xmpp 框架，如果在强网络环境下，xmpp 齐全没有问题。然而那种弱网络环境下 xmpp 就大刀阔斧啦，用户体验就很垃圾了。集体感觉 xmpp 能够玩玩（参考看这个 RFC3920 和 RFC3921），然而用来真正的产品就差远了。如果遇到一个做 IM 的敌人张口闭口都说 xmpp 的话，那么不必沟通了，必定不是什么好产品。微信、QQ 以前也曾用过 xmpp，然而最初也放弃了 xmpp，就晓得 xmpp 有很多弊病了，还有就是报文太大，好臃肿，节约流量。为了保障稳固，微信用了长链接和短链接相结合，例如：1，两个域名 微信划分了 http 模式（short 链接）和 tcp 模式（long 链接），别离应答状态协定和数据传输协定 long.weixin.qq.com dns check（112.64.237.188 112.64.200.218）short.weixin.qq.com dns check (112.64.237.186 112.64.200.240) 2，阐明
2.1 short.weixin.qq.com 是 HTTP 协定扩大，运行 8080 端口，http body 为二进制（protobuf）。
主要用途（接口）： 用户登录验证; 好友关系（获取，增加）；音讯 sync (newsync)，自有 sync 机制；获取用户图像；用户登记；行为日志上报。朋友圈发表刷新
2.2 long.weixin.qq.com tcp 长连贯，端口为 8080，相似微软 activesync 的二进制协定。
主要用途（接口）： 承受 / 发送文本音讯；承受 / 发送语音；承受 / 发送图片；承受 / 发送视频文件等。
所有下面申请都是基于 tcp 长连贯。在发送图片和视频文件等时，分为两个申请；第一个申请是缩略图的形式，第二个申请是全数据的形式。
2.2.1 数据报文方面 增量上传策略：每次 8k 左右大小数据上传，服务器确认；在持续传输。
图片上传： 先传缩略图，传文本音讯，再传具体文件
下载： 先下载缩略图，在下载原图 下载的时候，全部一次推送。
3 附录 3.1 用户登录验证 POST /cgi-bin/micromsg-bin/auth HTTP/1.1 Accept: User-Agent: Mozilla/4.0 Content-Type: application/x-www-form-urlencoded Host: short.weixin.qq.com Content-Length: 174
3.3 音讯 sync (newsync) POST /cgi-bin/micromsg-bin/newsync HTTP/1.1 Host: short.weixin.qq.com User-Agent: Android QQMail HTTP Client Cache-Control: no-cache Connection: Keep-Alive Content-Type: application/octet-stream accept: Content-Length: 206
3.5 用户登记 POST /cgi-bin/micromsg-bin/iphoneunreg HTTP/1.1 Accept: User-Agent: Mozilla/4.0 Cotent-Type: application/x-www-form-urlencoded Host: short.weixin.qq.com Content-Length: 271
3.6 行为日志上报 POST /cgi-bin/stackreport?version=240000a7&filelength=1258&sum=7eda777ee26a76a5c93b233eed504c7d&reporttype=1&username=jolestar HTTP/1.1 Content-Length: 736 Content-Type: binary/octet-stream Host: weixin.qq.com Connection: Keep-Alive User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)
从当初互联网的倒退而言，IM 和视频（包含 IM 外面视频通话）是一个方向，这些都应该成为互联网的基础设施，就像浏览器一样。当初 IM 还没有一个很好的解决方案，XMPP 并不能很好地做到业务逻辑独立开来。从 IM 的实质来看，IM 其实就是将一条音讯从一个中央传输到另外一个中央，这个和 TCP 很像，为什么不实现一个高级点的 TCP 协定了，只是将 TCP/IP 外面的 IP 地址换成了一个相似 XMPP 的惟一 ID 而已，其余的很多细节都能够照搬 TCP 协定。有了这个协定之后，将业务逻辑在现有 HTTP server 的根底上做，例如发送语音和图片就相当于上传一个文件，服务器在解决完这个文件后就发一条非凡的 IM 音讯。客户端收到这个 IM 音讯后，依照 IM 音讯外面 url 去 HTTP server 取语音文件和图片文件。将 HTTP server 和 IM server 买通之后，能够做很多事件。但将这个两个 server 合并在一块并不是一个坏事，不然腾讯也不会有 2005 年的策略转型了。从当初的状况来看，利用除了游戏，都没怎么赚钱，当初可能承载赚钱业务的还是以 web 为主。IM 不能够赚钱，但没有却是不行的，就像一个中央要致富，不修路是不行的情理一样。
下面说到了 protobuf，就简略介绍下：JSON 置信大家都晓得是什么货色，如果不晓得，那可就真的 OUT 了，GOOGLE 一上来。这里就不介绍啥的了。
Protobuffer 大家预计就很少据说了，但如果说到是 GOOGLE 搞的，置信大家都会有趣味去试一下，毕竟 GOOGLE 进口，多属精品。
Protobuffer 是一个相似 JSON 的一个传输协定，其实也不能说是协定，只是一个数据传输的货色罢了。
那它跟 JSON 有什么区别呢？
跨语言，这是它的一个长处。它自带了一个编译器，protoc，只须要用它进行编译，能够编译成 JAVA、python、C++ 代码，临时只有这三个，其余就临时不要想了，而后就能够间接应用，不须要再写任何其余代码。连解析的那些都曾经自带有的。JSON 当然也是跨语言的，但这个跨语言是建设在编写代码的根底上。陌陌设计：陌陌倒退刚开始因为规模小，30-40W 的连接数（包含 Android 后盾长连贯用户），也应用 XMPP；因为 XMPP 的毛病：流量大（基于 XML），不牢靠（为传统固定网络设计，没有思考 WIFI/2G/3G/ 地铁 / 电梯等简单网络场景），交互简单（登陆需 5 - 6 次，尤其是 TLS 握手）；XMPP 丢音讯的根本原因：服务端和客户端处于“半敞开”状态，客户端假连贯状态，服务端有收不到回执；Server 端连贯层和逻辑层代码没有解耦拆散，经常重启导致不可用；
音讯直达：
链接层：
逻辑层：
通信协定设计：
高效：弱网络疾速的收发 牢靠：不会丢音讯 易于扩大 协定格局：
Redis 协定：
优化
- 连贯层（参见通信服务器组成）：只做音讯转发，容许随时重启更新，设计准则简略 / 异步；单台压测试连接数 70W；现状：1.5 亿用户，月活 5000W+，连接数 1200W+；
- 逻辑层（参见通信服务器组成）：用户会话验证即登陆、音讯存取、异步队列
- 采纳公有通信协定，指标：高效，弱网络疾速收发；牢靠：不会丢音讯；易于扩大；参考协定格局：REDIS 协定；参见协定格局、基于队列的音讯协定、基于队列的交互、基于版本号的音讯协定、基于版本号的交互等；
- 外围的长连贯只用于传输轻量的实时数据，图片、语音等都开新的 TCP 或 HTTP 连贯；所有就绪后，最重要的就是监控，写一个 APP 查看所有的经营状态，每天察看；
- 如何抉择最优路线，即智能路由；二、智能路由、连贯策略： 多端口、双协定反对 应答挪动网关代理的端口限度 反对 TCP、HTTP 两种协定 依据备选 IP 列表进行并发测速（IP+ 端口 + 协定）后端依据终端连贯状况，定时更新终端的备选 IP 列表 终端在连贯闲暇时上报测速数据，便于后端决策 TCP 协定不通，主动切换到 http 优先应用最近可用 IP 并发测速，依据终端所处的地位下发多组 IP、PORT，只用 IP，不必域名，手机上的 DNS50% 不准 负载均衡器(LVS…) 的问题– 单点生效
单点性能瓶颈
负载平衡从客户端开始做起• 域名负载的问题
域名零碎不牢靠– 更新提早大 WNS（wireless network services）
1 解决挪动互联网开发常见问题：通道：数据交互、大数据上传、push 网络连接：大量长链接治理、链接不上、慢、多地散布 经营撑持：海量监控、简化问题定位 登录 & 平安：登录鉴权、频率管制
挪动互联网特点：1、高延时：信道建设耗时（高 RTT）2、低宽带、高丢包 3、多运营商（电信，挪动，联通等）4、简单网络 -2G，3G，4G，wifi。cmwap，cmnet。。-网关限度：协定，端口 5、用户流动性大，上网环境简单
1、开发工夫：历史一年半 2、链接成功率 -99.9% 3、极其网络环境下成功率- 因为常见 app 4、crash 率 -0.02%（crash 次数/登录用户数）
微信后盾零碎架构
背景：
A、分布式问题收敛 后盾逻辑模块专一逻辑，疾速开发 可能读取到过期的数据是个痛点 须要看到统一的数据 B、外部定义 数据领有两个以上的正本 如果胜利提交了变更，那么不会再返回旧数据 推演：1 减少一个数据 2 序列号发生器，偏序 束缚：只能有一个 client 操作 client 有解决抵触的能力 问题转移：client 如何散布？3 批改集群中一个制订的 key 的 value（1）笼罩他（2）依据 value 的内容做批改 if value = 1 then value：=2 通用解法：（1）paxos 算法 工程难度 所有可控
分布式算法设计：（2）quorum 算法（2011）再单个 key 下面运算 真是零碎束缚 类 paxos 计划，简化 为每次变更选举（by key）算法过程 提议/变更/同步/播送
零碎架构
写流程
Replication & Sharding 衡量点 自治，负载平衡，扩散控制 replication->relation
容灾对消 同城（上海）多数派存活 三园区（独立供电，独立）
Sharding
一组 KV6 为一个单位
1，人工阶段 部分扩容，影响收敛 9 2，均匀分布 制订分段 hash32（string）翻倍扩容
3，一致性哈希
具体实现？1、业务侧疾速开发 存储须要提供强一致性 丰盛的数据模型反对（结构化、类 SQL/KV）条件读，条件写
2 业务增长迅速，零碎要可能不便的横向扩容 3 设施故障/短时节点实效便成为常态，容灾自动化，主碑可写无需人工染指 4 小数据
存储模型 纯内存 Bitcask 小表零碎 LSM-tree
小表零碎 1、解决放大问题 2、数据按变更汇集存储 3、Affected1 ChangeTable（1+2+。。。。+n-1+total）/n 4、决裂与合并 数据流动 1、自动化迁徙 2、节点同时做代理 3、合并磁盘 io
同步流量 1、数据 vs 操作 2、幂等 3、保底策略
通信包量 1、动静合并 100K qps 200% -10% 3、衡量与估算 设计要点 1、吞吐量 2、异步化 3、复杂度 4、libco 主动修复零碎 1、不要让谬误累计 2、全量扫描 bitcask 的一些变动 1、内存限度 2、全内存
————————————————
OpenIM 官网：https://www.rentsoft.cn
OpenIM 官方论坛：https://forum.rentsoft.cn/
更多原创技术文章：
开源 OpenIM：高性能、可伸缩、易扩大的即时通讯架构
https://forum.rentsoft.cn/thr…
【OpenIM 原创】简略轻松入门 一文解说 WebRTC 实现 1 对 1 音视频通信原理
https://forum.rentsoft.cn/thr…
【OpenIM 原创】开源 OpenIM：轻量、高效、实时、牢靠、低成本的音讯模型
https://forum.rentsoft.cn/thr…
OpenIM 服务发现和负载平衡 golang 插件：gRPC 接入 etcdv3
https://forum.rentsoft.cn/thr…
【OpenIM 原创】简略轻松入门 一文解说 WebRTC 实现 1 对 1 音视频通信原理
https://forum.rentsoft.cn/thr…
【OpenIM 原创】C/C++ 调用 golang 函数，golang 回调 C /C++ 函数
https://forum.rentsoft.cn/thr…