4

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

 1 year ago
source link: https://www.51cto.com/article/743176.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

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

作者:周永健 陈立 2022-12-27 07:42:12
全栈云应用通过负载均衡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服务。​

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

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK