本文由探探服务端高级技术专家张凯宏分享，原题“探探长链接我的项目的Go语言实际”，因原文内容有较多谬误，有订正和改变。

1、引言

即时通信长连贯服务处于网络接入层，这个畛域非常适合用Go语言施展其多协程并行、异步IO的特点。

探探自长连贯我的项目上线当前，对服务进行了屡次优化：GC从5ms降到100微秒（Go版本均为1.9以上），次要gRPC接口调用延时p999从300ms降落到5ms。在业内大多把眼光聚焦于单机连接数的时候，咱们则更聚焦于服务的SLA（服务可用性）。

本文将要分享的是陌生人社交利用探探的IM长连贯模块从技术选型到架构设计，再到性能优化的整个技术实际过程和经验总结。

学习交换：

  • 即时通讯/推送技术开发交换5群：215477170 [举荐]
  • 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》
  • 开源IM框架源码：https://github.com/JackJiang2...

（本文已同步公布于：http://www.52im.net/thread-37...）

2、对于作者

张凯宏：负责探探服务端高级技术专家。

6年Go语言开发教训，曾用Go语言构建多个大型Web我的项目，其中波及网络库、存储服务、长连贯服务等。专一于Go语言实际、存储服务研发及大数据场景下的Go语言深度优化。

3、我的项目缘起

咱们这个我的项目是2018年下半年开始，据明天大略1年半工夫。

过后探探遇到一些技术痛点，最重大的就是重大依赖第三方Push，比如说第三方有一些故障的话，对实时IM聊天的KPS有比拟大的影响。

过后通过push推送音讯，利用内的push延时比拟高，均匀延时五六百毫秒，这个工夫咱们不能承受。

而且也没有一个 Ping Pland 机制（心跳查看机制？），无奈晓得用户是否在线。

过后产品和技术同学都感觉是机会搞一个长连贯了。

4、一个小插曲

我的项目大略继续了一个季度工夫，首先是拿IM业务落地，咱们感觉长连贯跟IM绑定比拟严密一些。

IM落地之后，后续长连贯上线之后，各个业务比拟依赖于长连贯服务。

这两头有一个小插曲，次要是取名字那一块。

我的项目之初给我的项目起名字叫Socket，看到socket比拟亲切，感觉它就是一个长连贯，这个感觉比拟莫名，不晓得为什么。但运维提出了异议，感觉UDP也是Socket，我感觉UDP其实也能够做长连贯。

运维提议叫Keepcom，这个是出自于Keep Alive实现的，这个提议还是挺不错的，最初咱们也是用了这个名字。

客户端给的倡议是Longlink，另外一个是Longconn，一个是IOS端技术共事取的、一个是安卓端技术共事取的。

最初咱们都败了，运维同学胜了，运维同学感觉，如果名字定不下来就别上线的，最初咱们斗争了。

5、为什么要做长连贯？

为什么做长连贯？

如上图所示：看一下比照挺显著，右边是长连贯，左边是短长连贯。

对于长连贯来说，不须要从新进入连贯，或者是开释连贯，一个X包只须要一个RTT就完事。左边对于一个短连贯须要三次握手发送一个push包，最初做挥手。

论断：如果发送N条音讯的数据包，对于长连贯是2+N次的RTT，对于短连贯是3N次RTT，最初开启Keep Alive，N是连贯的个数。

6、长连贯技术劣势

咱们决结了一下，长连贯有以下四大劣势：

1）实时性：长连贯是双向的通道，对音讯的推送也是比拟实时；
2）有状态：长连贯自身保护用户的状态，通过KeepAlive形式，确定用户是否在线；
3）省流程：长连贯比拟省流量，能够做一些用户自定义的数据压缩，自身也能够省不少的归属包和连贯包，所以说比拟省流量；
4）更省电：缩小网络流量之后，可能进一步升高挪动客户端的耗电。

7、TCP在挪动端能胜任吗？

