IM序列8:基于集群的移动端IM接入层负载均衡方案分享

Posted 编码前线

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了IM序列8:基于集群的移动端IM接入层负载均衡方案分享相关的知识,希望对你有一定的参考价值。

1、前言


要开发一个真正能用于生产环境的移动端IM系统,难度还是比较大的,因为移动端IM系统是多种技术手段的综合应用:包括移动端网络编程、通信安全、高性能互联网架构等等,尤其在当下IM技术相对封闭、实践资料并不容易找到的情况下。


本文将以基于TCP数据传输协议的移动端IM为例,通过循序渐进地方式,分享如何构建一个基于分布式集群的移动端IM接入层的设计和实现。

2、IM开发干货系列文章

《IM消息送达保证机制实现(一):保证在线实时消息的可靠投递》

《IM消息送达保证机制实现(二):保证离线消息的可靠投递》

《如何保证IM实时消息的“时序性”与“一致性”?》

《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?》

《IM群聊消息如此复杂,如何保证不丢不重?》

《一种android端IM智能心跳算法的设计与实现探讨(含样例代码)》

《移动端IM登录时拉取数据如何作到省流量?》

《通俗易懂:基于集群的移动端IM接入层负载均衡方案分享》(本文)

《浅谈移动端IM的多点登陆和消息漫游原理》


3、Web短连接与基于TCP长连接的负载均衡系统各自的特点



互联网架构中,web-server接入一般使用nginx来做反向代理,实施负载均衡。整个架构分三层:


上游调用层:一般是browser或者APP;

中间反向代理层:nginx;

下游真实接入集群:web-server,常见web-server的有tomcat,apache。


整个访问过程为:


browser向daojia.com发起请求;

DNS服务器将daojia.com解析为外网IP(1.2.3.4);

browser通过外网IP(1.2.3.4)访问nginx;

nginx实施负载均衡策略,常见策略有轮询,随机,IP-hash等;

nginx将请求转发给内网IP(192.168.0.1)的web-server。


由于http短连接,以及web应用无状态的特性,理论上任何一个http请求落在任意一台web-server都应该得到正常处理(如果必须落在一台,说明架构不合理,不能水平扩展)。


但与传统的Web系统不同的是:基于tcp长连接的IM系统中,每条长连接通路都是有状态的,客户端和服务端一旦建立连接,一个client发起的请求必须落在同一台tcp-im-server上。那么此时该如何做负载均衡,如何保证水平扩展呢?我们继续往下看。

4、单机场景下的tcp-im-server


IM序列8:基于集群的移动端IM接入层负载均衡方案分享


单机tcp-im-server显然是很容易保证请求一致性的:


client向tcp.daojia.com发起tcp请求;

DNS服务器将tcp.daojia.com解析为外网IP(1.2.3.4);

client通过外网IP(1.2.3.4)向tcp-im-server发起请求。


方案的缺点呢?那就是无法保证高可用。

5、一个典型的基于集群的tcp-im-server方案及其缺点


IM序列8:基于集群的移动端IM接入层负载均衡方案分享


通过搭建tcp-im-server集群来保证高可用,客户端来实现负载均衡:


client内配置有tcp1/tcp2/tcp3.mydomain.com三个tcp-im-server的外网IP;

客户端通过“随机”的方式选择tcp-im-server,假设选择到的是tcp1.mydomain.com;

通过DNS解析tcp1.mydomain.com;

通过外网IP连接真实的tcp-im-server。


那如何保证高可用呢?

如果client发现某个tcp-im-server连接不上,则选择另一个。


潜在的缺点?

每次连接前,需要多实施一次DNS访问:

难以预防DNS劫持;

多一次DNS访问意味着更长的连接时间,这个不足在手机端更为明显。


如何解决DNS的问题?

直接将IP配置在客户端,可以解决上述两个问题,很多公司也就是这么做的(俗称“IP直通车”)。


“IP直通车”有什么新问题?

将IP写死在客户端,在客户端实施负载均衡,扩展性很差:

