微服务spring cloud的性能问题解决之道

springcloud常见问题总结以（一）

springcloud常见问题总结以（⼀）1. 服务注册涉及到周期性的⼼跳，默认30秒⼀次，只有当实例、服务器端和客户端本地缓存中的元数据都相同时，服务才能被其他客户端发现（可能需要三次⼼跳）。

2. 可以使⽤参数eureka.instance.leaseRenewalintervalInSeconds修改eureka client向eureka server发送⼼跳间隔，从⽽加快客户端连接到其他服务的过程。

在⽣产环境中最好坚持使⽤默认值，因为在服务器内部有⼀些计算，它们会对续约做出假设。

1. Eureka server清理⽆效节点的周期⽐较长（默认90秒），以及⾃我保护等原因，可能对服务节点注销慢或者不注销2. Eureka server配置关闭⾃我保护，并按需配置清理⽆效节点的间隔：eureka:server:enable-self-preservation: false # 测试时关闭⾃我保护机制，保证不可⽤服务及时踢出eviction-interval-timer-in-ms: 30000 # 清理间隔单位是毫秒3. Eureka client端开启健康检查，按需配置续约更新时间和到期时间：eureka:client:healthcheck:enabled: true #开启健康检查（需要spring-boot-starter-actuator依赖）instance:lease-renewal-interval-in-seconds: 1 # 每间隔1s，向服务端发送⼀次⼼跳，证明⾃⼰依然”存活“，默认30秒lease-expiration-duration-in-seconds: 2 # 告诉服务端，如果我2s之内没有给你发⼼跳，就代表我“死”了，将我踢出掉，默认90秒。

注意：这些配置⼀般在开发测试的时候使⽤，⽣产环境建议使⽤默认配置4. ⾃定义微服务instanceIDeureka:instance:instance-id: ${spring.cloud.client.ipAddress}:${server.port} # 将instance-id设置为ip：端⼝的形式。

SpringCloud分布式事务的解决方案

SpringCloud分布式事务的解决⽅案常见的分布式解决⽅案1、两阶段提交协议（2PC）解决分布式系统的数据⼀致性问题出现了两阶段提交协议（2 Phase Commitment Protocol），两阶段提交由协调者和参与者组成，共经过两个阶段和三个操作，部分关系数据库如Oracle、MySQL⽀持两阶段提交协议。

说到2pc就不得不聊聊数据库分布式事务中的XA transactions在XA协议中分为两阶段:第⼀阶段：事务管理器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交.第⼆阶段：事务协调器要求每个数据库提交数据，或者回滚数据。

举⼀个例⼦：1、应⽤程序通过事务协调器向两个库发起prepare，两个数据库收到消息分别执⾏本地事务（记录⽇志），但不提交，如果执⾏成功则回复yes，否则回复no。

2、事务协调器收到回复，只要有⼀⽅回复no则分别向参与者发起回滚事务，参与者开始回滚事务。

3、事务协调器收到回复，全部回复yes，此时向参与者发起提交事务。

如果参与者有⼀⽅提交事务失败则由事务协调器发起回滚事务。

优点：尽量保证了数据的强⼀致，实现成本较低，在各⼤主流数据库都有⾃⼰实现，对于MySQL是从5.5开始⽀持。

缺点:单点问题:事务管理器在整个流程中扮演的⾓⾊很关键，如果其宕机，⽐如在第⼀阶段已经完成，在第⼆阶段正准备提交的时候事务管理器宕机，资源管理器就会⼀直阻塞，导致数据库⽆法使⽤。

同步阻塞:在准备就绪之后，资源管理器中的资源⼀直处于阻塞，直到提交完成，释放资源。

数据不⼀致:两阶段提交协议虽然为分布式数据强⼀致性所设计，但仍然存在数据不⼀致性的可能，⽐如在第⼆阶段中，假设协调者发出了事务commit的通知，但是因为⽹络问题该通知仅被⼀部分参与者所收到并执⾏了commit操作，其余的参与者则因为没有收到通知⼀直处于阻塞状态，这时候就产⽣了数据的不⼀致性。

SpringCloudfeign微服务调用之间的异常处理方式

SpringCloudfeign微服务调⽤之间的异常处理⽅式如何优雅地处理微服务间调⽤的异常现在微服务架构盛⾏，其中spring cloud⽅案就很具有代表。

