本文由马蜂窝技术团队电商交易基础平台研发工程师”Anti Walker”原创分享。
一、引言
即时通讯（IM）功能对于电商平台来说非常重要，特别是旅游电商。
从商品复杂性来看，一个旅游商品可能会包括用户在未来一段时间的衣、食、住、行等方方面面。从消费金额来看，往往单次消费额度较大。对目的地的陌生、在行程中可能的问题，这些因素使用户在购买前、中、后都存在和商家沟通的强烈需求。可以说，一个好用的 IM 可以在一定程度上对企业电商业务的 GMV 起到促进作用。
本文我们将结合马蜂窝旅游电商IM系统的发展历程，单独介绍基于Go重构分布式IM系统过程中的实践和总结（本文相当于《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》一文的进阶篇），希望可以给有相似问题的朋友一些借鉴。
另外：如果你对Go在高并发系统中的应用感兴趣，即时通讯网的以下两篇也值得一读：
《Go语言构建千万级在线的高并发消息推送系统实践(来自360公司)》
《12306抢票带来的启示：看我如何用Go实现百万QPS的秒杀系统(含源码)》
系列文章：
《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》
《从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结》
《从游击队到正规军(三)：基于Go的马蜂窝旅游网分布式IM系统技术实践》（* 本文）
关于马蜂窝旅游网：
名词解释：
1）客户：一般指购买商品的用户；
2）商家：提供服务的供应商，商家会有客服人员，提供给客户一个在线咨询的作用；
3）分发模块：即 Dispatcher，提供消息分发的给指定的工作模块的桥接作用；
4）工作模块：即 Worker 服务器，用来提供 WebSocket 服务，是真正工作的一个模块。
架构分层：
1）展示层：提供 HTTP 和 WebSocket 两种接入方式；
2）业务层：负责初始化消息线和业务逻辑处理。如果客户端以 HTTP 方式接入，会以 JSON 格式把消息发送给业务服务器进行消息解码、客服分配、敏感词过滤，然后下发到消息分发模块准备下一步的转换；通过 WebSocket 接入的业务则不需要消息分发，直接以 WebSocket 方式发送至消息处理模块中；
3）服务层：由消息分发和消息处理这两层组成，分别以分布式的方式部署多个 Dispatcher 和 Worker 节点。Dispatcher 负责检索出接收者所在的服务器位置，将消息以 RPC 的方式发送到合适的 Worker 上，再由消息处理模块通过 WebSocket 把消息推送给客户端；
4）数据层：Redis 集群，记录用户身份、连接信息、客户端平台（移动端、网页端、桌面端）等组成的唯一 Key。
4.4、服务流程
步骤一：
如上图右侧所示：
用户客户端与消息处理模块建立 WebSocket 长连接；
通过负载均衡算法，使客户端连接到合适的服务器（消息处理模块的某个 Worker）；
连接成功后，记录用户连接信息，包括用户角色（客人或商家）、客户端平台（移动端、网页端、桌面端）等组成唯一 Key，记录到 Redis 集群。
步骤二：
如图左侧所示，当购买商品的用户要给管家发消息的时候，先通过 HTTP 请求把消息发给业务服务器，业务服务端对消息进行业务逻辑处理。
1）该步骤本身是一个 HTTP 请求，所以可以接入各种不同开发语言的客户端。通过 JSON 格式把消息发送给业务服务器，业务服务器先把消息解码，然后拿到这个用户要发送给哪个商家的客服的。
2）如果这个购买者之前没有聊过天，则在业务服务器逻辑里需要有一个分配客服的过程，即建立购买者和商家的客服之间的连接关系。拿到这个客服的 ID，用来做业务消息下发；如果之前已经聊过天，则略过此环节。
3）在业务服务器，消息会异步入数据库。保证消息不会丢失。
步骤三：
业务服务端以 HTTP 请求把消息发送到消息分发模块。这里分发模块的作用是进行中转，最终使服务端的消息下发给指定的商家。
步骤四：
基于 Redis 集群中的用户连接信息，消息分发模块将消息转发到目标用户连接的 WebSocket 服务器（消息处理模块中的某一个 Worker）
1）分发模块通过 RPC 方式把消息转发到目标用户连接的 Worker，RPC 的方式性能更快，而且传输的数据也少，从而节约了服务器的成本。
2）消息透传 Worker 的时候，多种策略保障消息一定会下发到 Worker。
步骤五：
消息处理模块将消息通过 WebSocket 协议推送到客户端。
1）在投递的时候，接收者要有一个 ACK(应答) 信息来回馈给 Worker 服务器，告诉 Worker 服务器，下发的消息接收者已经收到了。
2）如果接收者没有发送这个 ACK 来告诉 Worker 服务器，Worker 服务器会在一定的时间内来重新把这个信息发送给消息接收者。
3）如果投递的信息已经发送给客户端，客户端也收到了，但是因为网络抖动，没有把 ACK 信息发送给服务器，那服务器会重复投递给客户端，这时候客户端就通过投递过来的消息 ID 来去重展示。
以上步骤的数据流转大致如图所示：
2）time.After：
在压测的时候，我们发现内存占用很高，于是使用 Go Tool PProf 分析 Golang 函数内存申请情况，发现有不断创建 time.After 定时器的问题，定位到是心跳协程里面。
原来代码如下：
优化点在于 for 循环里不要使用 select + time.After 的组合。
3）Map 的使用：
在保存连接信息的时候会用到 Map。因为之前做 TCP Socket 的项目的时候就遇到过一个坑，即 Map 在协程下是不安全的。当多个协程同时对一个 Map 进行读写时，会抛出致命错误：fetal error:concurrent map read and map write，有了这个经验后，我们这里用的是 sync.Map
4.6.2 踩坑经验
1）协程异常：
基于对开发成本和服务稳定性等问题的考虑，我们的 WebSocket 服务基于 Gorilla/WebSocket 框架开发。其中遇到一个问题，就是当读协程发生异常退出时，写协程并没有感知到，结果就是导致读协程已经退出但是写协程还在运行，直到触发异常之后才退出。
这样虽然从表面上看不影响业务逻辑，但是浪费后端资源。在编码时应该注意要在读协程退出后主动通知写协程，这样一个小的优化可以这在高并发下能节省很多资源。
2）心跳设计：
举个例子：之前我们在闲时心跳功能的开发中走了一些弯路。最初在服务器端的心跳发送是定时心跳，但后来在实际业务场景中使用时发现，设计成服务器读空闲时心跳更好。因为用户都在聊天呢，发一个心跳帧，浪费感情也浪费带宽资源。
这时候，建议大家在业务开发过程中如果代码写不下去就暂时不要写了，先结合业务需求用文字梳理下逻辑，可能会发现之后再进行会更顺利。
3）每天分割日志：
结论：
随着上行的并发变大，延迟控制在 24-66 毫秒之间。所以对于下行业务属于轻微延迟。另外针对 60 万 5k 上行的同时，用另一个脚本模拟开启 50 个协程并发下行 1k 的数据体，延迟是比没有并发下行的时候是有所提高的，延迟提高了 40ms 左右。
六、本文小结
基于 Go 重构的 IM 服务在 WebSocket 的基础上，将业务层设计为配有消息分发模块和消息处理模块的双层架构模式，使业务逻辑的处理前置，保证了即时通讯服务的纯粹性和稳定性；同时消息分发模块的 HTTP 服务方便多种编程语言快速对接，使各业务线能迅速接入即时通讯服务。
最后，我还想为 Go 摇旗呐喊一下。很多人都知道马蜂窝技术体系主要是基于 PHP，有一些核心业务也在向 Java 迁移。与此同时，Go 也在越来越多的项目中发挥作用。现在，云原生理念已经逐渐成为主流趋势之一，我们可以看到在很多构建云原生应用所需要的核心项目中，Go 都是主要的开发语言，比如 Kubernetes，Docker，Istio，ETCD，Prometheus 等，包括第三代开源分布式数据库 TiDB。
所以我们可以把 Go 称为云原生时代的母语。「云原生时代，是开发者最好的时代」，在这股浪潮下，我们越早走进 Go，就可能越早在这个新时代抢占关键赛道。希望更多小伙伴和我们一起，加入到 Go 的开发和学习阵营中来，拓宽自己的技能图谱，拥抱云原生。
附录：更多IM架构设计方面的文章
[1] 有关IM架构设计的文章：
《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
《移动端IM中大规模群消息的推送如何保证效率、实时性？》
《现代IM系统中聊天消息的同步和存储方案探讨》
《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
《WhatsApp技术实践分享：32人工程团队创造的技术神话》
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《王者荣耀2亿用户量的背后：产品定位、技术架构、网络方案等》
《IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《以微博类应用场景为例，总结海量社交系统的架构设计步骤》
《快速理解高性能HTTP服务端的负载均衡技术原理》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
《社交软件红包技术解密(七)：支付宝红包的海量高并发技术实践》
《社交软件红包技术解密(八)：全面解密微博红包技术方案》
《社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等》
《即时通讯新手入门：一文读懂什么是Nginx？它能否实现IM的负载均衡？》
《即时通讯新手入门：快速理解RPC技术——基本概念、原理和用途》
《多维度对比5款主流分布式MQ消息队列，妈妈再也不担心我的技术选型了》
《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》
《从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结》
《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
《瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）》
《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》
>> 更多同类文章 ……
[2] 更多其它架构设计相关文章：
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《快速理解高性能HTTP服务端的负载均衡技术原理》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
《达达O2O后台架构演进实践：从0到4000高并发请求背后的努力》
《优秀后端架构师必会知识：史上最全MySQL大表优化方案总结》
《小米技术分享：解密小米抢购系统千万高并发架构的演进和实践》
《一篇读懂分布式架构下的负载均衡技术：分类、原理、算法、常见方案等》
《通俗易懂：如何设计能支撑百万并发的数据库架构？》
《多维度对比5款主流分布式MQ消息队列，妈妈再也不担心我的技术选型了》
《从新手到架构师，一篇就够：从100到1000万高并发的架构演进之路》
《美团技术分享：深度解密美团的分布式ID生成算法》
《12306抢票带来的启示：看我如何用Go实现百万QPS的秒杀系统(含源码)》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-2909-1-1.html）