高速微服务器怎么设置

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

本文将从 Tomcat性能优化，SpringCloud开启重试机制，Zuul网关性能参数优化，Ribbon性能参数优化，Feign与Hystrix性能优化等 五个方面分享在生产环境如何做好SpringCloud性能优化。

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

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

tomcat参数说明：

maxThreads，acceptCount参数应用场景

场景一

场景二

场景三

maxThreads调优

一般说服务器性能要从两个方面说起：

1、cpu计算型指标

2、io密集型指标

所以大部分情况下，tomcat处理io型请求比较多，比如常见的连数据库查询数据进行接口调用。

另外，要考虑tomcat的并发请求量大的情况下，对于服务器系统参数优化，如虚拟机内存设置和linux的open file限制。

maxThreads设置多大合适？

我们知道线程过多，会导致cpu在线程切换时消耗的时间随着线程数量的增加越来越大；线程太少，服务器的请求响应吞吐量会急剧下降，所以maxThreads的配置绝对不是越大越好。

实际情况是设置maxThreads大小没有最优解，要根据具体的服务器配置，实际的应用场景不断的调整和优化。

acceptCount设置多大合适？

尽量与maxThreads的大小保持一致 ， 这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。

当使用URL进行路由时，则需要对zuul.host.connect-timeout-millis和zuul.host.socket-timeout-millis参数控制超时时间。

请求连接的超时时间

请求处理的超时时间

对所有操作请求都进行重试

对当前实例的重试次数，针对同一个服务实例，最大重试次数（不包括首次调用）

对下个实例的重试次数，针同其它的服务实例，最大重试次数（不包括首次server）

注意Hystrix断路器的超时时间需要大于ribbon的超时时间，不然不会触发重试

Feign和Ribbon在整合了Hystrix后，首次调用失败的问题？

目前楼主的强烈做法是： 禁用Hystrix的超时时间，设为false

还有一种是官方提倡的是 设置超时时间。

在实际的项目中亲测，这种方式也有不好的地方， 如请求时间超过5s会出现请求数据时有时无的情况 ，给用户的感觉是 系统不稳定，要求整改 。

另外，禁用hystrix，官方不推荐 。

hystrix超时设置原则

问题：一个http请求，如果feign和ribbon都配置了重试机制，异常情况下一共会请求多少次？

请求总次数 n 为feignClient和ribbon配置参数的笛卡尔积：

n(请求总次数) = feign(默认5次) * (MaxAutoRetries+1) * (MaxAutoRetriesNextServer+1)

其中+1是代表ribbon本身默认的请求。

其实二者的重试机制相互独立，并无联系。但是因为用了feign肯定会用到ribbon，所以feign的重试机制相对来说比较鸡肋，一般会关闭该功能。ribbon的重试机制默认配置为0，也就是默认是去除重试机制的，建议不要修改。

⑵ Spring微服务灰度发布（热部署）的实现（二）

接着上篇说，我们微服务中用到的nepxion discovery主要采用了三种灰度发布方式，一种是web图形化界面发布，二是zuul过滤器灰度发布，三是业务参数策略灰度发布。下面将重点介绍三种方式的实现。

一、web图形化界面灰度发布

因为我们项目用到了eureka注册中心，所以选择web图形化界面灰度发布比较合适。

1） 首先需要建立一个discovery控制台工程console, 端口为2222，控制台工程负责web图形化界面请求的处理，运行console工程。

2） 下载discovery ui,地址：https://github.com/Nepxion/DiscoveryUI，运行discovery UI，端口为8090

3）浏览器中输入localhost:8090,即可打开控制台，如下

注意：全链路灰度发布需要在“配置中心”下才可用。灰度发布配置中心，负责存储全链路灰度发布规则，并将规则推送到各个微服务中。而配置中心可用nacos，redis等，Discovery 中提供了相应配置中心的插件包。

二、zuul网关过滤器灰度发布

通过网关过滤器传递Http Header的方式传递全链路灰度路由规则。下面代码只适用于Zuul和Spring Cloud Gateway网关，Service微服务不需要加该方式。

三、业务参数在策略类中自定义灰度路由规则

通过策略方式自定义灰度路由规则。下面代码既适用于Zuul和Spring Cloud Gateway网关，也适用于Service微服务，同时全链路中网关和服务都必须加该方式

上面说了具体灰度规则发布方式，那究竟怎么定义灰度规则呢？？

规则是基于XML或者Json为配置方式，存储于本地文件或者远程配置中心，可以通过远程配置中心修改的方式达到规则动态化。其核心代码参考discovery-plugin-framework以及它的扩展、discovery-plugin-config-center以及它的扩展和discovery-plugin-admin-center等，规则示例

XML示例（Json示例见discovery-springcloud-example-service下的rule.json）

黑/白名单的IP地址注册的过滤规则

微服务启动的时候，禁止指定的IP地址注册到服务注册发现中心。支持黑/白名单，白名单表示只允许指定IP地址前缀注册，黑名单表示不允许指定IP地址前缀注册。规则如何使用，见示例说明

最大注册数的限制的过滤规则

微服务启动的时候，一旦微服务集群下注册的实例数目已经达到上限（可配置），将禁止后续的微服务进行注册。规则如何使用，见示例说明

黑/白名单的IP地址发现的过滤规则

微服务启动的时候，禁止指定的IP地址被服务发现。它使用的方式和“黑/白名单的IP地址注册的过滤规则”一致

版本访问的灰度发布规则

版本权重的灰度发布规则

全局版本权重的灰度发布规则

区域权重的灰度发布规则

全局区域权重的灰度发布规则

网关端全链路路由策略的灰度发布规则

注意 路由策略的入口有三个（以{"discovery-springcloud-example-a":"1.0", "discovery-springcloud-example-b":"1.0", "discovery-springcloud-example-c":"1.0;1.2"}）为例：

其作用的优先级为外界传入>网关Filter指定>配置中心或者本地rule.xml配置

您可以根据自己需求，自由定义灰度发布规则，灵活实现微服务的灰度发布。

源码位置：https://github.com/Nepxion/Discovery

⑶ 微服务架构是什么

微服务架构是一项在云中部署应用和服务的新技术。

大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。

微服务架构相关介绍：

微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。

在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。

微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。

如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。

服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。