那么在微服务之间进⾏调⽤，如果被调⽤的服务挂了，调⽤⽅如何感知呢？⼀、加上hystrix熔断在定义feignClient的地⽅指定熔断，如下图当被调⽤服务不可⽤或者被调⽤⽅发⽣错误的时候，会触发熔断，但是，如果被调⽤⽅抛出异常，调⽤⽅怎么知道究竟是出了什么问题呢？那，这就出现了⼆、feign全局异常处理我们不得不提到feign提供的⼀个接⼝叫做ErrorDecoder，是⽤来处理feign异常的，有⼀个⽅法需要实现 public Exception decode(String s, Response response)如下图：这样就会替换它默认的feign异常处理，这样就可以捕捉全局的异常了，但是⼜带来⼀个新的问题，如果使⽤这个ErrorDecoder，得关闭熔断，否者这⾥抛出的FeignBadRequestException异常⼜会被hystrix吞掉，那，有没有更好的办法呢？在被调⽤的controller⽅法⾥⾯捕捉全局异常，发⽣错误的时候，把异常保存⼀个对象⾥⾯，然后⽤该对象进⾏服务间的通信，调⽤⽅收到结果再检查是否包含错误，这个⽅式确实可以解决，但，这肯定不是个好办法；那么有没有更好的办法呢？跳出ErrorDecoder后，会经过在AbstractCommand⾥⾯的⼀个executeCommandAndObserve⽅法⾥⾯有个function叫做 handleFallback由此可知，当抛出的异常是HystrixBadRequestException时，直接抛出异常，不再经过fallback，那么我们的解决办法就有了，那就是调整FeignBadRequestException 的继承对象，如图现在，就实现了服务端不可⽤和服务端报错的异常分离，但是可能，有的同学已经注意到了，FeignClientErrorDecoder这个异常处理类⾥⾯是是针对状态为SERVICE_UNAVAILABLE的进⾏了特别处理，为社么要这样？这是因为与被调⽤⽅约定当状态码为 SERVICE_UNAVAILABLE 的时候视为被调⽤⽅主动抛出的异常需要注意的地⽅我们的被调⽤⽅除了提供微服务之间调⽤，很可能也提供了⾯向前端的接⼝，为了封装我们程序内部的异常，通常我们会定义个全局异常捕捉类，即使报错了，我们也提供⼀个友好的交互⽅式，⽐如下⾯这样第⼀处我们除了系统内部抛出的异常，第⼆处处理其它异常，也就是说，不管抛出什么错，该服务都会返回⼀个状态值为200的信息出去，那么问题来了，我们微服务间的调⽤也会被处理成200，从⽽导致feign会以为服务是正常的，正常返回结果了，没有报错，那怎么办？三、针对内部调⽤的特殊处理当然，你可能想到了，我们可以在提供给内部使⽤的接⼝进⾏异常转换，然后让全局异常处理处不进⾏这样的处理，但是，每个内部接⼝都要进⾏全局异常捕捉，然后转换，这，明显不是最好的做法四、通过注解标记为接⼝为内部调⽤接⼝先定义⼀个注解，直接上图我们定义该注解为⽅法和类上都可以使⽤，然后再定义处理程序处理程序要做⼀件事情，就是在程序⽅法异常的时候，将http状态码设置为我们约定的SERVICE_UNAVAILABLE，然后看下怎么使⽤这样我们把该⽅法标记为了供内部使⽤的接⼝，当然，同样也可以将注解放在类上，这样就可以把该类的全部⽅法标记为内部调⽤。

SpringCloudGateway内存溢出的解决方案

