本文转载自Startalk开发者，期待的搓搓小手，让我们来揭秘去中心化的im如何设计吧！！
Startalk目前全套代码已全面开放至Github网站，地址：github.com/qunarcorp/q…
Startalk 官网地址：im.qunar.com/new/#/home
****************************************************************************************
本文的重点是Startalk的去中心化设计，然而和当前很火的区块链并没有什么关联。它的重点即是Startalk的架构演进史，也是IM系统发展的一个小缩影。
我们会从以下这4个部分内容中了解Startalk去中心化主要解决的问题和方法:
Startalk是什么
Startalk过去的设计
Startalk的去中心化
有效案例
一、Startalk是什么
Startalk是从2015年开始为Qunar服务的自动化办公软件，到现在已经有4年多的时间了。最初的初创团队只有4个人。
制作Startalk的初心是为了解决当时我们在用RTX时候遇到的很多性能和使用上的问题。而且在当时，RTX还没有移动版本。
4年说短也不短了。在这个过程中，我们人手一直没能超过两位数，然而经过这几年的发展，我们已经开始在满足于办公自动化场景的基础上，实现了商务客服场景，以及自行设计的客服转接系统，当然，这部分内容由于不是主要内容，会出现在以后的系列介绍中。
团队从2017年后半年开始，工作重心逐步的转向了开源、去中心化和智能机器人领域。
读到这儿，可能很多读者会说， 即时通信我们有微信了哈，已经很好用了，为啥还要用其他的，甚至要开发自己的im系统呢？
其实，微信是重社交的，我们的办公和商务场景并不是那么侧重于社交。
我们从以下两个方面来阐述这个问题：
1、办公
要给同事发送核心客户名单，交易数据，身份证号，担心免费聊天工具不安全
大家知道，前阵子facebook刚出过安全事故，为什么会出现安全问题呢，当然并不是说fb在安全领域做的不够好，实际上他们的安全体系很健壮，比一般公司都要强大，
然而由于他们(facebook)是一个中心化的设计，所谓中心化的设计就是客户使用业务提供商提供的客户端登录到提供商的后台服务器，然后用户的任何一个操作的数据都保存在他们公司的服务器上了
既然数据集中在一个点保存，那么被攻克、被泄漏就并不是什么特别奇怪和偶然的事情。
出差没有带电脑，却有一大堆流程亟待审批
每个经常出差的人都清楚，如果OA只能在电脑上批，那将极大的影响办公效率。集成到公网上？自己家的办公系统放在公网貌似不是那么的靠谱。
尤其是再遇上某些多客户端登录，聊天记录不能完全同步的IM,将是一种灾难。
公司内的提升生产效率的一些自定义应用无法整合
现在我们已经进入了移动互联网时代，大家可能会发现，每新到一个公司就要装一批app,这已经是现在的通病了。反观微信，它的集成能力很强，但是很少有公司会把企业办公挪到微信上直接使用。
为什么呢？还是安全性、隐私的问题。
2、 社交
- 微信是重社交的软件，需要加好友才可以继续聊天。
因为微信是在广域网上的，如果能随便找到一个用户就可以聊天，那么安全性，骚扰，都是问题。
由于这些问题，当我需要立刻找到某个我不认识的人的时候，就会很麻烦。比如我现在需要联系某个部门的新来的团队负责人，如果是微信的话，我们需要加个好友才可以；
如果用Startalk，只需要走到相应的组织结构的位置上，就可以跟他进行沟通了，我不需要事先认识他，也不需要先跟他加个好友才可以继续。
与其同时的，很多人把工作和生活分得很开，微信就是平时生活上用的，如果里头有很多不是很熟悉的同事看自己的朋友圈，也是个挺奇怪的事情。
二、 Startalk过去的设计
很多人都觉得实现个IM很容易，其实有一定道理。做个能聊天的软件非常简单，很多前端用一下午时间就能coding出个完全可用的聊天室来，做出这个并不复杂。
然而一个成熟的im系统是需要各种能力协同配合的，笔者十年前就在做全国排名前三的IM，当时我就认为im的复杂性不亚于游戏。现在看虽然十年时间过去了，结论仍旧适用。那么由于涉及的技术领域比较广，标准化也就没那么容易，也就有了这篇文章和这个团队。
先来看看老版本的Startalk的架构图:
- ejabberd通过用户hash的方式来进行扩展
- 其他部分的功能横向扩展
客户端有3种类型连接，分别是TCP、UDP、HTTPS。客户端使用TCP连接保持双工通信。UDP主要用来搞音视频。HTTPS执行一些状态无关类操作。
最重要的一条连接来自于ejabberd，大家应该比较熟悉了，号称单机负载100万条连接没啥问题哈。实际测试也确实是这样，实测不需要怎么调优就达到30～40万在线还是很轻松的。
然后我们各种折腾，各种调优，发现和世界上其他所有的系统一样，该出问题还出问题。
接下来，我们认为我们进入了一个怪圈，系统确实存在有这样或者那样的问题，然而我们貌似是在为了优化而优化，为什么呢？我们来分享一下Startalk的业务数据:
Startalk日平均在线 6500人
单人 | 群内成员 | |
消息数量 | 25万 | 10万 |
人数 | 6000 | 3000 |
平均 | 40 | 33 |
这里只有Startalk某个时间点上的数据，仅供参考。Qunar商业版本数据涉及到商业数据的问题，就不能透露了，这里我们介绍下办公版本，其中消息量不包括机器人的推送消息
看到图之后我们会发现两个特点：
- 貌似每天有500个人不说话。。。
- 从使用频率上来讲呢，我们跟微信基本是一个层次的，2017年微信的运营数据也是日人均40条消息
看完这个表格之后，大家也就明白了，由于应用特性，我们的IM不需要过多的考虑上亿用户在线的场景，目前的能力完全足够用了。
那怎么办呢？
三、Startalk的去中心化
在经历了各种折腾发现根本用不上了之后，我们参考了很多类似的app，发现大家多数都在往中心化的模式设计
然后仔细的思考了一阵之后，我们发现其实去中心化是一条非常可行的路线。
在这里，可能有些同学认为去中心化的目的是针对性能和容量的优化，其实去中心化的重点是安全性、易用性和可部署性，其次是根据现有客户群体，兼顾了性能和容量。
那么我们看看去中心化最关注的安全性是什么呢？
如果您使用免费IM搞企业办公，就像下面这个图。。。
您的Idea，商业机密，客户资源，团队核心成员的联系方式以及组成， 都一览无余的展现给了您的潜在竞争对手。
在这里，服务提供商可能是无辜的，可能是帮凶。正如上面所说，facebook本意并不希望信息外泄。但是他们不可能做到永远不出安全问题。
那么大家在使用各种门类的免费im做企业办公的时候，这个问题是必须要考虑的。
看明白这个，大家也就明白了，为什么现在有几个大型的移动互联网公司都在搞自己的IM，很多公司宁可养一个成本很高的团队，也不会去用免费的版本。
看看新的架构图：
在新架构中，以前的模块被拆分，非状态服务合并到了Public中，状态服务进入了Domain中。Domain横向扩展，相互之间隔离。
然后部署方式也跟着去中心化了：
图很简单，以前是大家连中央服务器；现在大家需要在自己家里部署一套im服务。然后就可以连自己家的机器了。
这样一来呢，每个节点都独立运营了，数据也都只保存在节点中。一切都很美好，又回到了当前Startalk架构的基础形态了。
客户端上呢，由于我们的客户端支持同时连接多个节点，用户也不需要装多个客户端就可以满足需求。
然而，这样就引入了另外一个话题：如果我企业比较大，我还想按部门、按照各辖区分公司为单位进行去中心化部署，
这样部门与部门之间数据肯定是可以不进行共享的哈，当我需要跨分公司跟其他部门的人进行沟通，怎么办呢?
去中心化了以后的QTalk在节点间新增了一个Proxy做打通。打通的双方都需要做一些配置才可以使得这个Proxy变得可用。
这样一来的结果，domain间数据独立。在proxy加持的情况下，domain可以与其他domain进行互通。彻底的解决了安全的问题
同时由于每个domain支持的人数并不会很多，还记得之前分享的表格吧，所以性能和容量上得到了保证
四、有效案例
目前去哪儿网站、APP中的各种售前、客服，都是用Startalk的核心实现的。使用了最新的去中心化的设计和部署方式。效果见下图：
- 某高校的校园管理系统
这里为了保护用户隐私，隐去用户的名称。
这套系统有以下几个特点：
学院间互相独立，独立部署
校园APP全部移植到IM上
IM不仅做app容器，也做统一登录认证系统
用户使用客户端SDK做客户端接入
以上是StarTalk的去中心化设计及部署理念。后续文章中还会继续分享客服、智能AI机器人等相关内容，感谢各位的观看，谢谢！
*****************************************************************************************
Startalk目前全套代码已全面开放至Github网站，地址：github.com/qunarcorp/q…
Startalk 官网地址：im.qunar.com/new/#/home
