本文的重点是 QTalk 的去中心化设计，然而和当前很火的区块链并没有什么关联。它的重点即是 Qtalk 的架构演进史，也是 IM 系统发展的一个小缩影。

我们会从以下这 4 个部分内容中了解 QTalk 去中心化主要解决的问题和方法:

1.QTalk是什么；

2.QTalk过去的设计；

3.QTalk的去中心化；

4.有效案例。

一、QTalk 是什么

QTalk 是从 2015 年开始为 Qunar 服务的自动化办公软件，到现在已经有 3 年多的时间了。最初的初创团队只有 4 个人。

制作 QTalk 的初心是为了解决当时我们在用 RTX 时候遇到的很多性能和使用上的问题。而且在当时，RTX 还没有移动版本。

3 年说短也不短了。在这个过程中，我们人手一直没能超过两位数，然而经过这几年的发展，我们已经开始在满足于办公自动化场景的基础上，

实现了商务客服场景，以及自行设计的客服转接系统，当然，这部分内容由于不是主要内容，会出现在以后的系列介绍中。

团队从 2017 年后半年开始，工作重心逐步的转向了开源、去中心化和智能机器人领域。

读到这儿，可能很多读者会说， 即时通信我们有微信了哈，已经很好用了，为啥还要用其他的，甚至要开发自己的 im 系统呢？

其实，微信是重社交的，我们的办公和商务场景并不是那么侧重于社交。

我们从以下两个方面来阐述这个问题：

1.办公

• 要给同事发送核心客户名单，交易数据，身份证号，担心免费聊天工具不安全

大家知道，前阵子 facebook 刚出过安全事故，为什么会出现安全问题呢，当然并不是说 fb 在安全领域做的不够好，实际上他们的安全体系很健壮，比一般公司都要强大，

然而由于他们 (facebook)是一个中心化的设计，所谓中心化的设计就是客户使用业务提供商提供的客户端登录到提供商的后台服务器，然后用户的任何一个操作的数据都保存在他们公司的服务器上了

既然数据集中在一个点保存，那么被攻克、被泄漏就并不是什么特别奇怪和偶然的事情。

• 出差没有带电脑，却有一大堆流程亟待审批

每个经常出差的人都清楚，如果 OA 只能在电脑上批，那将极大的影响办公效率。集成到公网上？自己家的办公系统放在公网貌似不是那么的靠谱。

尤其是再遇上某些多客户端登录，聊天记录不能完全同步的 IM, 将是一种灾难。

• 公司内的提升生产效率的一些自定义应用无法整合

现在我们已经进入了移动互联网时代，大家可能会发现，每新到一个公司就要装一批 app, 这已经是现在的通病了。反观微信，它的集成能力很强，但是很少有公司会把企业办公挪到微信上直接使用。

为什么呢？还是安全性、隐私的问题。

2.社交

• 微信是重社交的软件，需要加好友才可以继续聊天。 因为微信是在广域网上的，如果能随便找到一个用户就可以聊天，那么安全性，骚扰，都是问题。

由于这些问题，当我需要立刻找到某个我不认识的人的时候，就会很麻烦。比如我现在需要联系某个部门的新来的团队负责人，如果是微信的话，我们需要加个好友才可以；

如果用 QTalk，只需要走到相应的组织结构的位置上，就可以跟他进行沟通了，我不需要事先认识他，也不需要先跟他加个好友才可以继续。

与其同时的，很多人把工作和生活分得很开，微信就是平时生活上用的，如果里头有很多不是很熟悉的同事看自己的朋友圈，也是个挺奇怪的事情。

二、 QTalk过去的设计

很多人都觉得实现个 IM 很容易，其实有一定道理。做个能聊天的软件非常简单，很多前端用一下午时间就能 coding 出个完全可用的聊天室来，做出这个并不复杂。

然而一个成熟的 im 系统是需要各种能力协同配合的，笔者十年前就在做全国排名前三的 IM，当时我就认为 im 的复杂性不亚于游戏。现在看虽然十年时间过去了，结论仍旧适用

那么由于涉及的技术领域比较广，标准化也就没那么容易，也就有了这篇文章和这个团队。

先来看看老版本的 QTalk 的架构图:

• ejabberd通过用户 hash 的方式来进行扩展

• 其他部分的功能横向扩展

客户端有 3 种类型连接，分别是 TCP、UDP、HTTPS。客户端使用 TCP 连接保持双工通信。UDP 主要用来搞音视频。HTTPS 执行一些状态无关类操作。