SpringCloudGateway内存溢出的解决⽅案记 Spring Cloud Gateway 内存溢出查询过程环境配置：org.springframework.boot ： 2.1.4.RELEASEorg.springframework.cloud ：Greenwich.SR1事故记录：由于⽹关存在 RequestBody 丢失的情况，顾采⽤了⽹上的通⽤解决⽅案，使⽤如下⽅式解决：@Beanpublic RouteLocator tpauditRoutes(RouteLocatorBuilder builder) {return builder.routes().route("gateway-post", r -> r.order(1).method(HttpMethod.POST).and().readBody(String.class, requestBody -> {return true;}) # 重点在这.and().path("/gateway/**").filters(f -> {f.stripPrefix(1);return f;}).uri("lb://APP-API")).build();}测试环境，Spring Cloud Gateway ⽹关功能编写完成。

开始进⾏测试环境压测。

正常采⽤梯度压测⽅式，最⾼⽤户峰值设置为400并发。

经历两轮时长10分钟左右压测，没有异常情况出现。

中午吃饭时间，设置了1个⼩时的时间进⾏测试。

回来的时候系统报出如下异常2019-08-12 15:06:07,296 1092208 [reactor-http-server-epoll-12] WARN ty.channel.AbstractChannelHandlerContext.warn:146 - An exception '{}' [enable DEBUG level for full stacktrace] was thrown by a user handler's exceptionCaught() method while handlin ty.util.internal.OutOfDirectMemoryError: failed to allocate 16777216 byte(s) of direct memory (used: 503316487, max: 504889344)at ty.util.internal.PlatformDependent.incrementMemoryCounter(PlatformDependent.java:640)at ty.util.internal.PlatformDependent.allocateDirectNoCleaner(PlatformDependent.java:594)at ty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:764)at ty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:740)at ty.buffer.PoolArena.allocateNormal(PoolArena.java:244)at ty.buffer.PoolArena.allocate(PoolArena.java:214)at ty.buffer.PoolArena.allocate(PoolArena.java:146)at ty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:324)at ty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:185)at ty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:176)at ty.buffer.AbstractByteBufAllocator.ioBuffer(AbstractByteBufAllocator.java:137)at ty.channel.DefaultMaxMessagesRecvByteBufAllocator$MaxMessageHandle.allocate(DefaultMaxMessagesRecvByteBufAllocator.java:114)at ty.channel.epoll.EpollRecvByteAllocatorHandle.allocate(EpollRecvByteAllocatorHandle.java:72)at ty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:793)at ty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe$1.run(AbstractEpollChannel.java:382)at ty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)at ty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404)at ty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:315)at io.当时⼀脸懵逼，马上开始监控 Jvm 堆栈，减少jvm的内存空间，提升并发数以后，重启项⽬重新压测，项⽬启动参数如下：java -jar -Xmx1024M /opt/deploy/gateway-appapi/cloud-employ-gateway-0.0.5-SNAPSHOT.jar↓↓↓↓修改为↓↓↓↓java -jar -Xmx512M /opt/deploy/gateway-appapi/cloud-employ-gateway-0.0.5-SNAPSHOT.jar缩减了⼀半内存启动，等待问题复现。

微服务架构的挑战与解决方案探索

微服务架构的挑战与解决方案探索近年来，微服务架构在软件开发领域中越来越受到关注和应用。

与传统的单体应用相比，微服务架构将应用拆分成一系列小型、独立的服务，每个服务都可以独立开发、部署和扩展。

这种架构的优势在于提高了开发效率、降低了耦合度，并且能够更好地满足不同业务需求。

然而，微服务架构也面临着一些挑战，本文将探讨这些挑战并提出相应的解决方案。

一、服务间通信的复杂性在微服务架构中，各个服务之间需要进行频繁的通信。

这涉及到服务的注册与发现、负载均衡、容错处理等问题。

如果不加以合理的设计和管理，服务间通信的复杂性将会导致系统的不稳定和性能下降。

为了解决这个问题，可以采用以下几种方案：1. 使用服务注册与发现机制，例如使用Consul、Eureka等工具，可以方便地管理和发现各个服务。

2. 引入消息队列，将服务之间的通信异步化，减少对服务的直接依赖。

3. 使用断路器模式来处理服务之间的故障，保证系统的稳定性。

二、数据一致性的保证在微服务架构中，每个服务都有自己的数据库，这就带来了数据一致性的问题。

当多个服务同时对同一份数据进行操作时，如何保证数据的一致性成为了一个挑战。

为了解决这个问题，可以采用以下几种方案：1. 引入分布式事务，例如使用TCC（Try-Confirm-Cancel）模式或者使用分布式事务管理器，如Seata等。

2. 使用事件驱动架构，将数据的变更以事件的形式发布出去，其他服务通过订阅事件来实现数据的一致性。

三、服务的部署和扩展微服务架构中的每个服务都可以独立部署和扩展，这为系统的灵活性和可伸缩性带来了很大的优势。

然而，服务的部署和扩展也面临一些挑战。

为了解决这个问题，可以采用以下几种方案：1. 使用容器化技术，例如Docker，可以将服务打包成镜像，实现快速部署和扩展。

2. 使用自动化运维工具，例如Kubernetes，可以方便地管理和扩展服务。

3. 使用云服务提供商的弹性计算能力，根据实际需求自动调整服务的规模。

SpringCloud微服务的实践

SpringCloud微服务的实践随着互联网技术的不断发展，越来越多的企业开始采用微服务架构来进行应用程序的开发与部署。

这一架构将整个应用程序分解成多个小型服务，每个服务可独立进行开发、部署、维护和升级。

SpringCloud作为微服务组件中的重要一员，在开发过程中发挥着重要的作用。

本文将分享一下在实际项目应用中的SpringCloud微服务实践经验。

一、SpringCloud介绍SpringCloud是一个用于构建分布式系统的框架，它基于Spring Boot微服务构建技术，提供一套完整的服务治理组件。

SpringCloud包含了多个子项目，如Eureka、Hystrix、Zuul等，这些组件能够帮助开发者快速构建高可靠、可扩展、易维护的微服务。

二、SpringCloud微服务的应用场景在日常开发中，SpringCloud微服务常用于以下三个场景：1. 服务编排服务编排主要是将多个应用程序协同工作，以实现更为复杂的业务逻辑。

SpringCloud通过Eureka、Feign等组件，可以实现服务的快速注册、发现与调用。

服务治理是指通过对服务进行监控、管理和维护，以保证系统的高可靠性、高可用性。

SpringCloud通过Hystrix、Turbine等组件，可实现服务的熔断、降级、限流等机制，为整个系统提供了更好的可靠性和稳定性。

3. API网关API网关是企业级应用接口的统一入口，负责处理API请求和响应，并进行鉴权、数据转换、流量控制等处理。

SpringCloud通过Zuul组件提供了API网关服务，能够快速构建安全可靠的API 网关。

三、SpringCloud微服务的实践在实际应用中，我们常用到的SpringCloud组件有Eureka、Feign、Hystrix、Zuul等。

下面以微服务架构下的电商企业为例，详细说明SpringCloud的实际应用。

1. 服务注册与发现服务注册与发现是SpringCloud微服务的核心组件，它主要用来管理多个微服务之间的依赖关系。

使用springcloud的缺点

使用Spring Cloud的缺点主要包括以下几点：
1.学习曲线陡峭：Spring Cloud的组件和功能非常丰富，学习曲线相对较陡
峭。

对于初学者来说，需要投入较多的时间和精力来学习和理解其各个组
件的原理和用法。

2.维护成本高：由于Spring Cloud采用了微服务架构，每个服务都是独立的
模块，因此需要针对每个服务进行部署、监控和维护。

这会增加维护成本
和管理工作量。

3.分布式系统复杂性：Spring Cloud主要针对分布式系统的开发和部署，因此
需要处理分布式系统的复杂性，如服务发现、负载均衡、熔断等。

这需要
开发人员具备较高的技术水平和经验。

4.版本兼容性问题：随着Spring Cloud的不断发展，各个组件的版本可能会
发生变化，导致版本兼容性问题。

在升级Spring Cloud的组件时，需要注
意版本之间的兼容性，以免出现不必要的问题。

5.开源社区的不成熟：尽管Spring Cloud的社区相对活跃，但相对于其他开
源社区来说，其成熟度可能还不够高。

这意味着在遇到问题时，可能找不
到足够的解决方案或技术支持。

总的来说，使用Spring Cloud需要投入较多的学习成本和维护成本，需要处理分布式系统的复杂性，并需要注意版本兼容性和开源社区的不成熟等问题。

在选择是否使用Spring Cloud时，需要根据实际需求和情况做出权衡。

如需了解更多关于使用SpringCloud的优劣分析，建议咨询资深编程技术人员。

使用SpringCloud来实现微服务架构有何优势

使用SpringCloud来实现微服务架构有何优势随着互联网的快速发展，越来越多的公司开始使用微服务架构来构建其应用程序。

微服务架构是一种分布式的架构风格，它将应用程序拆分成一组小型服务，每个服务都可以独立运行和扩展。

这种架构风格具有很多优点，例如能够提高应用程序的可靠性、可扩展性和吞吐量等。

在本文中，我将介绍如何使用SpringCloud来实现微服务架构，并说明其优势。

1. 什么是SpringCloudSpringCloud是一个基于SpringBoot构建的微服务框架。

它由多个子项目组成，每个子项目都提供了一组不同的特性，例如配置管理、断路器、服务发现、网关路由、消息总线等。

SpringCloud将这些特性组合在一起，为开发人员提供了一种简单、灵活、可扩展的微服务架构方案。

2. 使用SpringCloud的优势2.1 分布式系统的复杂性降低了微服务架构中的每个服务都可以独立运行和扩展，它们之间通过轻量级的通讯协议进行交互。

这种解耦和分离的方式降低了系统的复杂性。

通过使用SpringCloud提供的服务注册与发现、断路器、负载均衡等特性，可以更加方便地管理和控制服务之间的通讯，并保证系统的可靠性和可用性。

2.2 服务可扩展性和迁移性更加容易由于微服务是按照业务功能拆分的，因此每个服务都可以独立扩展。

使用SpringCloud提供的负载均衡、服务注册与发现等特性，可以自动地为新服务分配负载，并保证整个系统的可用性。

另外，在不同的云环境中迁移微服务也变得更加容易。

2.3 更好的性能和可靠性由于微服务是按照业务功能拆分的，每个服务都可以独立运行和扩展。

这种方式可以提升系统的性能和可靠性。

使用SpringCloud提供的断路器、服务注册与发现、负载均衡等特性，可以保证系统在大流量下的健壮性和稳定性。

2.4 更加灵活和敏捷微服务架构中的每个服务都可以独立运行和扩展，这种方式可以大大提升开发的灵活性和敏捷性。

微服务spring cloud的性能问题解决之道

微服务spring cloud的性能问题解决之道
李万鸿
太极图告诉我们：万事都存在矛盾，利弊是统一的。

微服务是先进的开发技术，springcloud是一个优秀实用的微服务开发框架，提供了注册、路由、负载均衡、配置等完善的功能，开发方便，值得使用。

不过也存在一个问题，就是springcloud的性能低，响应速度慢，那么如何解决呢？
这是springcloud的架构图，从上图可见，zuul是微服务的入口，负责到微服务的路由和权限功能，优点也是弱点，这正是其速度慢的重要原因之一。

Hystrix来实现断路器的功能。

Hystrix是Netflix开源的微服务框架套件之一，该框架目标在于通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。

凡事有利有弊，Hystrix需要控制微服务的访问，带来延迟，影响性能。

那么zuul和hystrix可以去掉吗？然也，完全可以不使用它们，系统的性能会有大的提升。

Zuul的路由功能完全可由eureka完成，eureka提供微服务的注册和发现，具有路由功能。

Hystrix的故障监控在很多情况下是多余的，不是互联网高并发场景，完全可以不用hystrix。

监控系统会发现问题，快速解决才是关键。

因此，从以上2个方面进行优化，完全可以提升springcloud的性能，为实际开发提供强劲的支持。

太极阴阳，矛盾统一，有利有弊，灵活应对。

基于Spring Cloud微服务的实现方法和优化方案

基于Spring Cloud微服务的实现方法和优化方案近年来，微服务架构已经被广泛应用于互联网技术领域。

而Spring Cloud作为其中的一个重要的微服务框架，其使用方便、功能丰富、性能优异、易扩展等优点已经被越来越多的企业所使用。

本文将主要介绍基于Spring Cloud微服务的实现方法和优化方案。

一、Spring Cloud微服务框架概述Spring Cloud是一个基于Spring Boot的分布式系统开发框架，主要由一些独立的子项目组成，例如Eureka，Hystrix，Zuul等。

Spring Cloud为开发人员提供了一种快速、便捷的开发分布式系统的方式，涵盖了从注册中心、资源调度、服务化、负载均衡、熔断等多方面的功能支持。

此外，Spring Cloud还提供了一些预定义好的模块和服务，以满足开发人员在开发过程中的需求。

二、基于Spring Cloud的微服务实现1、注册中心Spring Cloud基于Eureka实现了服务注册与发现，Eureka由两部分组成，即Eureka Server和Eureka Client。

Eureka Server提供服务注册服务，各个节点启动后，会在Eureka Server中进行注册，Eureka Server中注册表中维护了所有可用服务节点的信息，当有节点启动或停止时，Eureka Server能够自动进行注册表更新。

2、服务消费在Spring Cloud中可以通过注解@FeignClient来实现服务的消费。

Feign是Spring Cloud中的一种轻量级的HTTP客户端，可以支持HTTP请求和响应。

通过@FeignClient注解将服务接口定义成一个Feign客户端，然后使用起来就像调用本地方法一样简单。

3、负载均衡Spring Cloud自带了负载均衡的支持，通过Ribbon来实现。

在调用服务的时候，会自动的实现负载均衡，根据服务请求的次数、服务提供方的状态进行判断，将请求发送到最合适的服务节点上。

基于SpringCloud的微服务架构设计与性能优化

基于SpringCloud的微服务架构设计与性能优化一、引言随着互联网的快速发展，微服务架构作为一种新兴的软件架构风格，逐渐成为企业开发中的主流选择。

SpringCloud作为目前最流行的微服务框架之一，提供了丰富的组件和功能，帮助开发人员快速搭建和部署微服务系统。

然而，在实际应用中，如何设计一个高性能的微服务架构并进行性能优化，是每个开发团队都需要面对的挑战。

二、微服务架构设计1. 服务拆分在设计微服务架构时，首先需要考虑的是如何进行服务拆分。

合理的服务拆分可以提高系统的灵活性和可维护性，降低各个微服务之间的耦合度。

根据业务功能和业务域模型，将系统拆分成多个独立的微服务单元，每个微服务负责一个特定的业务功能。

2. 服务注册与发现SpringCloud提供了Eureka、Consul等注册中心来实现微服务的注册与发现。

通过注册中心，各个微服务可以动态地注册和发现其他微服务，实现了微服务之间的通信和协作。

合理配置注册中心可以提高系统的可用性和扩展性。

3. 负载均衡在微服务架构中，负载均衡是非常重要的一环。

通过负载均衡可以将请求均匀地分发到不同的微服务实例上，提高系统的稳定性和性能。

SpringCloud提供了Ribbon等负载均衡组件，可以轻松实现负载均衡功能。

4. 熔断与降级为了防止某个微服务出现故障导致整个系统崩溃，需要引入熔断和降级机制。

Hystrix是SpringCloud提供的熔断器组件，可以在微服务之间进行熔断和降级处理，保证系统在异常情况下依然能够正常运行。

三、性能优化1. 数据库优化数据库是系统性能的关键瓶颈之一。

通过合理设计数据库表结构、建立索引、使用缓存等方式可以提高数据库查询效率。

此外，采用数据库读写分离、分库分表等策略也可以有效减轻数据库压力。

2. 缓存优化在微服务架构中，缓存起着至关重要的作用。

通过使用Redis、Memcached等缓存组件，可以将热点数据缓存起来，减少对数据库的频繁访问，提高系统响应速度。

SpringCloudGateway拦截器遇到的小坑汇总

SpringCloudGateway拦截器遇到的小坑汇总Spring Cloud Gateway是一个基于Spring Framework 5，Spring Boot 2和Project Reactor构建的API网关。

它可以实现请求路由、限流、熔断等功能，是构建微服务架构的重要组件之一、在使用Spring Cloud Gateway进行开发时，可能会遇到一些坑，下面将列举一些方便开发者了解和解决。

1.配置顺序问题在使用Spring Cloud Gateway配置路由时，需要注意配置顺序的问题。

如果两个路由规则的匹配条件相似，而且顺序错乱，可能会导致路由规则无法正确匹配。

因此，需要将具体的路由规则放在前面，而将通用的路由规则放在后面，以免匹配错误。

2.路由配置端口问题3.添加全局过滤器在使用Spring Cloud Gateway进行开发时，可以通过添加全局过滤器来实现一些通用的功能。

例如，可以添加一个全局日志过滤器来记录请求日志。

可以通过实现GatewayFilterFactory接口来创建自定义的全局过滤器。

4.转发请求头问题在进行请求转发时，如果需要将原始请求的一些请求头传递到目标URL，可以通过添加以下配置来实现：spring.cloud.gateway.forward-headers-strategy=native5.缓存问题当使用Gateway进行请求转发时，如果目标URL的响应结果有缓存，需要注意在缓存配置中添加适当的Cache-Control或ETag响应头，避免返回缓存结果。

6.限流问题在进行请求限流时，可以使用Spring Cloud Gateway的限流过滤器来实现。

可以通过添加以下配置来启用限流：spring.cloud.gateway.filter.headers.enabled=truespring.cloud.gateway.filter.headers.header-name=x-countspring.cloud.gateway.filter.headers.quota=107.自定义路由规则问题如果希望使用复杂的逻辑来配置路由规则，可以使用自定义的Predicate实现来实现。

SpringCloud：Feign调用接口不稳定问题以及如何设置超时

SpringCloud：Feign调⽤接⼝不稳定问题以及如何设置超时1. Feign调⽤接⼝不稳定报错Caused by: .SocketException: Software caused connection abort: recv failedat .SocketInputStream.socketRead0(Native Method)at .SocketInputStream.socketRead(SocketInputStream.java:116)at .SocketInputStream.read(SocketInputStream.java:170)at .SocketInputStream.read(SocketInputStream.java:141)at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282)at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)at feign.httpclient.ApacheHttpClient.execute(ApacheHttpClient.java:87)at flix.feign.ribbon.RetryableFeignLoadBalancer$1.doWithRetry(RetryableFeignLoadBalancer.java:92) at flix.feign.ribbon.RetryableFeignLoadBalancer$1.doWithRetry(RetryableFeignLoadBalancer.java:77) at org.springframework.retry.support.RetryTemplate.doExecute(RetryTemplate.java:286)at org.springframework.retry.support.RetryTemplate.execute(RetryTemplate.java:163)at flix.feign.ribbon.RetryableFeignLoadBalancer.execute(RetryableFeignLoadBalancer.java:77)at flix.feign.ribbon.RetryableFeignLoadBalancer.execute(RetryableFeignLoadBalancer.java:48)at flix.client.AbstractLoadBalancerAwareClient$1.call(AbstractLoadBalancerAwareClient.java:109)at flix.loadbalancer.reactive.LoadBalancerCommand$3$1.call(LoadBalancerCommand.java:303)at flix.loadbalancer.reactive.LoadBalancerCommand$3$1.call(LoadBalancerCommand.java:287)at rx.internal.util.ScalarSynchronousObservable$3.call(ScalarSynchronousObservable.java:231)at rx.internal.util.ScalarSynchronousObservable$3.call(ScalarSynchronousObservable.java:228)at rx.Observable.unsafeSubscribe(Observable.java:10211)at rx.internal.operators.OnSubscribeConcatMap$ConcatMapSubscriber.drain(OnSubscribeConcatMap.java:286)at rx.internal.operators.OnSubscribeConcatMap$ConcatMapSubscriber.onNext(OnSubscribeConcatMap.java:144)at flix.loadbalancer.reactive.LoadBalancerCommand$1.call(LoadBalancerCommand.java:185)at flix.loadbalancer.reactive.LoadBalancerCommand$1.call(LoadBalancerCommand.java:180)at rx.Observable.unsafeSubscribe(Observable.java:10211)at rx.internal.operators.OnSubscribeConcatMap.call(OnSubscribeConcatMap.java:94)at rx.internal.operators.OnSubscribeConcatMap.call(OnSubscribeConcatMap.java:42)at rx.Observable.unsafeSubscribe(Observable.java:10211)at rx.internal.operators.OperatorRetryWithPredicate$SourceSubscriber$1.call(OperatorRetryWithPredicate.java:127)at rx.internal.schedulers.TrampolineScheduler$InnerCurrentThreadScheduler.enqueue(TrampolineScheduler.java:73)at rx.internal.schedulers.TrampolineScheduler$InnerCurrentThreadScheduler.schedule(TrampolineScheduler.java:52)at rx.internal.operators.OperatorRetryWithPredicate$SourceSubscriber.onNext(OperatorRetryWithPredicate.java:79)at rx.internal.operators.OperatorRetryWithPredicate$SourceSubscriber.onNext(OperatorRetryWithPredicate.java:45)at rx.internal.util.ScalarSynchronousObservable$WeakSingleProducer.request(ScalarSynchronousObservable.java:276)at rx.Subscriber.setProducer(Subscriber.java:209)at rx.internal.util.ScalarSynchronousObservable$JustOnSubscribe.call(ScalarSynchronousObservable.java:138)at rx.internal.util.ScalarSynchronousObservable$JustOnSubscribe.call(ScalarSynchronousObservable.java:129)at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:48)at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:48)at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:48)at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)at rx.Observable.subscribe(Observable.java:10307)at rx.Observable.subscribe(Observable.java:10274)at rx.observables.BlockingObservable.blockForSingle(BlockingObservable.java:445)at rx.observables.BlockingObservable.single(BlockingObservable.java:342)at flix.client.AbstractLoadBalancerAwareClient.executeWithLoadBalancer(AbstractLoadBalancerAwareClient.java:117)at flix.feign.ribbon.LoadBalancerFeignClient.execute(LoadBalancerFeignClient.java:63)at feign.SynchronousMethodHandler.executeAndDecode(SynchronousMethodHandler.java:97)... 117 common frames omittedfeign在调⽤时，会有不稳定的情况出现，时⽽出现接⼝调不通。

