nginx和tomcat来实现负载均衡和灰度发布

本文详细介绍了Nginx的配置方法,包括负载均衡的实现方式,并探讨了如何通过Nginx实现代码的热部署及灰度发布。同时,文章还深入解析了在同一台Linux虚拟机上安装两个Tomcat实例的配置过程,针对Tomcat内存不足的问题提供了具体的解决方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

###nginx配置 niginx主要是配置nginx.conf配置文件

upstream boss {
       server 127.0.0.1:8080 weight=2;
       server 127.0.0.1:8081 down;
}

 server {
        listen       80;
        server_name  boss.example.com;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location / {
           if ( $request_uri = "/" ) {
              rewrite "/" http://boss.example.com/boss-web break;
           }
           proxy_pass http://boss;
           proxy_set_header Host $host;
           proxy_set_header X-Forward-For $remote_addr;	
        }
}

###tomcat配置 目前是在同一台linux虚拟机上装的tomcat,所以在tomcat的server.xml配置文件。 tomcat1用默认配置文件 tomcat2有4个地方需要配置。

 <Connector port="8081" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />

<Connector executor="tomcatThreadPool"
               port="8081" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />

<!-- Define an AJP 1.3 Connector on port 8009 -->
    <Connector port="8010" protocol="AJP/1.3" redirectPort="8443" />

这样配置其实是有问题的就是session共享的问题。不过好在权限是用shiro来实现的,所以在“同域名”的情况下,是可以利用cookie来共享域的。要真正解决这个问题,需要觉得session共享的问题。有两种解决方案,一种是利用cookie来共享,一种是利用服务器后台比如存在memcached中或者redis中。

##灰度发布 nginx:利用负载均衡原理实现代码的热部署和灰度发布

###Tomcat内存空间不够问题解决。

1、 linux下的tomcat:
修改TOMCAT_HOME/bin/catalina.sh 位置cygwin=false前。 JAVA_OPTS="-server -Xms256m -Xmx512m -XX:PermSize=64M -XX:MaxPermSize=128m"

对于用jdk8的需要修改上面的参数 JAVA_OPTS="-server -Xms256m -Xmx512m -XX:MetaspaceSize=64m -XX:MaxMetaspaceSize=128m"

转载于:https://my.oschina.net/miaojiangmin/blog/833630

