XMPP

背景

XMPP是一种以XML为基础的开放式即时通信协议。

Turms自身不采用XMPP协议是因为：

• 设计非常低效：
  • 数据格式采用了冗余低效的XML协议，其元数据很多时候比实际传输的数据还大。
  • XMPP的流程设计中，存在大量低效设计，比如将用户头像图片转换成Base64文本进行传输，又比如用户修改了某些个人信息，服务端需要将该信息主动推送给其联系列表中订阅其在线状态的用户。
• 拓展性差。一些文章会说XMPP拓展性强，但这种“拓展性强”也只是相对于那些没啥拓展性的协议而言的。真正拓展性强的协议肯定是自研协议。

但考虑到以下两点，我们计划在近期适配Turms服务端，以对XMPP协议提供支持：

• XMPP的生态恰好弥补了Turms的一个缺点，即：一些开发者在Turms项目下反馈：基于Turms从零开始实现一套定制的IM应用还是比较复杂的，尤其还需要自己的团队来实现UI界面并适配接口，因此目前Turms更适合想深耕IM的团队来研究与使用，并不适合快速发布产品。

  而XMPP正好有着比较丰富的客户端生态，Turms服务端只要稍微适配下，就能为XMPP客户端提供服务。这样用户既可以快速使用各种带UI的XMPP客户端对外提供服务，又能享受到Turms的优点，等用户想打造专属于自己的IM应用后，可以再逐步淘汰XMPP客户端，并转移到Turms客户端上。

  补充：由于Turms的定位，我们在长期计划中都不考虑安排“提供带UI的客户端实现”相关的任务。换一种说法，我们只会在发布了为Turms定制的压测平台、数据分析平台等平台，并实现了各种拓展功能特性与各种Bug修复，才会开始考虑提供带UI的客户端，因此该任务的优先级是极低的。

• 大部分知名的XMPP开源服务端项目的不仅技术架构老套、技术栈陈旧、性能糟糕，而且代码水平与工程能力都偏低。以Tigase项目为例，作为发展了数十年的开源项目，竟然还会犯大量用==比较字符串的低级错误，又或者大量地将数据模型与业务逻辑杂糅在一起，没有代码设计的能力，开发水平之低，令人咋舌。

  尽管部分开源XMPP服务端会宣传自己的架构可拓展性“Scalable”强，但其可拓展性跟Turms比起来，就相形见绌了。Turms是在真正意义上，在架构、自身代码实现、数据库设计等方面，尽量把各方面（包括可拓展性）做到极致的项目，因此在中大型IM领域，Turms可以对其进行降维打击。

注意：其实我们并没有计划让Turms服务端取代其他XMPP服务端，因为XMPP服务端与Turms服务端的定位非常不同，XMPP服务端的一大作用是实现即时通讯的开放互通（就像邮件一样开放互通），但Turms服务端支持XMPP协议主要是为了让用户可以快速使用XMPP客户端与Turms服务端互通，从而快速对外提供服务，而且我们也没计划支持Turms服务端与其他XMPP服务端互通。

实现原理

• turms-gateway服务端内部先实现了一个定制的XMPP服务端。

  补充：需要定制是因为Turms服务端用不到XMPP协议规定的一些功能，因此也就没必要实现了，但定制的XMPP服务端依旧能兼容标准的XMPP客户端。

• 该XMPP服务端在接收到XMPP客户端的请求后，会将这些请求转换成对应的Turms服务调用，因此从后续调用的角度看，XMPP客户端请求与Turms客户端请求走得都是类似的逻辑，最终实现XMPP客户端与Turms客户端互通。

  补充：

  • 二者使用“类似的逻辑”是因为它们的业务流程略有差异，并不是100%的一对一关系。
  • XMPP客户端与Turms客户端共用账号体系，因此一个账号既可以使用XMPP客户端登陆，也可以用Turms客户端登陆。
  • XMPP客户端并不知道Turms客户端这一概念，反之亦然。二者之所以能互通是因为turms-gateway会将数据转换为它们能理解的协议格式，再进行发送。