深入了解微信Mars基础组件
发布网友
发布时间：2022-12-10 19:20
共1个回答
热心网友
时间：2023-12-16 22:21
Mars是微信在2017年开源的一套跨平台跨业务的基础组件。在这里可以给出github上的官方架构图
通过研究和学习，为什么要使用Mars我这里做了几点小结
1 如果你的应用只是一个普通的APP，并不涉及到即时通讯，或者你们的APP对于消息的即时性没有很强的要求，那么我比较推荐你只单独使用Mars的Xlog组件就可以了。这对你们app的日志管理，线上问题追踪和定位具有非常好的帮助。在接入了Xlog后，出现线上问题我们上家公司几乎可以做到5分钟内定位问题，10分钟给出解决方案。
2 STN组件的设计逻辑非常的贴合移动互联网的网络使用环境，是一套非常成功的解决方案，尤其是弱网环境和平台特性具有非常多的优化策略
3 Mars 是基于socket的解决方案，在网络调优方面具有跟强的主动性和可控性。
熟悉TCP传输协议的同学都知道，TCP在建立连接的情况下，如果当前的请求方没有在规定的时间内得到接收方的相应，那么就会发生重传的机制，这个也是TCP保证可靠性传输的一个重要的原则。我们在了解超时和重传是需要了解的两个指标
RTT：数据往返的时间；
RTO：超时重传的时间间隔
这里盗一张mars的官方图，我们来看下Android手机的tcp超时重传的时间间隔表现
是不是传输层已经有了超时重传机制，应用层就不需要了呢？其实不是的，我们可以知道tcp在经过一定的超时重传后才会确定当前的tcp不可用，返回timeout标示。但是这个时间非常的就，一般来说Android手机大概要6min才会确定当前的TCP连接不可用。但是对于移动端来说6min的时间是非常影响用户体验的，因此应用层的超时重传机制需要更加的敏捷。
但是需要注意，敏捷并不等于密集。在很多的场景下，密集的心跳机制并不能取到重新建连的效果，反而会是网络通道更加的恶劣。因此在经过多个尝试后，Mars采用了一下的几个超时方案
总读写时间这个比较好理解，就是一次完成的RTT所需要的时间，这里总结起来包括：
请求发送耗时- 类比TCP包传输耗时；
响应信令接收耗时- 类比ACK传输耗时；
服务器处理请求耗时- TCP接收端接收和处理数据包的时间相对固定，而服务器由于信令所属业务的不同，逻辑处理的耗时会差异明显，所以无法类比；
等待耗时- 受应用中请求并发数影响。
因此，我们提出了应用层的总读写超时如右图所示，最低网速根据不同的网络取不同的值。
总读写超时有一个弊端是无法确定服务端的处理请求时间，最致命的一点是相应信令的时间处理较长，这导致了在网络状态很差的情况下，同样需要较长的时间才可以进行重试。首包超时是指在tcp的第一次回包的情况就去确定这个信令的接受耗时。调整后的首包超时方案如下
首包超时有一个弊端，就是在网络堵塞的情况下，由于tcp的拥塞窗口和流量控制，一个tcp包会被切割成几个部分进行传输，也就是发生了tcp的拆包和粘包的现象。加入后续的包又丢失了，仍然需要整个完整的读写超时才能发生问题。这就引入了包包超时的机制：两个数据段之间的超时时间。因为包包超时在首包超时之后，这个阶段已经确认服务器收到了请求，且完成了请求的处理，因此不需要计算等待耗时、请求传输耗时、服务器处理耗时，只需要估算网络的 RTT。
动态读写超级更多的是依赖于当前的网络状况，这个网络状态评估就跟之前提到的SDT模块有着莫大的关系。Mars在动态超时的设计中，把当前的网络分为excellent和evaluate两种状态，分别在这两种状态中不停的调整当前的动态耗时。
我们先总结一下串行连接和并行的优缺点
串行连接：
1 资源占用小，服务端没有负载的压力
2 超时选择困难，连接最慢可用
并行连接
1 资源占用较大，服务端负债压力大
2 连接最快可用
复合连接
先看一下官方给的图
智能心跳指的是长连接过程中，应用层维护的自己和服务端的心跳连接。客户端在适当的时间周期内，向服务端发送一个心跳请求，判断当前的连接是否可用。一般的app处理是用一个定时的任务（45s）连续的向服务端发送ping请求，等待服务端的返回。如果心痛不同，则认为当前的长连接不可用，需要重新进行长连接的建联。
微信的智能心跳如下
心跳时间区间：最小4分30秒，最大9分50秒；
心跳增加步长：60秒；心跳稳定后，探测步长：20秒；
当前APP为活跃状态，长连刚连接前3个成功心跳，和没有网络，这3种情况使用固定最小心跳：4分30秒；其他情况使用自适应智能心跳，基本算法如下；
连续3个心跳成功后，每心跳增加60秒心跳步长，一直到最大9分50秒，设为固定状态；
连续3个心跳失败后，减少60+20秒，第4个心跳失败，直接设最小心跳4分30秒；
