TCP接入层的负载均衡、高可用、扩展性架构
原创
58沈剑
架构师之路
今天和大家系统性聊聊TCP的负载均衡,高可用,与扩展性架构。
web-server的负载均衡,高可用,扩展性架构是怎么实施的?
互联网架构中,
web-server接入一般使用nginx来做反向代理
,实施负载均衡。整个架构分三层:
(1)上游调用层
,一般是browser或者APP;
(2)中间反向代理层
,nginx;
(3)下游真实接入集群
,web-server,常见web-server的有tomcat,apache;
那整个访问过程是怎么样的?
(1)browser向daojia.com发起请求;
(2)DNS将daojia.com解析为
外网IP
(1.2.3.4);
(3)browser通过外网IP(1.2.3.4)访问nginx;
(4)nginx实施负载均衡策略,常见策略有轮询,随机,IP-hash等;
(5)nginx将请求转发给
内网IP
(192.168.0.1)的web-server;
由于
http短连接,以及web应用无状态
的特性,理论上
任何一个http请求落在任意一台web-server都应该得到正常处理
。
画外音:如果必须落在一台,说明架构可能不合理,难以水平扩展。
问题来了,
tcp是有状态的连接
,客户端和服务端一旦建立连接,
一个client发起的请求必须落在同一台tcp-server上
,此时如何做负载均衡,如何保证水平扩展呢?
方案一:单机法tcp-server
单个tcp-server显然是可以保证请求一致性:
(1)client向tcp.daojia.com发起tcp请求;
(2)DNS将
tcp.daojia.com
解析为外网IP(1.2.3.4);
(3)client通过外网IP(1.2.3.4)向tcp-server发起请求;
这个方案有什么缺点?
无法保证高可用。
方案二:集群法tcp-server
可以通过搭建tcp-server集群来保证高可用
,
客户端来实现负载均衡
:
(1)client内配置有tcp1/tcp2/tcp3.daojia.com三个tcp-server的外网IP;
(2)客户端通过“随机”的方式选择tcp-server,假设选择到的是tcp1.daojia.com;
(3)通过DNS解析tcp1.daojia.com;
(4)通过外网IP连接真实的tcp-server;
如何保证高可用呢?
如果client发现某个tcp-server连接不上,则选择另一个。
这个方案有什么缺点?
每次连接前,需要多实施一次DNS访问:
(1)难以预防DNS劫持;
(2)多一次DNS访问意味着
更长的连接时间
,这个不足在手机端更为明显;
如何解决DNS的问题?
直接将IP配置在客户端,可以解决上述两个问题,很多公司也就是这么做的,
俗称“
IP直通车
”。
“IP直通车”有什么新问题?
将IP写死在客户端,在客户端实施负载均衡,
扩展性很差
:
(1)如果原有IP发生变化
,客户端得不到实时通知;
(2)如果新增IP
,即tcp-sever扩容,客户端也得不到实时通知;
(3)如果负载均衡策略变化
,需要升级客户端;
方案三:服务端实施负载均衡
只有将复杂的策略下沉到服务端,才能根本上解决扩展性的问题
。
增加一个http接口,将客户端的“IP配置”与“均衡策略”放到服务端
是一个不错的方案:
(1)client每次访问tcp-server前,先调用一个
新增的get-tcp-ip接口
,对于client而言,
这个http接口只返回一个tcp-server的IP;
(2)这个http接口,实现的是原client的IP均衡策略;
(3)拿到tcp-server的IP后,和原来一样向tcp-server发起TCP长连接;
这样的话,扩展性问题就解决了:
(1)如果原有IP发生变化,只需要修改get-tcp-ip接口的配置;
(2)如果新增IP,也是修改get-tcp-ip接口的配置;
(3)如果负载均衡策略变化,不需要升级客户端;
然而,
新的问题
又产生了,如果所有IP放在客户端,当有一个IP挂掉的时候,client可以再换一个IP连接,保证可用性,而get-tcp-ip接口只是维护静态的tcp-server集群IP,对于这些
IP对应的tcp-server是否可用
,是完全不知情的,怎么办呢?
方案四:tcp-server状态上报
get-tcp-ip接口怎么知道tcp-server集群中各台服务器是否可用呢,
tcp-server主动上报是一个潜在方案
,如果某一个tcp-server挂了,则会终止上报,对于停止上报状态的tcp-server,get-tcp-ip接口,将不返回给client相应的tcp-server的外网IP。
该设计的存在的问题?
诚然,状态上报解决了tcp-server高可用的问题,但这个设计犯了一个
“反向依赖”的耦合小错误
:使得tcp-server要依赖于一个与本身业务无关的web-server。
方案五:tcp-server状态拉取
更优的方案
是:
web-server通过“拉”的方式获取各个tcp-server的状态
,而不是tcp-server通过“推”的方式上报自己的状态。
这样的话,
每个tcp-server都独立与解耦
,只需专注于资深的tcp业务功能即可。
高可用、负载均衡、扩展性
等任务
由get-tcp-ip的web-server专注来执行
。
多说一句,
将负载均衡实现在服务端
,还有一个
好处
,可以实现
异构tcp-server的负载均衡
,以及
过载保护
:
(1)静态实施
:web-server下的多个tcp-server的IP可以配置负载权重,根据tcp-server的机器配置分配负载(nginx也有类似的功能);
(2)动态实施
:web-server可以根据“拉”回来的tcp-server的状态,动态分配负载,并在tcp-server性能急剧下降时实施过载保护;
总结
web-server如何实施负载均衡?
利用nginx反向代理来轮询、随机、ip-hash。
tcp-server怎么快速保证请求一致性?
单机。
如何保证高可用?
客户配置多个tcp-server的域名。
如何防止DNS劫持,以及加速?
IP直通车,客户端配置多个tcp-server的IP。
如何保证扩展性?
服务端提供get-tcp-ip接口
,向client屏屏蔽负载均衡策略,并实施便捷扩容。
如何保证高可用?
tcp-server“推”
状态给get-tcp-ip接口,
or
get-tcp-ip接口“拉”
tcp-server状态。
细节重要,
思路比细节更重要
。
系统性了解架构,希望大家有收获,
谢转
。
预览时标签不可点
阅读原文
修改于
微信扫一扫
关注该公众号
继续滑动看下一个
轻触阅读原文
架构师之路
向上滑动看下一个
知道了
微信扫一扫
使用小程序
取消
允许
取消
允许
×
分析
微信扫一扫可打开此内容,
使用完整服务
:
,
,
,
,
,
,
,
,
,
,
,
,
。
视频
小程序
赞
,轻点两下取消赞
在看
,轻点两下取消在看
分享
留言
收藏
听过