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服务。​