解决启用Spring-Cloud-OpenFeign配置可刷新项目无法启动的问题

解决启⽤Spring-Cloud-OpenFeign配置可刷新项⽬⽆法启动的问题本篇⽂章涉及底层设计以及原理，以及问题定位，⽐较深⼊，篇幅较长，所以拆分成上下两篇：上：问题简单描述以及 Spring Cloud RefreshScope 的原理下：当前 spring-cloud-openfeign + spring-cloud-sleuth 带来的 bug 以及如何修复最近在项⽬中想实现 OpenFeign 的配置可以动态刷新（主要是 Feign 的 Options 配置），例如：feign:client:config:default:# 链接超时connectTimeout: 500# 读取超时readTimeout: 8000我们可能会观察到调⽤某个 FeignClient 的超时时间不合理，需要临时修改下，我们不想因为这种事情重启进程或者刷新整个 ApplicationContext，所以将这部分配置放⼊ spring-cloud-config 中并使⽤动态刷新的机制进⾏刷新。

官⽅提供了这个配置⽅法，参考：即在项⽬中增加配置：feign.client.refresh-enabled: true但是在我们的项⽬中，增加了这个配置后，启动失败，报找不到相关 Bean 的错误：Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'feign.Request.Options-testService1Client'availableat org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:863)at org.springframework.beans.factory.support.AbstractBeanFactory.getMergedLocalBeanDefinition(AbstractBeanFactory.java:1344)at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:309)at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:213)at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1160)at org.springframework.cloud.openfeign.FeignContext.getInstance(FeignContext.java:57)at org.springframework.cloud.openfeign.FeignClientFactoryBean.getOptionsByName(FeignClientFactoryBean.java:363)at org.springframework.cloud.openfeign.FeignClientFactoryBean.configureUsingConfiguration(FeignClientFactoryBean.java:195)at org.springframework.cloud.openfeign.FeignClientFactoryBean.configureFeign(FeignClientFactoryBean.java:158)at org.springframework.cloud.openfeign.FeignClientFactoryBean.feign(FeignClientFactoryBean.java:132)at org.springframework.cloud.openfeign.FeignClientFactoryBean.getTarget(FeignClientFactoryBean.java:382)at org.springframework.cloud.openfeign.FeignClientFactoryBean.getObject(FeignClientFactoryBean.java:371)at mbda$registerFeignClient$0(FeignClientsRegistrar.java:235)atorg.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.obtainFromSupplier(AbstractAutowireCapableBeanFactory.java:1231) atorg.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1173) atorg.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:564) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:524) ... 74 more问题分析通过这个 Bean 名称，其实可以看出来这个 Bean 是我们开始提到要动态刷新的 Feign.Options，⾥⾯有连接超时、读取超时等配置。