在我的项目开始之前，咱们做了比拟多的考量。

首先咱们看一下对于挪动端的长连贯来说，TCP协定是不是可能Work？

对于传统的长连贯来说，Web端的长连贯TCP能够胜任，在挪动端来说TCP是否胜任？这取决于TCP的几个个性。

首先TCP有慢启动和滑动窗口的个性，TCP通过这种形式管制PU包，防止网络阻塞。

TCP连贯之后走一个慢启动流程，这个流程从初始窗大小做2个N次方的扩张，最初到肯定的域值，比方域值是16包，从16包开始逐渐往上递增，最初到24个数据包，这样达到窗口最大值。

一旦遇到丢包的状况，当然两种状况。一种是疾速重传，窗口简略了，相当于是12个包的窗口。如果启动一个RTO相似于状态连贯，窗口一上涨到初始的窗口大小。

如果启动RTO重传的话，对于后续包的阻塞蛮重大，一个包阻塞其余包的发送。


（▲ 上图援用自《迈向高阶：优良Android程序员必知必会的网络根底》）

无关TCP协定的基础知识，能够读读以下材料：

《TCP/IP详解 - 第17章·TCP：传输控制协议》
《TCP/IP详解 - 第18章·TCP连贯的建设与终止》
《TCP/IP详解 - 第21章·TCP的超时与重传》
《通俗易懂-深刻了解TCP协定（上）：实践根底》
《通俗易懂-深刻了解TCP协定（下）：RTT、滑动窗口、拥塞解决》
《网络编程懒人入门(一)：疾速了解网络通信协定（上篇）》
《网络编程懒人入门(二)：疾速了解网络通信协定（下篇）》
《网络编程懒人入门(三)：疾速了解TCP协定一篇就够》
《脑残式网络编程入门(一)：跟着动画来学TCP三次握手和四次挥手》
《网络编程入门从未如此简略(二)：如果你来设计TCP协定，会怎么做？》

8、TCP还是UDP？

（▲ 上图援用自《挪动端IM/推送零碎的协定选型：UDP还是TCP？》）

TCP实现长连贯的四个问题:

1）挪动端的音讯量还是比拟稠密，用户每次拿到手机之后，发的音讯总数比拟少，每条音讯的距离比拟长。这种状况下TCP的间连和放弃长链接的劣势比拟显著一些；
2）弱网条件下丢包率比拟高，丢包后Block后续数据发送容易阻塞；
3）TCP连贯超时工夫过长，默认1秒钟，这个因为TCP诞生的年代比拟早，那会儿网络状态没有当初好，过后定是1s的超时，当初能够设的更短一点；
4）在没有疾速重传的状况下，RTO重传等待时间较长，默认15分钟，每次是N次方的递加。

为何最终还是抉择TCP呢？因为咱们感觉UDP更重大一点。

首先UDP没有滑动窗口，无流量管制，也没有慢启动的过程，很容易导致丢包，也很容易导致在网络中间状态下丢包和超时。

UDP一旦丢包之后没有重传机制的，所以咱们须要在应用层去实现一个重传机制，这个开发量不是那么大，然而我感觉因为比拟偏底层，容易出故障，所以最终抉择了TCP。

TCP还是UDP？这始终是个比拟有争议的话题：

《网络编程懒人入门(四)：疾速了解TCP和UDP的差别》
《网络编程懒人入门(五)：疾速了解为什么说UDP有时比TCP更有劣势》
《5G时代曾经到来，TCP/IP老矣，尚能饭否？》
《Android程序员必知必会的网络通信传输层协定——UDP和TCP》
《鲜为人知的网络编程(六)：深刻地了解UDP协定并用好它》
《鲜为人知的网络编程(七)：如何让不牢靠的UDP变的牢靠？》

如果你对UDP协定还不理解，能够读读这篇：《TCP/IP详解 - 第11章·UDP：用户数据报协定》。

9、抉择TCP的更多理由

咱们列举一下，次要有这3点：

