负载均衡在复杂ERP产品中的技术应用

vlambda
2020-05-01

负载均衡在复杂ERP产品中的技术应用

文字丨3063字，阅读用时3分钟

企业管理软件ERP产品，一般用于集团型或大中型企业比较多，用户访问量往往都比较大，对服务器的压力也是非常的大，从而导致ERP系统变得缓慢和不稳定。我们可以通过负载均衡设备或服务提高系统的性能和可用性，从而保证系统的流畅性和稳定性。

下面介绍负载均衡设备或服务在ERP系统中具体应用，从而让大家更清楚负载均衡是如何提高ERP系统的性能和可用性的。

1.负载均衡在ERP系统中应用

【负载均衡】：负载均衡F5在ERP产品按照地区IP负载应用服务

对于一家大型企业，在全国各地都有分子公司，为了实现财务共享集中式财务核算和业务运作模式，需要集中部署一套ERP系统。

注册用户上万个，用户并发访问量可达1000个。对于单台应用服务，最多支持250个并发访问数，那是架不住这么高并发的。

由于用户访问量比较高造成服务器压力过大，为了分担单体服务器的压力，需要通过负载均衡设备F5进行负载多台应用服务器同时处理高并发的请求。

负载均衡在复杂ERP产品中的技术应用

由于用户来自不同地区，所以请求也是来自不同地区，可以根据用户来源IP做负载均衡。比如，河北用户请求通过F5负载到ERP Tomcat1 服务上，山东用户请求可以负载到ERP Tomcat2服务上。负载均衡可以就对大量的不同用户请求分担到不同的服务器了，进一步提高了服务器处理高并发请求的效率，从而提高了ERP系统的性能。如果ERP Tomcat1的服务宕机了，河北用户请求就会负载到ERP Tomcat2服务上，从而实现了ERP系统高可用性。

【特别说明】：为什么要用用户的来源IP做负载路由策略呢？

因为ERP系统的数据库使用了Oracle RAC 集群，为了减少数据库实例之间的缓存融通和锁资源的消耗，所以负载均衡策略按照地区来访问固定的数据库节点，比如河北用户只访问数据库节点A，山东用户只访问数据库节点B。

2.负载均衡在费控系统中应用

为了提高费控系统的性能和可用性，费控的负载均衡使用了SLB服务器（实际上是Nginx），采用了URL+轮询的负载路由策略。

比如,url1: yanshi.com负载到虚拟服务器组A，yunyanshi.com负载到虚拟服务器组B。假设 100个用户请求通过负载均衡SLB，其中有50个请求负载到ECS1上，有50个请求负载到ECS2,这样服务器的压力都被给平摊了。

在使用负载均衡服务SLB的时候，也遇见一些坑，下面给介绍其中一个比较常见的坑。

负载均衡在复杂ERP产品中的技术应用

【问题现象】：费控系统负载均衡SLB使用的是HTTPS协议，负载到后台负载ECS应用服务使用的是HTTP协议。当后台服务重定向请求时，请求就会变成了HTTP协议，但是在SLB端使用的HTTPS协议，导致HTTP协议经过SLB后变成无效路径。

【问题分析】：因为ECS后台应用服务支持的HTTP协议，所以请求重定向时，请求依然使用的是HTTPJ协议。请求经过SLB时，因为SLB支持的是HTTPS协议，所以重定向的HTTP请求会被SLB无法识别，就认为该请求的路径是无效的。

【问题解决】：使用SLB的http协议80端口重定向到https协议的443端口，这样的话，SLB后台程序就会把重定向的http协议请求转换为https协议，从而请求经过SLB能够找到具体的路径。

3.负载均衡在小型ERP系统中的应用

在中小型的ERP系统中，负载均衡虽然使用的不是很普遍，但是在一些大点的企业，还是可以使用的。在小ERP产品中使用负载均衡Nginx的时候，也会遇见一些坑，下面介绍的一个就是大家可能经常碰见的坑。

【问题现象】：当用户访问小型ERP系统遇到一个静态资源路径找不到的问题，导致有些页面加载不全或报错。在使用Nginx七层负载均衡的时候，用的是https协议，负载到后台Tomcat服务后，静态资源，js,css,图片，html等静态资源的请求都会变成了http协议，导致这些静态资源请求经过Nginx负载均衡的时候，无法识别http协议，就找不到请求的URL路径。