微服务中的异常处理及故障排除策略

微服务中的异常处理及故障排除策略随着现代软件架构的发展，微服务架构已经成为了当今领先的软件开发模式之一。

在微服务架构中，每个服务都具有独立性和可替换性，可以灵活地针对不同的业务场景进行扩展和升级。

然而，微服务的灵活性也意味着它面临着更多的异常和故障，因此在微服务架构中的异常处理和故障排除策略愈发重要。

一、微服务异常处理在微服务架构中，由于不同的服务之间相互依赖，当其中一个服务出现异常时，可能会引发整个系统的崩溃。

因此，异常处理是非常关键的。

微服务异常处理应该具备以下几个方面：1. 异常类型的分类不同类型的异常需要不同的处理方式。

例如，网络连接异常需要重新请求，数据库异常可能需要回滚等等。

因此，对异常类型进行分类，并制定相应的处理策略十分必要。

2. 异常信息的传递当出现异常时，需要及时将异常信息传递给相关人员，以便调试和排查问题。

在微服务中，由于存在多个服务之间的调用，因此异常信息的传递和跟踪也需要得到特别的关注。

3. 异常处理机制针对不同的异常类型，需要制定相应的处理机制。

例如，对于业务异常，可以通过抛出异常的方式来提示用户；对于程序异常，可以捕获并记录异常信息等等。