1）目前在挪动端、安卓、IOS来说，初始窗口大小比拟大默认是10，综合TCP慢启动的劣势来看；
2）在一般的文本传输状况下，对于丢包的重大不是很敏感（并不是说传多媒体的数据流，只是传一些文本数据，这一块对于丢包的副作用TCP不是特地重大）；
3）咱们感觉TCP在应用层用的比拟多。

对于第“3）”点，这里有以下三个考量点。

第一个考量点：

根本当初应用程序走HTP协定或者是push形式根本都是TCP，咱们感觉TCP个别不会出大的问题。

一旦摈弃TCP用UDP或者是QUIC协定的话，保不齐会呈现比拟大的问题，短时间解决不了，所以最终用了TCP。

第二个考量点：

咱们的服务在根底层上用哪种形式做LB，过后有两种抉择，一种是传统的LVS，另一种是HttpDNS（对于HttpDNS请见《全面理解挪动端DNS域名劫持等杂症：原理、本源、HttpDNS解决方案等》）。

最初咱们抉择了HttpDNS，首先咱们还是须要跨机房的LB反对，这一点HttpDNS齐全胜出。其次，如果须要跨网端的话，LVS做不到，须要其余的部署形式。再者，在扩容方面，LVS算是稍逊一筹。最初，对于个别的LB算法，LVS反对并不好，须要依据用户ID的LB算法，另外须要一致性哈希的LB算法，还须要依据地理位置的定位信息，在这些方面HttpDNS都可能完满的胜出，然而LVS都做不到。

第三个考量点：

咱们在做TCP的饱和机制时通过什么样的形式？Ping包的形式，间隔时间怎么确定，Ping包的工夫细节怎么样确定？

过后比拟纠结是客户端被动发ping还是服务端被动发Ping？

对于客户端保活的机制反对更好一些，因为客户端可能会被唤醒，然而客户端进入后盾之后可能发不了包。

其次：APP前后台对于不同的Ping包距离来保活，因为在后盾自身处于一种弱在线的状态，并不需要去频繁的发Ping包确定在线状态。

所以：在后盾的Ping包的工夫距离能够长一些，前端能够短一些。

再者：须要Ping指数增长的距离反对，在故障的时候还是比拟救命的。

比如说：服务端一旦故障之后，客户端如果拼命Ping的话，可能把服务端彻底搞瘫痪了。如果有一个指数级增长的Ping包距离，根本服务端还能缓一缓，这个在故障时比拟重要。

最初：Ping包重试是否须要Backoff，Ping包从新发Ping，如果没有收到Bang包的话，须要等到Backoff发Ping。

10、动静Ping包工夫距离算法

PS：在IM里这其实有个更业余的叫法——“智能心跳算法”。

咱们还设计了一个动静的Ping包工夫距离算法。

因为国内的网络运营商对于NIT设施有一个保活机制，目前根本在5分钟以上，5分钟如果不发包的话，会把你的缓存给删掉。基本上各运营商都在5分钟以上，只不过挪动4G妨碍了。根本能够在4到10分钟之内发一个Ping包就行，能够维持网络运营商设施里的缓存，始终放弃着，这样就没有问题，使长连贯始终保活着。

减少Ping包距离能够缩小网络流量，可能进一步升高客户端的耗电，这一块的受害还是比拟大的。

在低端安卓设施的状况下，有一些DHCP租期的问题。这个问题集中在安卓端的低版本上，安卓不会去续租过期的IP。

解决问题也比较简单，在DHCP租期到一半的时候，去及时向DHCP服务器续租一下就能解决了。

限于篇幅，我就不在这里开展了，有趣味能够读这些材料：

《为何基于TCP协定的挪动端IM依然须要心跳保活机制？》
《一文读懂即时通讯利用中的网络心跳包机制：作用、原理、实现思路等》
《微信团队原创分享：Android版微信后盾保活实战分享(网络保活篇)》
《挪动端IM实际：实现Android版微信的智能心跳机制》
《挪动端IM实际：WhatsApp、Line、微信的心跳策略剖析》
《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》
《手把手教你用Netty实现网络通信程序的心跳机制、断线重连机制》