如果原有IP发生变化,客户端得不到实时通知;

如果新增IP,即tcp-sever扩容,客户端也得不到实时通知;

如果负载均衡策略变化,需要升级客户端。


6、优化1:把负载均衡策略放到服务端做


只有将复杂的策略下沉到服务端,才能根本上解决扩展性的问题。

IM序列8:基于集群的移动端IM接入层负载均衡方案分享


增加一个http接口,将客户端的“IP配置”与“均衡策略”放到服务端是一个不错的方案:


client每次访问tcp-im-server前,先调用一个新增的get-tcp-ip接口,对于client而言,这个http接口只返回一个tcp-im-server的IP;

这个http接口,实现的是原client的IP均衡策略;

拿到tcp-im-server的IP后,和原来一样向tcp-im-server发起TCP长连接。


这样的话,扩展性问题就解决了:


如果原有IP发生变化,只需要修改get-tcp-ip接口的配置;

如果新增IP,也是修改get-tcp-ip接口的配置;

如果负载均衡策略变化,需要升级客户端。


然而,新的问题又产生了,如果所有IP放在客户端,当有一个IP挂掉的时候,client可以再换一个IP连接,保证可用性,而get-tcp-ip接口只是维护静态的tcp-im-server集群IP,对于这些IP对应的tcp-im-server是否可用,是完全不知情的,怎么办呢?

7、优化2:改为由tcp-im-servert主动上报状态



get-tcp-ip接口怎么知道tcp-im-server集群中各台服务器是否可用呢,tcp-im-server主动上报是一个潜在方案,如果某一个tcp-im-server挂了,则会终止上报,对于停止上报状态的tcp-im-server,get-tcp-ip接口,将不返回给client相应的tcp-im-server的外网IP。


该设计的存在的问题?

诚然,状态上报解决了tcp-im-server高可用的问题,但这个设计犯了一个“反向依赖”的耦合小错误:使得tcp-im-server要依赖于一个与本身业务无关的web-server。

8、优化3:改为主动拉取tcp-im-server的状态


 


更优的方案是:web-server通过“拉”的方式获取各个tcp-im-server的状态,而不是tcp-im-server通过“推”的方式上报自己的状态。


这样的话,每个tcp-im-server都独立与解耦,只需专注于资深的tcp业务功能即可。


高可用、负载均衡、扩展性等任务由get-tcp-ip的web-server专注来执行。


多说一句,将负载均衡实现在服务端,还有一个好处,可以实现异构tcp-im-server的负载均衡,以及过载保护:


静态实施:web-server下的多个tcp-im-server的IP可以配置负载权重,根据tcp-im-server的机器配置分配负载(nginx也有类似的功能);

动态实施:web-server可以根据“拉”回来的tcp-im-server的状态,动态分配负载,并在tcp-im-server性能极具下降时实施过载保护。


9、本文小结


web-server如何实施负载均衡?

利用nginx反向代理来轮询、随机、ip-hash。


tcp-im-server怎么快速保证请求一致性?

单机。


如何保证高可用?

客户配置多个tcp-im-server的域名。


如何防止DNS劫持,以及加速?

IP直通车,客户端配置多个tcp-im-server的IP。


如何保证扩展性?

服务端提供get-tcp-ip接口,向client屏屏蔽负载均衡策略,并实施便捷扩容。


如何保证高可用?

tcp-im-server“推”状态给get-tcp-ip接口,或者 get-tcp-ip接口“拉”tcp-im-server状态。


以上是关于IM序列8:基于集群的移动端IM接入层负载均衡方案分享的主要内容,如果未能解决你的问题,请参考以下文章

即时通讯开发框架Nginx能否实现IM的负载均衡?

企业级负载均衡解决方案之二:美团点评四层负载均衡解决方案MGW

基于lvs实现4层负载均衡

企业实战(22)基于Haproxy负载均衡+Keepalived高可用集群实战详解

Nginx七层负载均衡 #yyds干货盘点#

接入层控制:nginx动态流量路由和负载均衡