4. 自动化的异常处理在微服务架构中，由于存在大量的服务，手动处理每一个异常是不现实的。

因此，需要利用自动化工具来对异常进行处理。

例如，可以使用ELK等工具来对服务的日志进行监控和分析。

二、微服务故障排除策略在微服务架构中，因为存在多个服务的相互依赖，因此当一些服务发生故障时，可能会导致整个系统不可用。

为了保证系统的稳定性和可用性，需要制定相应的故障排除策略。

1. 监控和告警监控是发现故障的第一步。

在微服务架构中，可以使用服务网关等工具来对服务进行监控和统计。

当出现故障时，需要及时发送告警信息给相关负责人员，并尽快进行处理。

2. 故障定位和诊断当出现故障时，需要有相应的定位和诊断工具来快速找到故障点。

例如，可以使用分布式跟踪工具来对服务之间的调用进行跟踪和诊断。

springcloud项目占用内存好几个G导致服务器崩溃的问题

springcloud项⽬占⽤内存好⼏个G导致服务器崩溃的问题问题描述springcloud项⽬部署或调试时，占⽤的内存特别多。

当部署到服务器上去后，有可能导致服务器内存占⽤过多⽽崩溃。

解决⽅案1.本地调试时，IDEA中添加参数以减少本地内存使⽤按照下图点击，添加参数-Xms64m -Xmx128m2.远程上线时，命令⾏添加参数 2.1单个服务直接部署例如使⽤nohup执⾏时,在java与-jar之间添加参数-Xms64m -Xmx128mnohup java -Xms64m -Xmx128m -jar x.xx-xx.jar &2.2对每个服务使⽤dockerFile编排FROM java:8COPY *.jar /security.jarCMD ["--server.port=8080"]EXPOSE 8080ENTRYPOINT ["java","-Xms64m","-Xmx256m","-jar","security.jar"]这是⼀个完整的dockerfile⽂件，最后⼀⾏中添加的两个参数⽤于控制内存⼤⼩参数详解设置JVM内存的参数有四个：-Xmx: Java Heap最⼤值，默认值为物理内存的1/4，最佳设值应该视物理内存⼤⼩及计算机内其他内存开销⽽定；-Xms: Java Heap初始值，Server端JVM最好将-Xms和-Xmx设为相同值，开发测试机JVM可以保留默认值；-Xmn: Java Heap Young区⼤⼩，不熟悉最好保留默认值；-Xss: 每个线程的Stack⼤⼩，不熟悉最好保留默认值；到此这篇关于springcloud项⽬占⽤内存好⼏个G导致服务器崩溃的问题的⽂章就介绍到这了,更多相关springcloud占⽤内存过⾼内容请搜索以前的⽂章或继续浏览下⾯的相关⽂章希望⼤家以后多多⽀持！。