<think>好的,用户问的是如何在Java的BS架构、单体服务且前后端不分离的情况下实现负载均衡。首先,我需要确认用户的具体场景。BS架构通常指的是浏览器/服务器模式,单体服务意味着前端后端代码是耦合在一起的,可能打包成一个WAR或JAR文件部署。前后端不分离,所以前端资源(如HTML、JS、CSS)后端逻辑可能在同一应用中。 接下来,负载均衡的目标是将请求分发到多个服务器实例,以提高系统的可用性处理能力。用户可能已经有一个运行中的单体应用,现在面临流量增加,需要扩展。需要考虑几个方面:如何部署多个实例,如何保持会话一致性,如何处理静态资源,以及如何配置负载均衡器。 首先,常见的负载均衡方案有硬件负载均衡(如F5)软件负载均衡(如Nginx、HAProxy)。对于Java应用,可能使用Tomcat、Jetty等Servlet容器,或者Spring Boot内嵌的容器。用户需要部署多个应用实例,每个实例运行在不同的端口或服务器上。 然后,需要考虑会话(Session)管理。在单体应用中,用户会话可能存储在服务器的内存中,如果使用负载均衡,需要确保用户的请求被转发到同一实例,或者使用分布式会话解决方案。比如,可以使用粘性会话(Sticky Session),让负载均衡器根据会话ID将同一用户的请求转发到同一服务器。或者将会话数据存储到外部存储如Redis中,实现会话共享。 静态资源的处理也需要考虑。由于前后端不分离,静态资源可能打包在应用中,每个实例都有相同的资源。这时需要确保负载均衡器正确分发请求,或者将静态资源单独托管,比如使用CDN或反向代理(如Nginx)来服务静态文件,减轻应用服务器的负担。 另外,数据库文件存储的问题。如果应用涉及文件上传,需要确保所有实例访问的是同一存储位置,比如网络共享存储或云存储服务。数据库连接池的配置也需要调整,避免每个实例过多的连接导致数据库压力过大。 可能的步骤包括: 1. 部署多个应用实例,可以在同一服务器不同端口或多个服务器上。 2. 配置负载均衡器(如Nginx)进行请求分发,设置负载均衡策略(轮询、IP哈希、最少连接等)。 3. 处理会话问题,使用粘性会话或引入Redis等实现会话共享。 4. 处理静态资源,可能需要统一存储或由负载均衡器直接处理。 5. 确保后端服务(如数据库、文件系统)能够支持多实例访问。 需要提醒用户注意的问题:会话一致性、静态资源同步、配置管理、健康检查等。例如,Nginx可以配置健康检查,自动剔除故障节点;使用Spring SessionRedis可以方便地实现分布式会话。 可能用户没有考虑到的是,随着实例增加,配置管理日志收集也会变得复杂,可能需要引入额外的工具。另外,负载均衡器本身可能成为单点故障,需要考虑高可用性,比如使用Keepalived实现Nginx的高可用。 最后,总结实现步骤,给出具体的配置示例,比如Nginx的配置片段,Spring Boot如何集成Redis存储会话,帮助用户更直观地操作。</think>在Java BS架构单体服务前后端不分离的场景下,实现负载均衡可按照以下步骤进行: ### 一、核心实现方案 1. **水平扩展应用实例** ```bash # 在不同服务器或同一服务器的不同端口启动多个实例 java -jar your-app.jar --server.port=8080 java -jar your-app.jar --server.port=8081 ``` 2. **配置Nginx负载均衡** ```nginx http { upstream backend { # 配置IP哈希保持会话粘性 ip_hash; # 配置应用实例地址 server 192.168.1.100:8080 weight=3; server 192.168.1.101:8081; server backup.example.com:8082 backup; } server { location / { proxy_pass http://backend; # 传递客户端真实IP proxy_set_header X-Real-IP $remote_addr; } } } ``` 3. **会话管理方案对比** | 方案类型 | 实现方式 | 优点 | 缺点 | |----------------|-----------------------------|-----------------------|-----------------------| | 粘性会话 | Nginx的`ip_hash` | 实现简单 | 扩容时流量分配不均 | | Redis分布式会话| Spring Session + Redis | 支持无缝扩容 | 需要引入Redis依赖 | ### 二、关键实施细节 1. **静态资源处理** - 保持所有实例的静态资源完全一致 - 建议使用`rsync`进行资源同步: ```bash rsync -avz /path/to/resources user@server2:/app/static/ ``` 2. **文件存储方案** ```java // 在代码中配置共享存储路径 @Configuration public class StorageConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/uploads/**") .addResourceLocations("file:///shared-storage/uploads/"); } } ``` 3. **健康检查配置** ```nginx server { location /health { proxy_pass http://backend; health_check interval=10s fails=3 passes=2; } } ``` ### 三、增强方案 1. **双活Nginx架构** ```mermaid graph TD A[客户端] --> B[Nginx主] A --> C[Nginx备] B --> D[应用实例1] B --> E[应用实例2] C --> D C --> E B <--> C[Keepalived心跳检测] ``` 2. **灰度发布配置** ```nginx upstream backend { server app-v1:8080 weight=9; # 旧版本 server app-v2:8080 weight=1; # 新版本 } ``` ### 四、性能优化建议 1. **连接池配置优化** ```properties # application.properties spring.datasource.hikari.maximum-pool-size=20 spring.datasource.hikari.minimum-idle=5 ``` 2. **缓存配置示例** ```java @Configuration @EnableCaching public class CacheConfig { @Bean public RedisCacheManager cacheManager(RedisConnectionFactory factory) { return RedisCacheManager.builder(factory) .cacheDefaults(RedisCacheConfiguration.defaultCacheConfig() .entryTtl(Duration.ofMinutes(30))) .build(); } } ``` ### 五、监控方案 1. **Prometheus监控指标暴露** ```java @Bean MeterRegistryCustomizer<MeterRegistry> metricsCommonTags() { return registry -> registry.config().commonTags("application", "monolithic-app"); } ``` 2. **关键监控指标项: - 请求QPS - 平均响应时间 - JVM内存使用率 - 线程池活跃线程数 - 数据库连接池使用率 > **注意事项**: > 1. 使用`ip_hash`时,建议同时配置`权重(weight)`参数优化流量分配 > 2. 文件上传目录建议使用云存储服务(如OSS)或网络附加存储(NAS) > 3. 定期清理各实例的本地临时文件 > 4. 建议对静态资源开启CDN加速 这种架构的TPS承载能力取决于:硬件配置、业务复杂度、数据库性能等因素。典型4核8G服务器集群(3节点)一般可支撑$QPS=800 \sim 1200$,响应时间$RT < 300ms$的业务场景。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值