怎样在微信公众号里做微网站网站收录有什么用

问题

IM 系统从架构模式上包括 【介绍人模式】和 【代理人模式】。介绍人模式也叫直连模式，消息收发不需要服务端的参与，即客户端之间直连的方式；代理人模式也叫中转模式，消息收发需要服务端进行中转。

下面关于这两类模式描述的说法正确的有哪几项呢？  

A. 介绍人模式需要解决 P2P 打洞技术问题；

B. 代理人模式方便对消息内容进行风险管控；

C. 介绍人模式不利于实现消息漫游，影响用户体验；

D. 从性能上比较，介绍人模式比代理人模式的性能更优。

解析

A选项：早期的很多IM软件大都采用了介绍人模式，也就是要通信的两个客户端进行直连的模式；如果这两个客户端在同一个局域网中，建立连接是非常方便的（比如现在仍在普遍使用的“飞鸽传书”）；如果这两个客户端是在不同的局域网中（局域网中的客户端是没有公网IP的），怎么建立连接呢？这个时候往往需要P2P打洞技术。这个地方有一个非常有意思的面试题目：几乎所有的客户端都是没有公网独立IP的，但我们上网时，那些服务器程序回复的数据包是怎么找到我们的客户端的呢？（大家可以自行学习一下  NAT 技术！）介绍人模式见下图。

B选项：代理人模式对消息内容可以方便地进行风控管理，这个是非常容易理解的；毕竟在介绍人模式下进行风控管理，用户体验、代价和复杂度都太大了！（大家想一下，为什么？）代理人模式见下图。

C选项：介绍人模式下，消息都保存在客户端本地；换一个终端设备，消息如何漫游呢！

D选项：收发消息的性能损耗，除了网络传输外，还有对连接的管理和维护、网络异常情况的处理、消息落库、复杂的业务处理、程序逻辑框架等等；介绍人模式下，所有的客户端既是客户端也是服务端，在活跃的聊天场景（比如群聊）中，所有的客户端形成了一种网状的通信模式；在极端情况下，每一个客户端要处理其他所有的客户端请求，此时客户端的性能是很难提升的；而如果将压力转移到扩展性非常好的服务端，也就是代理人模式，整个 IM 的性能就会提升很多。当然，我们是工程派，对性能的论断没有一个实验环境进行完整的实验是不合理；这个地方重点强调的是：介绍人模式不会因为看似网络传输减少了一个环节，其性能就比代理人模式要优！

扩展一下：

我们对这两种 IM 的架构方案进行抽象： 

IM 的介绍人模式其实就是【边缘计算方案】，充分利用每个客户端节点的计算能力进行业务逻辑处理；

IM 的代理人模式其实就是【中心计算方案】，充分利用中心服务器的计算能力进行业务逻辑处理。

参考答案

ABC