【问题分析】：Nginx负载的时候，使用的https协议，而后台的Tomcat应用服务使用的是http协议，静态资源加载的时候，还是使用原来的http协议，经过Nginx负载的时候，不支持http协议请求的转发，所以会返回给客户端提示静态资源的url路径找不到。

【问题解决】：在Tomcat的应用服务的程序上对静态资源路径做一些修改，首先需要把静态资源的url路径改成https协议，然后请求重定向经过Nginx负载的时候，就会识别https协议请求，最后Nginx会转发到后端Tomcat应用服务。

由于Nginx在互联网企业或传统IT企业也用的比较多，属于轻量级的软件负载均衡服务，下面专门简要的讲解下其负载均衡的基本策略。

4.负载均衡6种策略简单介绍

负载均衡策略	具体方式
轮询	默认方式
weight	权重方式
ip_hash	依据ip分配方式
least_conn	最少连接方式
fair（第三方）	响应时间方式
url_hash	依据URL分配方式

（1）轮询（默认）

每个请求按时间顺序逐一分配到不同的后端服务器。

#动态服务器组

upstream yanshi.com{

server 192.168.1.2:8080;

server 192.168.1.3:8080;

}

【特别说明】：

在轮询中，如果服务器down掉了，会自动剔除该服务器。
缺省配置就是轮询策略。
此策略适合服务器配置相当，无状态且短平快的服务使用。

（2）weight

权重方式，在轮询策略的基础上指定轮询的几率。

#动态服务器组

upstream yanshi.com{

server 192.168.1.2:8080 weight=10;

server 192.168.1.3:8080 weight=10;

}

【特别说明】：

权重越高分配到需要处理的请求越多。
此策略可以与least_conn和ip_hash结合使用。
此策略比较适合服务器的硬件配置差别比较大的情况。

（3）ip_hash

每个请求按客户端来源ip的hash结果分配，这个方法保证每个客户端固定访问一个后端服务器，可以解决session不能跨服务器的会话问题。

#动态服务器组

upstream yanshi.com{

ip_hash; #保证每个客户端固定访问一个后端服务器

server 192.168.1.2:8080 weight=10;

server 192.168.1.3:8080 ;

}

【特别说明】：

在nginx版本1.3.1之前，不能在ip_hash中使用权重（weight）。
ip_hash不能与backup同时使用。
此策略适合有状态服务，比如session。
当有服务器需要剔除，必须手动down掉。

（4）least_conn

把请求转发给连接数较少的后端服务器。

#动态服务器组

upstream yanshi.com{

least_conn; #把请求转发给连接数较少的后端服务器

server 192.168.1.2:8080 weight=10;

server 192.168.1.3:8080 ;

}

【特别说明】：

此负载均衡策略适合请求处理时间长短不一造成服务器过载的情况。

（5）fair（第三方）

按照服务器端的响应时间来分配请求，响应时间短的优先分配。

[第三方的负载均衡策略的实现需要安装第三方插件]

#动态服务器组

upstream yanshi.com{

server 192.168.1.2:8080;

server 192.168.1.3:8080 ;

fair; #实现响应时间短的优先分配

}

（6）url_hash（第三方）

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

[第三方的负载均衡策略的实现需要安装第三方插件]

#动态服务器组

upstream yanshi.com{

hash $request_uri; #实现每个url定向到同一个后端服务器

server 192.168.1.2:8080;

server 192.168.1.3:8080 ;

}

【特别说明】：

同一个资源多次请求，可能会访问不同服务器，导致多次下载，缓存命中率不高，以及一些资源时间的浪费。而使用url_hash，可以使同一个url（也就是同一个资源请求）访问同一台服务器，一旦缓存了资源，再此请求，直接从缓存中读取。　

【参数说明】：

参数	说明
fail_timeout	与max_fails结合使用
max_fails	设置在fail_timeout参数设置的时间内最大失败次数，如果在这个时间内，所有针对该服务器的请求都失败了，那么认为该服务器会被认为是停机了
fail_time	服务器会被认为停机的时间长度,默认为10s
backup	标记该服务器为备用服务器。当主服务器停时，请求会被发送到它这里
down	标记服务器永久停机了