Spring cloud config的安全保护
生产环境中我们的配置中心肯定是不能随随便便被人访问的，我们可以加上适当的保护机制，由于微服务是构建在 Spring Boot 之上，所以整合 Spring Security是最方便的方式。 1、在 springcloud config server 项目添加依赖：
代码语言：javascript复制<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>2、在 springcloud config server 项目的 application.properties 中配置用户名密码：
代码语言：javascript复制spring.security.user.name=wkcto
spring.security.user.password=1234563、在 springcloud config client 上 bootstrap.properties 配置用户名和密码：
代码语言：javascript复制spring.cloud.config.username=wkcto
spring.cloud.config.password=123456Bus
在（5）Spring Cloud Config中，我们知道的配置文件可以通过Config Server存储到Git等地方，通过Config Client进行读取，但是我们的配置文件不可能是一直不变的，当我们的配置文件放生变化的时候如何进行更新？ 一种最简单的方式重新一下Config Client进行重新获取，但Spring Cloud绝对不会让你这样做的，Spring Cloud Bus正是提供一种操作使得我们在不关闭服务的情况下更新我们的配置。
SpringCloud Config Refresh
SpringCloud学习系列之五—–配置中心(Config)和消息总线(Bus)完美使用
不使用Spring Cloud Bus获取配置信息流程图:
使用Spring Cloud Bus获取配置信息流程图:
其他问题
请求瓶颈相关三个问题
问题一：Zuul端转发请求的线程数与后端Service处理请求的线程数不一致，它们之间是什么关系呢？ 问题二：Zuul为什么会在Serivce正常的情况下出现服务熔断呢？ 问题三：为什么后端Service的并发线程数量达到200后没有随并发用户数的进一步增大而增大呢？
下面，我们按照由易到难的顺序进行剖析这些问题，探究Zuul如何进行调优。 问题三 问题剖析 为什么后端Service的并发线程数量达到200后没有随并发用户数的增大而增大呢？ SpringBoot默认使用8.5版本的Tomcat作为内嵌的Web容器。因此Zuul或Service接收到的请求时，都是由Tomcat中Connector的线程池数量决定，也就是worker线程数。 Tomcat中默认的worker线程数的最大值为200（官方文档中有说明），可以在yaml中增加server.tomcat.max-threads属性来设置worker线程数的最大值。 配置调优 因此，问题三的解决方案是在Zuul端和Service端的yaml中增加如下配置：
代码语言：javascript复制#增大tomcat中worker的最大线程数量
server:
tomcat:
max-threads: 500
Service端完整的yaml配置文件：GitHub链接问题二 问题剖析 为什么Zuul会在Serivce正常的情况下出现服务熔断呢？ 默认情况下，当某微服务请求的失败比例大于50%（且请求总数大于20次）时，会触发Zuul中断路器的开启，后续对该微服务的请求会发生熔断，直到微服务的访问恢复正常。在Serivce正常时出现服务熔断，有可能是请求端或网络的问题，但通常是由于hystrix的信号量小于Zuul处理请求的线程数造成的。Zuul默认使用semaphores信号量机制作为Hystrix的隔离机制，当Zuul对后端微服务的请求数超过最大信号量数时会抛出异常，通过配置zuul.semaphore.max-semaphores可以设置Hystrix中的最大信号量数。也就是说zuul.semaphore.max-semaphores设置的值小于server.tomcat.max-threads，会导致hystrix的信号量无法被acquire，继而造成服务熔断。 问题解决 确保zuul.semaphore.max-semaphores属性值大于server.tomcat.max-threads。
