融云首席架构师李淼：即时通讯服务异地双活的那些事儿

前言

首先请您介绍一下自己，您在融云负责哪些方面的工作？

李淼：我的履历比较简单，基本上一直在做即时通讯领域相关的研发工作。14年3月份的时候融云团队成立，我是融云的第一个程序员，当时作为架构师，负责整个产品的架构设计。在此之前，我一直在神州泰岳从事飞信相关的研发，融云初创的时候，我对即时通讯领域最为拿手，所以选择做即时通讯也是顺理成章的事情。

不过虽然我是从飞信转过来的，但并不是将飞信的技术延续接着做，我们是利用之前的积累，重新开发了一套架构和通讯协议，因为我们觉得飞信的协议设计的比较重，已经不太适合移动互联网了。 

请介绍一下你们的异地双活项目

李淼：我们在做融云的时候已经想到做异地多活的架构，实际上我们这个不是双活，是一个多活的架构，但多活就要做多份部署，由于前期成本的问题，所以我们先把融云的基本功能做起来，在需求基本上稳定的情况下，现在再把当初设计的异地双活加入到融云的项目里。我们融云的项目是14年6月份正式上线的，异地双活则是15年1月份开始启动，对融云进行架构改造，可以看做是对融云架构的一个升级。

你们上马异地双活项目的原因和契机是什么？ 

李淼：刚才说过我们在设计融云的架构时候已经考虑到了异地双活，我们做异地双活首先是应对各种突发的意外事件，比如光缆被挖断，又比如IDC出事故。我们在做飞信的时候已经遇到过类似的情况，飞信虽然部署在移动的机房里，但由于工程施工，也会出现电缆被挖断的事故。所以从最开始的时候我们已经想到了异地双活的事情。另外，多活的架构有一定的前瞻性，由于融云是个全新的产品，我们在设计架构的时候就将最新的思想融入进来，现在的这些支付宝和携程事件，证明我们当初的想法是对的。

对于异地双活你们做了哪些调研？能否介绍一下其中的技术？

李淼：在设计双活架构之前我们已经做过很长时间的调研，包括新浪、腾讯、阿里，听过他们的一些讲解，我们消化完之后结合即时通讯的一些特点设计了这样一个架构。

关于里面的技术，单拿即时通讯而言，它可能包含几个东西，第一个层面是双的问题，这里面有两点，首先是多机房的数据同步，然后是多机房用户之间的通讯。即时通讯类应用和电商这种不太一样，电商类业务要求只做数据同步，但我们还要求用户与用户之间在数据中心有数据交换，这两点是我们着重要解决的。 

第二个层面，你做了双活，就涉及到一个活的问题。一个机房挂了，是不是可以把流量导入到另一个机房。我们的数据中心不直接向用户提供服务，而是在数据中心之上做了很多代理，这些代理不提供业务，只作为流量入口，和数据中心不放在一起，而是放在全国各地，用户通过代理来访问数据中心，代理如果检测到数据中心出现问题，它会自动把流量导入到另一个数据中心。

我们主要就从这两个层面来展开工作和研究。

对于即时通讯类应用的异地双活，有哪些难点和问题？

李淼：一个是刚才说到的代理的问题，实际上这个代理涉及到一些比较精巧的机制，比如如何检测数据中心的存活，检测完之后还需要做跳转，而这些需要在极短的时间内完成，保证持续不间断的提供服务。

另一个难点是数据中心之间的数据同步。即时通讯有一个特点，就是它对消息的实时性要求特别高，但对数据存储是允许有一定延迟的，所以我们在数据同步这块主要需要提高可靠性，我们用了类似于消息队列的方式，然后进行“慢同步”，最终保证这个数据是一致的。不过这里虽说是慢同步，但实际还是很快的。每个数据中心都会保留一份全量数据，我们保存的是客户授权给我们用户基本信息，还有一部分是群关系。

异地双活项目目前部署的情况如何？

李淼：我们现在已经进入到上线的部署测试阶段，尝试将一部分流量导入到第二个数据中心，我们现在的这个架构可以实现流量控制，我们可以通过配置，将用户和流量按照设想的方式分配。一般而言，真正理想状态的异地双活，每个数据中心需要能完全承受整个业务流量，而平时单个数据中心承担的流量为50%，还需要预留超过50%的缓冲，这样在一个机房宕掉之后我们可以将流量切换到另一个机房，用户甚至不会有感觉。

为了保证数据中心之间的数据快速同步，我们把数据中心都建立在有专线的IDC机房之间，打个比方，我们现在用的是青云，第二个数据中心是同城的，第三个数据中心是和第二个有专线的异地机房，所以其实可以理解为“两地三活”这样一个模式，两地三活基本上在金融业讲得比较多，因为他们对数据的一致性和备份要求非常高，在这块部署方面我们也借鉴了一些。 

关于受访者

李淼，融云联合创始人、首席架构师。2007年加入神州泰岳飞信团队，负责融云即时通讯云平台的设计与研发工作。通过多年在即时通讯和云计算领域的实践和探索，完成了基于云平台的即时通讯架构设计和适应移动互联网的通讯协议和信令交互设计。

来源：即时通讯网 - 即时通讯开发者社区！