11、服务架构

11.1 根本介绍
服务架构比较简单，大略是四个模块：

1）首先是HttpDNS；
2）另一个是Connector接入层，接入层提供IP，
3）而后是Router，相似于代理转发音讯，依据IP抉择接入层的服务器，最初推到用户；
4）最初还有认证的模块Account，咱们目前只是探探APP，这个在用户核心实现。

11.2 部署
部署上相当于三个模块：

1）一个是Dispatcher；
2）一个是Redis；
3）一个是Cluser。

如下图所示：客户端在连贯的时候：

1）须要拿到一个协定；
2）第二步通过HttpDNS拿到ConnectorIP；
3）通过IP连长连贯，下一步发送Auth音讯认证；
4）连贯胜利，前面发送Ping包保活；
5）之后断开连接。

11.3 音讯转发流程
音讯转发的流程分为两个局部。

首先是音讯上行：服务端发动一个音讯包，通过Connector接入服务，客户端通过Connector发送音讯，再通过Connector把音讯发到微服务上，如果不须要微服务的话间接去转发到Vetor就行的，这种状况下Connector更像一个Gateway。

对于上行：业务方都须要申请Router，找到具体的Connector，依据Connector部署音讯。

各个公司都是微服务的架构，长连贯跟微服务的交互根本两块。一块是音讯上行时，更像是Gateway，上行通过Router接入，通过Connector发送音讯。

11.4 一些实现细节
上面是一些是细节，咱们用了GO语言1.13.4，内部消息传输上是gRPC，传输协定是Http2，咱们在外部通过ETCD做LB的形式，提供服务注册和发现的服务。

如下图所示：Connector就是状态，它从用户ID到连贯的一个状态信息。

咱们看下图的左边：它其实是存在一个比拟大的MAP，为了避免MAP的锁竞争过于重大，把MAP拆到2到56个子MAP，通过这种形式去实现高读写的MAP。对于每一个MAP从一个ID到连贯状态的映射关系，每一个连贯是一个Go Ping，实现细节读写是4KB，这个没改过。

咱们看一下Router：它是一个无状态的CommonGRPC服务，它比拟容易扩容，当初状态信息都存在Redis外面，Redis大略一组一层，目前峰值是3000。

咱们有两个状态：一个是Connector，一个是Router。

首先以Connector状态为主，Router是状态统一的保障。

这个外面分为两种状况：如果连贯在同一个Connector上的话，Connector须要保障向Router复制的程序是正确的，如果程序不统一，会导致Router和Connector状态不统一。通过对立Connector的窗口实现音讯一致性，如果跨Connector的话，通过在Redis Lua脚本实现Compare And Update形式，去保障只有本人Connector写的状态能力被本人更新，如果是别的Connector的话，更新不了其他人的信念。咱们保障跨Connector和同一Connector都可能去依照程序通过统一的形式更新Router外面连贯的状态。

Dispatche比较简单：是一个纯正的Common Http API服务，它提供Http API，目前延时比拟低大略20微秒，4个CPU就能够撑持10万个并发。

目前通过无单点的构造实现一个高可用：首先是Http DNS和Router，这两个是无障碍的服务，只须要通过LB保障。对于Connector来说，通过Http DNS的客户端被动漂移实现连贯层的Ordfrev，通过这种形式保障一旦一个Connector出问题了，客户端能够立马漂到下一个Connector，去实现主动的工作转移，目前是没有单点的。

12、性能优化

12.1 根本状况
后续有优化次要有以下几个方面：