spring-cloud-gateway启动踩坑及解决

spring-cloud-gateway启动踩坑及解决⽬录spring-cloud-gateway启动踩坑1、webflux与mvc不兼容2、webflux使⽤netty作为容器3、后来实验了下很坑得springcloudgateway异常spring-cloud-gateway启动踩坑本⼈使⽤的版本是2.1.2,以下只记录⼏个⼩问题，但确实实实在在的把个⼈恶⼼的要死要活的找不到办法，⼏经挣扎，最终解决。

更可恨的是开发的过程中，没有出现异常，后来由于项⽬组其它⼈加了依赖，不知不觉对项⽬的兼容造成了英雄，真的是被撞的头破⾎流，才找到原因1、webflux与mvc不兼容如类路径中引⽤了webmvc会导致项⽬启动不起来异常1org.springframework.context.ApplicationContextException: Unable to start web server; nested exception isorg.springframework.context.ApplicationContextException: Unable to start ServletWebServerApplicationContext due to missingServletWebServerFactory bean.异常2Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type'org.springframework.core.convert.ConversionService' available: expected at least 1 bean which qualifies as autowire candidate.Dependency annotations: {@org.springframework.beans.factory.annotation.Qualifier(value=webFluxConversionService)}解决办法，找到依赖webmvc的jar包，将webmvc排除即可，如<dependency><groupId>${project.groupId}</groupId><artifactId>core</artifactId><version>${project.version}</version><exclusions><exclusion><groupId>org.springframework</groupId><artifactId>spring-webmvc</artifactId></exclusion></dependency>2、webflux使⽤netty作为容器不能使⽤tomcat，表现形式为⽹关⼯作转发正常，⽬标服务返回数据也正常，但是⽹关会⽆法解析返回的数据并最终由⽹关将数据返回给客户端ng.ClassCastException: org.springframework.core.io.buffer.DefaultDataBufferFactory cannot be cast totyDataBufferFactory解决办法找到将tomcat依赖进来的jar包，然后排除即可。

springcloud之Feign超时问题的解决

springcloud之Feign超时问题的解决问题背景最近公司项⽬有个功能需进⾏三层Feign调⽤，且还要调外部接⼝，延迟挺⼤，造成Feign⼀直提⽰Read timed out executing POST。