最重要的一条连接来自于 ejabberd，大家应该比较熟悉了，号称单机负载 100 万条连接没啥问题哈。实际测试也确实是这样，实测不需要怎么调优就达到 30～40 万在线还是很轻松的。

然后我们各种折腾，各种调优，发现和世界上其他所有的系统一样，该出问题还出问题。

接下来，我们认为我们进入了一个怪圈，系统确实存在有这样或者那样的问题，然而我们貌似是在为了优化而优化。

为什么呢？我们来分享一下 QTalk 的业务数据:

QTalk日平均在线 6500人

	单人	群内成员
消息数量	25万	10万
人数	6000	3000
平均	40	33

这里只有 QTalk 某个时间点上的数据，仅供参考。Qunar 商业版本数据涉及到商业数据的问题，就不能透露了，这里我们介绍下办公版本，其中消息量不包括机器人的推送消息

看到图之后我们会发现两个特点：

• 貌似每天有500个人不说话。。。

• 从使用频率上来讲呢，我们跟微信基本是一个层次的，2017年微信的运营数据也是日人均40条消息

看完这个表格之后，大家也就明白了，由于应用特性，我们的 IM 不需要过多的考虑上亿用户在线的场景，目前的能力完全足够用了。

那怎么办呢？

三、QTalk的去中心化

在经历了各种折腾发现根本用不上了之后，我们参考了很多类似的 app，发现大家多数都在往中心化的模式设计

然后仔细的思考了一阵之后，我们发现其实去中心化是一条非常可行的路线。

在这里，可能有些同学认为去中心化的目的是针对性能和容量的优化，其实去中心化的重点是安全性、易用性和可部署性，其次是根据现有客户群体，兼顾了性能和容量。

那么我们看看去中心化最关注的安全性是什么呢？

如果您使用免费 IM 搞企业办公，就像下面这个图。。。

您的 Idea，商业机密，客户资源，团队核心成员的联系方式以及组成， 都一览无余的展现给了您的潜在竞争对手。

在这里，服务提供商可能是无辜的，可能是帮凶。正如上面所说，facebook 本意并不希望信息外泄。但是他们不可能做到永远不出安全问题。

那么大家在使用各种门类的免费 im 做企业办公的时候，这个问题是必须要考虑的。

看明白这个，大家也就明白了，为什么现在有几个大型的移动互联网公司都在搞自己的 IM，很多公司宁可养一个成本很高的团队，也不会去用免费的版本。

看看新的架构图：

在新架构中，以前的模块被拆分，非状态服务合并到了 Public 中，状态服务进入了 Domain 中。Domain 横向扩展，相互之间隔离。

然后部署方式也跟着去中心化了：

图很简单，以前是大家连*服务器；现在大家需要在自己家里部署一套 im 服务。然后就可以连自己家的机器了。

这样一来呢，每个节点都独立运营了，数据也都只保存在节点中。一切都很美好，又回到了当前 Qtalk 架构的基础形态了。

客户端上呢，由于我们的客户端支持同时连接多个节点，用户也不需要装多个客户端就可以满足需求。

然而，这样就引入了另外一个话题：如果我企业比较大，我还想按部门、按照各辖区分公司为单位进行去中心化部署，

这样部门与部门之间数据肯定是可以不进行共享的哈，当我需要跨分公司跟其他部门的人进行沟通，怎么办呢 ?

去中心化了以后的 QTalk 在节点间新增了一个 Proxy 做打通。打通的双方都需要做一些配置才可以使得这个 Proxy 变得可用。

这样一来的结果，domain 间数据独立。在 proxy 加持的情况下，domain 可以与其他 domain 进行互通。彻底的解决了安全的问题

同时由于每个 domain 支持的人数并不会很多，还记得之前分享的表格吧，所以性能和容量上得到了保证

四、有效案例

• 基于去中心化部署的 QTalk 的商业版本，QChat。(https://qt.qunar.com/) 目前去哪儿网站、APP 中的各种售前、客服，都是用 Qtalk 的核心实现的。使用了最新的去中心化的设计和部署方式。效果见下图：

• 某高校的校园管理系统 这里为了保护用户隐私，隐去用户的名称。

这套系统有以下几个特点：

1.学院间互相独立，独立部署；

2.校园 APP 全部移植到 IM 上；

3.IM不仅做 app 容器，也做统一登录认证系统；

4.用户使用客户端 SDK 做客户端接入。

介绍到这里，相信大家对 QTalk 的去中心化部署有了基本的概念。后续文章中还会继续分享客服、智能 AI 机器人等相关内容，本次分享就到一段落，感谢各位的观看，谢谢！