1）网络优化：这一块拉着客户端一起做，首先客户端须要重传包的时候发三个嗅探包，通过这种形式做一个疾速重传的机制，通过这种机制进步疾速重传的比例；
2）心跳优化：通过动静的Ping包间隔时间，缩小Ping包的数量，这个还在开发中；
3）避免劫持：是通过客户端应用IP直连形式，回避域名劫持的操作；
4）DNS优化：是通过HttpDNS每次返回多个IP的形式，来申请客户端的HttpDNS。
12.2 网络优化
对于接入层来说，其实Connector的连接数比拟多，并且Connector的负载也是比拟高。

咱们对于Connector做了比拟大的优化，首先看Connector最早的GC工夫到了4、5毫秒，惨不忍睹的。

咱们看一下上面这张图（图上）是优化后的后果，大略均匀100微秒，这算是比拟好。第二张图（图下）是第二次优化的后果，大略是29微秒，第三张图大略是20几微秒。

12.3 音讯提早
看一下音讯提早，探探对im音讯的提早要求比拟高，特地重视用户的体验。

这一块刚开始大略到200ms，如果对于一个操作的话，200ms还是比较严重的。

第一次优化之后（下图-上）的状态大略1点几毫秒，第二次优化之后（下图-下）当初降到最低点差不多100微秒，跟个别的Net操作工夫维度上比拟靠近。

12.4 Connector优化过程
优化过程是这样的：

1）首先须要要害门路上的Info日志，通过采样实现Access Log，info日志是接入层比拟重的操作；
2）第二通过Sync.Poll缓存对象；
3）第三通过Escape Analysis对象尽可能在线上调配。
前面还实现了Connector的无损发版：这一块比拟有价值。长连贯刚上线发版比拟多，每次发版对于用户来说都有感，通过这种形式让用户尽量无感。

实现了Connector的Graceful Shutdown的形式，通过这种形式优化连贯。

首先：在HttpDNS高低线该机器，下线之后迟缓断开用户连贯，直到连接数小于肯定阈值。前面是重启服务，发版二进制。

最初：是HttpDNS上线该机器，通过这种形式实现用户发版，工夫比拟长，过后测了挺长时间，去掂量每秒钟断开多少个连贯，最初阈值是多少。

前面是一些数据：方才GC也是一部分，目前连接数都属于比拟要害的数据。首先看连接数单机连接数比拟少，不敢放太开，最多是15万的单机连接数，大概100微秒。

Goroutine数量跟连接数一样，差不多15万个：

看一下内存应用状态，下图(上)是GO的内存总量，大略是2：3，剩下五分之一是属于未占用，内存总量是7.3个G。

下图是GC状态，GC比拟衰弱，红线是GC每次沉闷内存数，红线远远高于绿线。

看到GC目前的情况大略是20几微秒，感觉目前跟GO的官网工夫比拟能对得上，咱们感觉GC目前都曾经优化到位了。

12.5 后续要做的优化
最初是布局后续还要做优化。

首先：对系统上还是须要更多优化Connector层，更多去缩小内存的调配，尽量把内存调配到堆上而不是站上，通过这种形式缩小GC压力，咱们看到GO是非Generational Collection GE，堆的内存越多的话，扫的内存也会越多，这样它不是一个线性的增长。

第二：在外部更多去用Sync Pool做短暂的内存调配，比如说Context或者是长期的Dbyle。

协定也要做优化：目前用的是WebSocket协定，前面会加一些性能标记，把一些重要信息传给服务端。比如说一些重传标记，如果客户端退出重传标记的话，咱们能够先校验这个包是不是重传包，如果是重传包的话会去判断这个包是不是反复，是不是之前发过，如果发过的话就不须要去解包，这样能够少做很多的服务端操作。

另外：能够去把Websocket目前的Mask机制去掉，因为Mask机制避免Web端的改包操作，然而根本是客户端的传包，所以并不需要Mask机制。

业务上：目前布局前面须要做比拟多的事件。咱们感觉长连贯因为是一个接入层，是一个十分好的中央去统计一些客户端的散布。比如说客户端的安卓、IOS的散布情况。

