转载

故障转移,服务发现,负载均衡,居然都和它有关!!!

没错,说的就是连接池,玩互联网架构,连接池是必须要掌握的。

什么是连接池?

创建与管理连接缓冲池的技术,本质是资源复用,不用频繁创建与销毁连接,能提高性能。

画外音:数据库连接池,服务连接池,都是连接池。

微服务分层架构中,连接池扮演着极其重要的角色。

故障转移,服务发现,负载均衡,居然都和它有关!!!

如上图:

(1) 上层虚线框 ,是web集群;

(2) 下层虚线框 ,是service集群;

(3) 绿色框 ,代表一条上下游建立的连接;

(4) 蓝色框 ,代表连接池;

此例中,一个调用方会与一个服务节点建立2条连接,服务集群共3个集群,故连接池总共6条连接,从c1到c6。

上层调用方,除了会从连接池中拿连接收发报文访问下游服务外,互联网架构中, 还有哪些技术点 与连接池相关呢?

一、故障转移与服务发现

故障转移,服务发现,负载均衡,居然都和它有关!!!

如上图:

(1) 故障转移 ,假如旧的服务节点s1出现了故障,c1和c2连接失效,会被从连接池中剔除,后续请求不会再发送到故障的节点中;

(2) 服务发现 ,假如新的服务节点s4上线,c7和c8连接建立,会被加入到连接池中来,后续请求会发送到新增的节点中;

动态删除连接与新增连接,这就是 动态连接池

服务发现,如何感知到新的节点s4上线呢?

详见《 改了配置,不想重启,怎么整? 》。

二、负载均衡

采用 轮询的策略 ,逐个使用连接池中的连接,可以实现对下游服务访问的负载均衡。

采用 完全随机的策略 ,也能实现负载均衡。

故障转移,服务发现,负载均衡,居然都和它有关!!!

如上图:

给每个连接一个相同的权重,取连接访问下游时,采用一个随机算法,落到哪个格子用哪个连接,还是上面的例子:

n = random() % 6 + 1;

n=[1,2],访问s1;

n=[3,4],访问s2;

n=[5,6],访问s3;

3个区间的宽度相同,即落到某个服务的概率相等 ,负载是均衡的。

那么, 如果服务节点的服务能力有差异,有的处理能力强,有的处理能力弱,怎么办呢?

三、静态权重负载均衡

故障转移,服务发现,负载均衡,居然都和它有关!!!

如上图:

给每个服务配置一个不同的权重,连接池初始化时,不同服务的区间大小有差异,取连接访问下游时,落到某个格子的概率也会有差异:

n = random() % 16 + 1;

n=[1,2],访问s1;

n=[3,6],访问s2;

n=[7,16],访问s3;

3个区间的宽度与服务的权重成正比,即落到某个服务的概率等同权重

画外音: nginx就支持这么玩,但静态权重实在太粗暴了。

那么, 如果服务节点的服务能力有差异,但又很难用静态权重标识,怎么办呢?

四、动态权重负载均衡

故障转移,服务发现,负载均衡,居然都和它有关!!!

如上图:连接池初始化时,为连接分配 一个动态的权重。

画外音: 服务不再需要配置了。

仍按照之前的方法分配负载,只是:

(1)连接处理超时,动态权重下降;

(2)连接处理成功,动态权重上升;

更具体的细节,详见《 异构服务器的负载均衡,怎么设计? 》。

如此一来,就能够 根据服务的实际处理能力分配负载了 ,是不是有点意思?

故障转移,服务发现,负载均衡,静态权重/动态权重负载均衡 ,你有收获吗?

故障转移,服务发现,负载均衡,居然都和它有关!!!

架构师之路 -分享技术思路

相关文章

改了配置,不想重启,怎么整?

异构服务器的负载均衡,怎么设计?

调研 :贵司改过底层连接池么?

原文  http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651963044&idx=1&sn=d53a226cab628d29988a42fe4a769789
正文到此结束
Loading...