G行全栈云环境负载均衡服务能力实践—负载均衡服务在G行的实践

云计算 云原生
全栈云应用通过负载均衡ELB将负载流量转发给后端的多个虚拟机或者容器应用,通过TCP和HTTP两种健康检查方式对后端负载的存活状态进行探查。TCP健康检查只探测对应的应用端口是否存在,配置简单,响应较快。

前言

G行作为金融行业数字化转型的探索者与实践者,提出“123+N”的数字化特色发展体系,即一个智慧大脑,两大技术平台——云计算平台和大数据平台,三项服务能力——移动化、开放化、生态化服务能力,N个数字化名品——数据挖掘模型体系、随心贷、专属客服、手机银行等。根据数字化发展战略要求,传统数据中心的应用系统要逐步迁移到云平台,实现服务云化,满足业务需求的快速迭代,同时云平台可提供快速便捷的资源交付和资源扩容能力,提升资源利用率,达到降本增效的目标。

针对应用上云,G行制定了相关的上云策略,强调优先容器化部署,对于无法容器化改造的产品组件可通过虚拟机或裸金属方式上云,以多种部署形式满足应用上云要求。针对传统环境和云上应用,所使用的业务流量负载方式是不同的,传统环境主要使用硬件F5负载均衡,优点是性能好、功能强大,缺点是成本高、扩展性差、不符合信创要求。云环境使用云平台提供的服务组件弹性负载均衡服务,优点是成本低、扩展性好、符合信创要求,缺点是相比硬件负载均衡性能略有下降。上期文章介绍了负载均衡服务的关键技术,本期重点介绍下负载均衡服务在G行的实践。

G行弹性负载均衡实践

G行在应用上云过程中,通过制定上云模型以规范上云部署架构。上云模型主要分为虚拟机架构上云、容器化上云、裸金属上云以及多种形式的混合上云部署模型。在这些模型中,弹性负载均衡主要提供流量负载能力,主要运用在虚拟机应用和容器应用中。

图片

图1 G行虚拟机上云与容器化上云的负载均衡示意

虚拟机应用弹性负载均衡服务能力实践

为满足同城多活要求,应用服务在逻辑上三个数据中心部署(分别为AZ1、AZ2、AZ3)。其中数据层部署跨三中心的DB和Redis服务实例,对三中心的应用服务层提供统一的数据库服务和缓存服务。数据库服务主要用于结构化数据的永久保存,缓存服务主要用于会话保持数据的存储和其他缓存使用场景,实现应用无状态。

应用层在每个数据中心部署对应的前端Web应用和后端App服务。其中Web和App服务均以负载均衡架构部署,通过前端的负载均衡ELB将请求流量转发到对应的后端服务节点,提升负载能力的同时保障系统的高可用设计,并且可根据服务的容量需求进行动态扩缩容。负载均衡通过TCP和HTTP两种健康检查方式对后端负载的存活状态进行探查,实现故障节点自动隔离能力和故障自愈恢复能力。

在应用访问层设计方面,全栈云为三层网络架构,每个数据中心使用一个ELB地址作为该数据中心的应用入口,外部请求通过DNS服务配置的域名解析策略将流量转发到三个数据中心Web服务前端的ELB地址,然后ELB将请求转发到对应的Web服务,再经App服务前端的ELB负载到App服务,最终到数据库服务。

由于上述架构在三个数据中心使用了三个ELB作为应用入口地址,无法像传统环境一样,使用统一一个负载均衡实例作为入口地址,利用负载均衡的会话保持功能实现会话保持,因此需要通过应用层将会话信息Session保存在Redis服务中。外部请求再次进入系统后,读取Session信息获取会话信息,而无需关注实际请求是哪一个服务节点,对应用来说是透明的,从而实现全栈应用的会话保持能力。

图片

图2 G行虚拟机应用弹性负载均衡服务架构示意

容器应用弹性负载均衡服务能力实践

容器部署应用以前后端分离单体应用为例,应用请求依旧通过DNS服务将请求转发到Web服务对应的ELB地址,然后Web服务通过访问App服务的Service将流量转发到实际App服务Pod上,最后访问到数据库服务。

在该应用架构中主要有两点需要特别说明。第一,负载均衡ELB作为容器应用对外暴露端口的固定地址,三中心架构通过DNS域名将地址解析到三中心的ELB地址,ELB地址通过在k8s集群创建Loadbalance服务,将应用服务对外暴露。第二,在k8s集群内部,服务与服务之间通过Service服务访问,严禁使用ELB的Loadbalance服务。该应用Web服务访问App服务,属于集群内部访问,Web服务应该通过Service服务访问App,此时的Service服务在k8s内部类似起到负载均衡器的作用。

关于App的Service服务,此处的负载均衡器理论上也可以通过弹性负载均衡ELB暴露固定地址,访问链路由DNS-->ELB-->Web Pod-->Service-->App Pod-->EverDB演变为DNS-->ELB-->Web Pod-->ELB-->App Pod-->EverDB。虽然访问没有问题,但增大了ELB实例的服务开销,同时本身内部服务访问的容器网络流量转变为容器网络和ELB网络的交叉流量,降低了服务之间的访问效率,并且增加网络链路的复杂度。

图片

图3 G行容器应用弹性负载均衡服务架构示意

总结

全栈云应用通过负载均衡ELB将负载流量转发给后端的多个虚拟机或者容器应用,通过TCP和HTTP两种健康检查方式对后端负载的存活状态进行探查。TCP健康检查只探测对应的应用端口是否存在,配置简单,响应较快。HTTP检查可以根据提供的端口和URL路径准确判断应用的健康状态,检查准确性高,覆盖面更全,具体使用方式根据业务场景进行配置。针对流量转发算法,一般负载均衡设备后端的负载节点配置相同,可采用轮询算法进行负载流量转发。

针对不同的上云部署方式,虚拟机类应用,弹性负载均衡无特殊要求;而容器类应用,弹性负载均衡ELB只能用于需要对外暴露服务端口的服务,通过创建Loadbalance服务将ELB和容器Pod关联,而内部服务访问统一使用Service服务。​

责任编辑:武晓燕 来源: 匠心独运维妙维效
相关推荐

2022-12-20 08:01:20

全栈云负载均衡传统硬件

2023-03-28 07:42:03

2021-04-21 14:56:28

负载均衡高并发优化技术架构

2022-06-01 09:04:58

Kafka运维副本迁移

2010-04-21 14:54:45

负载均衡服务

2015-04-16 13:26:30

青云/QingClou

2010-04-20 15:27:20

负载均衡

2010-04-20 11:51:31

负载均衡

2022-02-02 21:37:57

云计算全栈云运营

2020-04-15 22:18:55

架构负载均衡分布式

2017-07-03 08:08:25

负载均衡分类

2012-10-19 09:57:43

Apache负载均衡集群功能

2019-03-13 12:04:41

Nginx负载均衡动静分离

2022-02-08 07:56:38

云厂商云计算云服务

2019-06-19 15:34:39

Nginx反向代理负载均衡

2022-01-11 07:44:27

云计算云应用全栈云

2023-12-05 07:31:26

云容器数字化

2010-04-22 18:27:37

Apache负载均衡

2014-06-11 09:17:39

负载均衡

2015-08-24 11:02:56

网络故障负载均衡
点赞
收藏

51CTO技术栈公众号