进一步：能够做用户画像的统计，男的女的，年龄是多少，地理位置是多少。大略是这些，谢谢！

13、热门问题回复

  • 发问：方才说连贯层对话重启，间接的过程中那些断掉的用户就飘到其余的，是这样做的吗？

张凯宏：目前是这样的，客户端做主动飘移。

  • 发问：当初是1千万日活，如果服务端往客户端一下推100万，这种场景怎么做的？

张凯宏：目前咱们没有那么大的音讯推送量，有时候会发一些业务相干的推送，目前做了一个限流，通过客户端限流实现的，大略三四千。

  • 发问：如果做到后端，意味着会存在安全隐患，攻击者会不停的建设连贯，导致很难去做进攻，会有这个问题吗？因为歹意的攻打，如果攻打的话建设连贯就能够了，不须要认证的机制。

张凯宏：明确你的意思，这一块不只是长连贯，短连贯也有这个问题。客户端始终在伪造拜访后果，流量还是比拟大的，这一块靠防火墙和IP层防火墙实现。

  • 发问：长连贯服务器是挂在最外方，两头有没有一层？

张凯宏：目前接着如上层间接裸露在外网层，后面过一层IP的防DNSFre的防火墙。除此之外没有别的网络设备了。

  • 发问：基于什么样的思考两头没有加一层，因为后面还加了一层的状况。

张凯宏：目前没有这个打算，前面会在Websofte接入层后面加个LS层能够不便扩容，这个收益不是特地大，所以当初没有去打算。

  • 发问：刚刚说的断开重传的三次嗅探那个是什么意思？

张凯宏：咱们想更多的去触发疾速重传，这样对于TCP的重传距离更短一些，服务端依据三个循环包判断是否疾速重传，咱们会发三个循环包防止一个RTO重传的开启。

  • 发问：探探最开始安卓服务器是应用第三方的吗？

张凯宏：对的，刚开始是极光推送的。

  • 发问：从第三方的安卓服务器到自研。

张凯宏：如果极光有一些故障的话，对咱们影响还是蛮大。之前极光的故障频率挺高，咱们想是不是本人能把服务做起来。第二点，极光自身能提供一个用户是否在线的判断，然而它那个判断要走通道，延时比拟高，自身判断是连贯把延时升高一些。

  • 发问：比如说一个新用户上线连贯过去，有一些用户发给他音讯，他是怎么把一线音讯拿到的？

张凯宏：咱们通过业务端保障的，未收回来的音讯会存一个ID号，当用户从新连的时候，业务端再拉一下。

14、参考资料

[1] 挪动端IM/推送零碎的协定选型：UDP还是TCP？
[2] 5G时代曾经到来，TCP/IP老矣，尚能饭否？
[3] 为何基于TCP协定的挪动端IM依然须要心跳保活机制？
[4] 一文读懂即时通讯利用中的网络心跳包机制：作用、原理、实现思路等
[5] 微信团队原创分享：Android版微信后盾保活实战分享(网络保活篇)
[6] 挪动端IM实际：实现Android版微信的智能心跳机制
[7] 迈向高阶：优良Android程序员必知必会的网络根底
[8] 全面理解挪动端DNS域名劫持等杂症：原理、本源、HttpDNS解决方案等
[9] 技术扫盲：新一代基于UDP的低延时网络传输层协定——QUIC详解
[10] 新手入门一篇就够：从零开发挪动端IM
[11] 长连贯网关技术专题(二)：知乎千万级并发的高性能长连贯网关技术实际
[12] 长连贯网关技术专题(三)：手淘亿级挪动端接入层网关的技术演进之路
[13] 长连贯网关技术专题(五)：喜马拉雅自研亿级API网关技术实际
[14] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等
[15] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等
[16] 从老手到专家：如何设计一套亿级音讯量的分布式IM零碎

本文已同步公布于“即时通讯技术圈”公众号。
同步公布链接是：http://www.52im.net/thread-37...