feign.RetryableException: Read timed out executing POST http://******at feign.FeignException.errorExecuting(FeignException.java:67)at feign.SynchronousMethodHandler.executeAndDecode(SynchronousMethodHandler.java:104)at feign.SynchronousMethodHandler.invoke(SynchronousMethodHandler.java:76)at feign.ReflectiveFeign$FeignInvocationHandler.invoke(ReflectiveFeign.java:103)at com.sun.proxy.$Proxy113.getBaseRow(Unknown Source)Caused by: .SocketTimeoutException: Read timed outat .SocketInputStream.socketRead0(Native Method)at .SocketInputStream.socketRead(SocketInputStream.java:116)at .SocketInputStream.read(SocketInputStream.java:170)at .SocketInputStream.read(SocketInputStream.java:141)at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)at java.io.BufferedInputStream.read(BufferedInputStream.java:345)at .www.http.HttpClient.parseHTTPHeader(HttpClient.java:704)at .www.http.HttpClient.parseHTTP(HttpClient.java:647)at .www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1569)at .www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)at .HttpURLConnection.getResponseCode(HttpURLConnection.java:480)at feign.Client$Default.convertResponse(Client.java:152)at feign.Client$Default.execute(Client.java:74)解决⽅案⾸先，我们看下Feign的简介Feign 是⼀个声明式的web服务客户端，这便得编写web服务客户端更容易，使⽤Feign 创建⼀个接⼝并对它进⾏注解，它具有可插拔的注解⽀持包括Feign注解与JAX-RS注解，Feign还⽀持可插拔的编码器与解码器，Spring Cloud 增加了对 Spring MVC的注解，Spring Web 默认使⽤了HttpMessageConverters, Spring Cloud 集成 Ribbon 和 Eureka 提供的负载均衡的HTTP客户端 Feign.这么说吧，Feign接⼝调⽤分两层，Ribbon的调⽤和Hystrix调⽤，理论上设置Ribbon的时间即可，但是Ribbon的超时时间和Hystrix的超时时间需要结合起来，按照⽊桶原则最低的就是Feign的超时时间，建议最好配置超时时间⼀致。

SpringCloudOpenFeignPost请求400错误解决方案

SpringCloudOpenFeignPost请求400错误解决⽅案在微服务开发中SpringCloud全家桶集成了OpenFeign⽤于服务调⽤，SpringCloud的OpenFeign使⽤SpringMVCContract来解析OpenFeign的接⼝定义。

但是SpringMVCContract的Post接⼝解析实现有个巨坑，就是如果使⽤的是@RequestParam传参的Post请求，参数是直接挂在URL上的。

问题发现与分析最近线上服务器突然经常性出现CPU⾼负载的预警，经过排查发现⽇志出来了⼤量的OpenFeign跨服务调⽤出现400的错误（HTTP Status 400）。

⼀般有两种情况：nginx 返回400java应⽤返回400通过分析发现400是java应⽤返回的，那么可以确定是OpenFeign客户端发起跨服务请求时出现异常了。

但是查看源码发现出现这个问题的服务接⼝⾮常简单，就是⼀个只有三个参数的POST请求接⼝，这个错误并不是必现的错误，⽽是当参数值⽐较长（String）的时候才会出现。

所以可以初步确认可能是参数太长导致请求400，对于POST请求因参数太长导致400错误⾮常疑惑，POST请求除⾮把参数挂在URL上，否则不应该出现400才对。

问题排查为了验证上⾯的猜测，⼿写了⼀个简单的⽰例，在验证过程中特意开启了OpenFeign的debug⽇志。

⾸先编写服务接⼝这是⼀个简单的Post接⼝，仅有⼀个参数（这⾥的代码仅⽤于验证，⾮正式代码）@FeignClient(name = "user-service-provider")public interface HelloService {@PostMapping("/hello")public String hello(@RequestParam("name") String name);}编写服务服务这⾥随便写⼀个Http接⼝即可（同上，代码仅⽤于验证）@SpringBootApplication@RestControllerpublic class Starter {@RequestMapping("/hello")public String hello(String name) {return "User服务返回值：Hello " + String.valueOf(name);}public static void main(String[] args) {SpringApplication.run(Starter.class, args);}}服务注册并调⽤将服务注册到注册中⼼上，通过调⽤hello服务@Autowiredpublic HelloService helloService;@RequestMapping("/hello")public String hello(String name) {return helloService.hello(name);}通过⽇志可以发现，SpringCloud集成OpenFeign的POST请求确实是直接将参数挂在URL上，如下图：正是因为这个巨坑，导致了线上服务器经常性⾼CPU负载预警。

生产级基于SpringCloud微服务架构性能优化实战，建议收藏

生产级基于SpringCloud微服务架构性能优化实战，建议收藏前言本文将从Tomcat性能优化，SpringCloud开启重试机制，Zuul网关性能参数优化，Ribbon性能参数优化，Feign与Hystrix性能优化等五个方面分享在生产环境如何做好SpringCloud性能优化。

Tomcat性能优化一般基于SpringCloud的微服务能够脱离传统的tomcat，独立跑起来，SpringBoot功不可没，其原理是SpringBoot内嵌了tomcat（当然可以换成其他servlet容器，如jetty），能够以java -jar形式就能跑起来。

所以针对每个springboot服务，我们需要对tomcat的一些参数进行优化，以下是楼主项目组优化的tomcat参数配置，供大家参考。

server: tomcat: accept-count: 10000 max-threads: 5000 max-connections: 5000tomcat参数说明：maxThreads：tomcat起动的最大线程数，即同时处理的任务个数，默认值为200acceptCount：当tomcat起动的线程数达到最大时，接受排队的请求个数，默认值为100 maxThreads，acceptCount参数应用场景场景一tomcat的请求线程数未达到maxThreads最大阀值，tomcat新建线程处理此请求。

场景二tomcat的请求线程数达到maxThreads最大阀值，tomcat会把当前请求放入队列，等待空闲线程处理该请求。

场景三tomcat的请求线程数达到maxThreads最大阀值，并且请求队列以达到acceptCount的最大阀值，tomcat拒绝请求，返回连接拒绝（connection refused）。

maxThreads调优一般说服务器性能要从两个方面说起：1、cpu计算型指标如果是cpu计算型请求，那么系统响应时间的主要限制就是cpu的运算能力，此时maxThreads应该尽量设的小，降低同一时间内争抢cpu的线程个数，可以提高计算效率，提高系统的整体处理能力2、io密集型指标如果是IO密集型请求，例如数据库读写，那么响应时间的主要限制就变为等待外部资源，此时maxThreads应该尽量设的大，这样才能提高同时处理请求的个数，从而提高系统整体的处理能力。