基于Go的马蜂窝旅游网分布式IM系统技术实践

个人博客导航页（点击右侧链接即可打开个人博客）：大牛带你入门技术栈 

一、引言

即时通讯（IM）功能对于电商平台来说非常重要，特别是旅游电商。

从商品复杂性来看，一个旅游商品可能会包括用户在未来一段时间的衣、食、住、行等方方面面。从消费金额来看，往往单次消费额度较大。对目的地的陌生、在行程中可能的问题，这些因素使用户在购买前、中、后都存在和商家沟通的强烈需求。可以说，一个好用的 IM 可以在一定程度上对企业电商业务的 GMV 起到促进作用。

本文我们将结合马蜂窝旅游电商IM系统的发展历程，单独介绍基于Go重构分布式IM系统过程中的实践和总结（本文相当于《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》一文的进阶篇），希望可以给有相似问题的朋友一些借鉴。

系列文章：

《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》

《从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结》

《从游击队到正规军(三)：基于Go的马蜂窝旅游网分布式IM系统技术实践》（* 本文）

二、技术背景和问题

与广义上的即时通讯不同，电商各业务线有其特有业务逻辑，如客服聊天系统的客人分配逻辑、敏感词检测逻辑等，这些往往要耦合进通信流程中。随着接入业务线越来越多，即时通讯服务冗余度会越来越高。同时整个消息链路追溯复杂，服务稳定性很受业务逻辑的影响。

之前我们 IM 应用中的消息推送主要基于轮询技术，消息轮询模块的长连接请求是通过 php-fpm 挂载在阻塞队列上实现。当请求量较大时，如果不能及时释放 php-fpm 进程，对服务器的性能消耗很大。

为了解决这个问题，我们曾用 OpenResty+Lua 的方式进行改造，利用 Lua 协程的方式将整体的 polling 的能力从 PHP 转交到 Lua 处理，释放一部 PHP 的压力。这种方式虽然能提升一部分性能，但 PHP-Lua 的混合异构模式，使系统在使用、升级、调试和维护上都很麻烦，通用性也较差，很多业务场景下还是要依赖 PHP 接口，优化效果并不明显。

为了解决以上问题，我们决定结合电商 IM 的特定背景对 IM 服务进行重构，核心是实现业务逻辑和即时通讯服务的分离。

更多有关马蜂窝旅游网的IM系统架构的演进过程，请详读：《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》一文，在此不再赘述。

三、基于Go的双层分布式IM架构

3.1、实现目标

1）业务解耦：

将业务逻辑与通信流程剥离，使 IM 服务架构更加清晰，实现与电商 IM 业务逻辑的完全分离，保证服务稳定性。

2）接入方式灵活：

之前新业务接入时，需要在业务服务器上配置 OpenResty 环境及 Lua 协程代码，非常不便，IM 服务的通用性也很差。考虑到现有业务的实际情况，我们希望 IM 系统可以提供 HTTP 和 WebSocket 两种接入方式，供业务方根据不同的场景来灵活使用。

比如已经接入且运行良好的电商定制化团队的待办系统、定制游抢单系统、投诉系统等下行相关的系统等，这些业务没有明显的高并发需求，可以通过 HTTP 方式迅速接入，不需要熟悉稍显复杂的 WebSocket 协议，进而降低不必要的研发成本。

3）架构可扩展：

为了应对业务的持续增长给系统性能带来的挑战，我们考虑用分布式架构来设计即时通讯服务，使系统具有持续扩展及提升的能力。

3.2、语言选择

目前，马蜂窝技术体系主要包括 PHP，Java，Golang，技术栈比较丰富，使业务做选型时可以根据问题场景选择更合适的工具和语言。

结合 IM 具体应用场景，我们选择 Go 的原因包括：

• 1）运行性能：在性能上，尤其是针对网络通信等 IO 密集型应用场景。Go 系统的性能更接近 C/C++；
• 2）开发效率：Go 使用起来简单，代码编写效率高，上手也很快，尤其是对于有一定 C++ 基础的开发者，一周就能上手写代码了。

3.3、架构设计

整体架构图如下：