spring cloud简介

spring cloud构建于spring boot之上，很容易上手并应用于生产之中。 spring cloud是一系列框架的有序集合。利用spring boot开发的便利性巧妙的简化了分布式基础设施的开发。如服务发现注册，配置中心，消息总线，负载均衡，断路器，数据监控等。将各家公司开发的比较成熟的，经得起实际考验的服务框架组合起来。

spring cloud是微服务架构的一站式解决方案。

版本号为伦敦地铁站的站名, spring cloud要求运行在某一特定spring boot版本下

Release Train Boot Version

Greenwich 2.1.x

Finchley 2.0.x

Edgware 1.5.x

Dalston 1.5.x

eureka

是Netflix开发的服务发现框架，spring cloud将其集成在spring-cloud-netflix中。

与 zookeeper对比

• 主要体现在zookeeper是CP, 当集群节点比较多时, zookeeper的一致性可能会把整个集群拖垮。eureka是AP, 将可用性做到了极致,即使所有的eureka server都宕机, 也能对外提供服务, 因为本地保存了一份服务列表

项目中使用：

在Application启动类上添加:@EnableEurekaServer注解

eureka.client.register-with-eureka=false

eureka.client.fetch-registry=false

Eureka server默认90秒(三个心跳周期)内没有检测到某服务列表中的某微服务,则会自动将该微服务从服务列表中删除. 在短时间内若eureka server丢失服务过多,其会自动进入自我保护模式,当收到的心跳数量恢复到阈值以上时,其会自动退出自我保护模式。

eureka.server.renewal-percent-threshold=0.85(default), 收到的心跳数量小于85%时.则进入自动保护模式

eureka.server.enable-self-preservation=true(default)

新添加一个提供者或者消费者需要60秒才能放到服务注册中心

openfeign 和 Ribbon

spring cloud之前版本使用的是feign,现在改为openfeign了,open feign内置了ribbon

@FeignClient("provider-depart")
public interface DepartService {
}

在client中直接注入该service即可, 在client的启动类中添加@EnableFeignClients(basePackages = "指定service接口所在包")注解

feign.client.config.default.connect-timeout=5000 #连接超时时限
feign.client.config.default.read-timeout=10000 #读取响应超时时限

// 开启压缩
feign.compression.request.enabled=true
feign.compression.request.mime-types=["text/xml","application/xml","application/json"]
feign.compression.request.min-request-size=2048
feign.compression.response.enabled=true

Ribbon内置负载均衡算法

• RoundRobinRule(轮询策略,默认负载均衡策略)
• RandomRule (随机策略)
• RetryRule: 安装RoundRobin获取Provider,若获取失败,则在指定的时限内重试,默认时限为500ms
• BestAvailableRule: 选择连接消费者最少的Provider连接
• AvailabilityFilterRule: 过滤掉处于断路器跳闸状态的Provider和超过连接极限的Provider,对剩余Provider采用轮询策略
• ZoneAvoidanceRule: 根据所在区域的Provider的性能选择可用Provider
• WeightedResponseTimeRule: "权重响应时间策略",根据每个Provider的平均响应时间计算其权重,越快权重越高.在刚启动时,

采用轮询策略,后面就根据权重进行选择了.

修改负载均衡策略

修改配置文件:ribon.NFLoadBalancerRuleClassName=com.netflix.loadbalancer.RandomRule
在配置类中:
@Bean
public IRule loadBalanceRule() {
return new RandomRule();
}

自定义负载均衡策略

a. 实现IRule接口

b. 重写choose(Object key)方法,

private ILoadBalancer lb; // 可以获取到所有的可用的server

Hysttix熔断机制

• 雪崩效应

在复杂的系统中,会有很深的调用链路,如果链路中的某个服务不可用或延迟过高,且当有越来越多的请求,则会导致过度占用系统的线程,IO等资源.最终导致系统崩溃

熔断机制就是为了解决雪崩效应的, 熔断分两种,预熔断和及时熔断

• 服务降级

服务降级是请求发生问题时的一种增强用户体验的一种方式. 发生服务熔断一定会发生服务降级.服务降级不一定会发生服务熔断

spring cloud是通过hystrix来实现服务降级和熔断的, 对应的依赖: spring-cloud-starter-netflix-hystrix

在启动类中添加: @EnableCircuitBreaker

由于启动类注解过多,可以添加:@SpringCloudApplication, 其包含: @SpringBootApplication, @EnableDiscoveryClient和@EnableCircuitBreaker

openfeign的服务降级

@Service
@FeignClient(value = "provider01", fallback = DepartFallback.class)
@RequestMapping("/provider/depart")
public interface DepartService {
    @GetMapping("/getDepartName")
    public String getDepartName();
}


@Component
@RequestMapping("/fallback/depart")// 注意这个path一定要写,要不然会用DepartService中的path,造成路径重复
public class DepartFallback implements DepartService {
@Override
public String getDepartName() {
return "fall back depart name";
}
}

hystrix服务降级有两种方式:

• fallbackMethod

在controller中,
@HystrixCommand(fallbackMethod = "getHystrixHandle")
@GetMapping("/get/{id}")
public Depart getHandle(@PathVariable("id") int id) {
String url = "http://localhost:8081/provider/depart/get/" + id;
return restTemplate.getForObject(url, Depart.class);
}

// 服务降级方法
public Depart getHystrixHandle(@PathVariable("id") int id) {
Depart depart = new Depart();
depart.setId(id);
depart.setName("no this depart");
return depart;
}

• fallbackFactory

1. 自定义factory实现FallbackFactory<DepartService> {
@Override
public DepartService create(Throwable throwable) {
return new DepartService() {
//CRUD方法的实现
}
}
2. 在DepartService上添加:
@FeignClient(value = "abcmsc-provider-depart", fallbackFactory = DepartFallbackFactory.class)

三种熔断的优先级

openfeign 的fallback > fallback factory > fallback method

hystrix高级配置

隔离策略(HystrixCommandProperties)

防止提供者被熔断,防止大量客户端请求被阻塞

hystrix.command.default.execution.isolation.strategy=thread/semaphore

隔离请求的方式有两种

• 线程隔离(default)

hystrix创建一个依赖线程池,每个请求可以获得一个线程,超过上限则阻塞
默认超时时限为1000毫秒,hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=1000
hystrix.command.default.execution.isolation.thread.interruptOnTimeout=true//default, 超时是否中断
hystrix.command.default.execution.isolation.thread.interruptOnCancel=false/default, 取消是否中断

• 信号量隔离

hystrix为每个依赖创建一个信号量(其实就是一个整型的数字),每过来一个则减1,用完则阻塞

对比

线程隔离中对依赖的请求线程与调用线程是不同的线程,而信号量隔离是同一个线程,所以在复杂长链路中选线程隔离(速度快),短链路选信号量隔离

dashboard 监控仪表盘

对应依赖: spring-cloud-starter-netflix-hystrix-dashboard

启动类添加@EnableHystrixDashboard
http://localhost:8082/hystrix

项目中添加:

@Bean
public ServletRegistrationBean getServlet() {
HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();
ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet);
registrationBean.setLoadOnStartup(1);
registrationBean.addUrlMappings("/hystrix.stream");
registrationBean.setName("HystrixMetricsStreamServlet");
return registrationBean;
}
注意使用:http://localhost:8082/hystrix.stream

前面是对单个消费者进行监控,turbine可以对整个集群进行监控, turbine能够汇集监控信息,然后聚合提供给Hystrix Dashboard

a. 导入turbine依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-turbine</artifactId>
</dependency>
b. 在配置文件中配置turbine
turbine.appConfig=node01,node02 // 监控serviceId列表
turbine.aggregator.clusterConfig= default
turbine.clusterNameExpression="default"
c. 在启动类上添加@EnableTurbine注解

服务降级报警机制

无论哪种原因启用了服务降级, 系统都应该向管理员发出警报通知管理员

在发送短信之前,应先查看服务降级标识(以防有大量请求过来,都发生降级,造成发送无数条短信),这个标识应放在Redis中(双重检测锁)

zuul(微服务网关)

网关用于对请求进行鉴权,限流,路由,监控等

zuul主要提供请求的路由和与过滤功能

路由:对外部请求转发到具体的微服务主机,是外部访问微服务系统的统一入口

过滤:对外部请求进行干预

通过zuul, 访问消费者的接口就变成了:http://localhost:8083/consumer01/depart/getDepartName

注:consumer01为微服务名称

应用开启zuul代理模式:

@EnableZuulProxy,

添加依赖:spring-cloud-starter-netflix-zuul

路由策略配置

zuul:
prefix: /abc // 配置前缀,必须以"/"开始
ignored-services: "*" // 屏蔽所有微服务名称,即防止通过微服务名称访问
ignored-patterns: /**/list/** // 屏蔽路径
sensitive-headers: token // 指定token被屏蔽, 默认的是"Cookie", "Set-Cookie", "Authorization"
routes:
# 指定微服务的路由规则
abcmsc-consumer-depart-8080: /abc8080/**, 也可以写成"/**"
abcmsc-consumer-depart-8090: /abc8090/**
abcmsc-consumer-depart: /abc012/**

• 负载均衡

默认是轮询

• zuul的服务降级

实现FallbackProvider
@Component
public class ConsumerFallback implements FallbackProvider {
// 指定要降级的微服务名称
@Override
public String getRoute() {
// 对所有微服务降级
return "*";
// 仅对指定的微服务进行降级
// return "abcmsc-consumer-depart-8080";
}

// 定制降级响应
@Override
public ClientHttpResponse fallbackResponse(String route, Throwable cause) {
return new ClientHttpResponse() {
@Override
public HttpStatus getStatusCode() throws IOException {
// 返回状态常量
return HttpStatus.SERVICE_UNAVAILABLE;
}
@Override
public int getRawStatusCode() throws IOException {
// 返回状态码，这里为503
return HttpStatus.SERVICE_UNAVAILABLE.value();
}
@Override
public String getStatusText() throws IOException {
// 返回状态码对应的状态短语，这里为"Service Unavailable"
return HttpStatus.SERVICE_UNAVAILABLE.getReasonPhrase();
}
@Override
public void close() { }
@Override
public InputStream getBody() throws IOException {
// 设置降级信息
String msg = "fallback:" + ConsumerFallback.this.getRoute();
return new ByteArrayInputStream(msg.getBytes());
}
@Override
public HttpHeaders getHeaders() {
HttpHeaders headers = new HttpHeaders();
headers.setContentType(MediaType.APPLICATION_JSON);
return headers;
}
};
}
}

• 路由过滤

在路由前,中,后都可以对请求进行过滤

需要继承ZuulFilter
@Component
@Slf4j
public class RouteFilter extends ZuulFilter {
// 指定路由之前执行过滤
@Override
public String filterType() {
// 返回"pre"
return FilterConstants.PRE_TYPE;
}
@Override
public int filterOrder() {
// 在系统最小值-3的前面执行
return -5;
}
// 对请求通过过滤的后的逻辑
@Override
public Object run() throws ZuulException {
log.info("通过过滤");
return null;
}
// 对请求进行过滤器的核心逻辑
@Override
public boolean shouldFilter() {
// 获取请求上下文
RequestContext context =
RequestContext.getCurrentContext();
// 获取请求
HttpServletRequest request = context.getRequest();

// 获取请求参数
String user = request.getParameter("user");
// 获取请求URI
String uri = request.getRequestURI();

// 只有当请求访问的是/abc8080且user为空时是不能通过过滤的
if(uri.contains("/abc8080") && StringUtils.isEmpty(user)) {
log.warn("user用户为空");
// 指定当前请求未通过zuul过滤，默认值为true
context.setSendZuulResponse(false);
// 向客户端响应码401，未授权
context.setResponseStatusCode(HttpStatus.SC_UNAUTHORIZED);
return false;
}
return true;
}
}

zuul 限流

• 令牌桶限流

Guava的RateLimit, 会创建一个每秒产生多少个令牌的limit,如果尝试获取失败,则拦截

1. RouteFilter extends ZuulFilter
2. private static final RateLimiter rateLimiter = RateLimiter.create(2);
3. rateLimiter.tryAcquire()

• 多维请求限流

令牌桶限流粒度有点大,使用spring-cloud-zuul-ratelimit限流库可以做到细粒度限流:
<groupId>com.marcosbarbero.cloud</groupId>
<artifactId>spring-cloud-zuul-ratelimit</artifactId>
<version>2.2.3.RELEASE</version>
user:单位时间窗内经过该网关的用户数量限制
origin:客户端IP的限流,单位时间窗内经过该网关的IP数量限制
URL:单位时间窗内经过该网关的请求的URL数量限制

• 漏桶限流

水(请求)先进入到漏桶里,漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率.流出速率是一定的

zuul灰度发布

灰度发布是根据Eureka的元数据来实现的

a. consumer配置文件中添加:eureka.instance.metadata-map.host-mark=running-host
b. 在zuul server中添加该依赖:
<dependency>
<groupId>io.jmnarloch</groupId>
<artifactId>ribbon-discovery-filter-spring-cloud-starter</artifactId>
<version>2.1.0</version>
</dependency>
c. 在继承ZuulFilter的类中添加如下代码:
@Override
public Object run() throws ZuulException {
RequestContext context = RequestContext.getCurrentContext();
final HttpServletRequest request = context.getRequest();
String mark = request.getHeader("gray-mark");
String host = "running-host";
if (StringUtils.isNotBlank(mark) && "enable".equals(mark)) {
host = "gray-host";
}
RibbonFilterContextHolder.getCurrentContext().add("host-mark", host);
return null;
}
这样,根据客户端请求头中传递的gray-mark属性就可以实现该请求流向哪个consumer了

• 在zuul server集群的前端添加NGINX来做负载均衡

spring cloud config

client提交下载请求 --- config Server集群 --- 远程库(github) --- config server 集群将配置文件再组装 -- client 拉取重新组装过的组件

a. 新创建config server项目
导入:<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
application.properties配置文件中添加:
server.port=9999
spring.cloud.config.server.git.uri=git@github.com:MrShang/config.git
spring.cloud.config.server.git.timeout=5
spring.cloud.config.server.git.default-label=master
spring.cloud.config.server.git.private-key=~/.ssh/id_rsa
启动类添加@EnableConfigServer

注:启动config server之后可以通过:http://localhost:9999/application-consumer.yml访问到,还支持json,properties格式
b. 在consumer或者provider中添加config客户端依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
c. 将consumer或者provider的application.properties上传到远程Github仓库:git@github.com:MrShang/config.git
本地resources目录下面创建bootstrap.properties(不需要application.properties了)
spring.cloud.config.uri=http://localhost:9999
spring.cloud.config.label=master
spring.cloud.config.name=application-consumer
spring.cloud.config.profile=dev

自动刷新两种实现方式

1. github的web hooks功能(不推荐使用)

2. spring cloud bus

将服务和服务实例与分布式消息系统连接在一起的事件总线

流程: git远程库有配置修改,自动更新步骤

a. 向任意一台config client 发送bus-refresh 的POST请求

b. config client会通知到config server

c. config server调用Git 远程库拉取最新配置,并将最新配置传递给config client

d. 然后该config client把消息发送到消息总线系统(kafka)

e. 消息总线系统将消息同步到其他config client

config client的配置(bootstrap.xml)
spring.cloud.config.uri=http://localhost:9999
spring.cloud.config.label=master
spring.cloud.config.name=application-consumer
spring.cloud.config.profile=dev

spring.kafka.bootstrap-servers=
management.endpoints.web.exposure.include=bus-refresh

在用到变量的类添加@RefreshScope注解,如DepartController,DepartServiceImpl
在client端添加该依赖:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bus-kafka</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-actuator</artifactId>
</dependency>
发送bus-refresh的POST请求

调用跟踪链 spring cloud sleuth + zipkin

spring cloud sleuth可以实现针对spring cloud应用程序的分布式跟踪, 兼容zipkin, HTrace和基于日志的(ELK)跟踪

跟踪单元中涉及的三个重要概念,trace, span和 annotation

trace, trace是一个客户端发起响应的开始到收到响应结束为止的过程,称为一个trace

span, 一个trace包含调用了若干个微服务,span就是指在调用每一个微服务开始到收到微服务的请求的一个记录

系统分别为trace和span分配了一个64位长度的数字作为ID,即traceId 和 spanId

annotation: cs(client send), cr(client receive), sr(service receive), ss(service send)

sleuth + zipkin 日志采样

zipkin是Twitter开发的APM工具(Application Performance Management),用于日志的聚合,为用户提供UI界面

zipkin包括4个核心组件

a. Collector

处理外部系统发过来的信息,处理为zipkin内部的Span格式,以用于后续的存储,分析,展示

b. Storage

存储处理器收到的跟踪信息,可修改存储策略

c. API

通过API实现对系统的监控

d. UI

展示

客户端向zipkin日志发送方式

a. 添加zipkin依赖(其中包含sleuth)
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
<version>2.1.1.RELEASE</version>
</dependency>
b. 下载zipkin的jar包, 启动 java -jar zipkin.jar, http://localhost:9411/zipkin
c. 客户端配置文件添加属性
spring.sleuth.sampler.probability=1.0 //采样率,默认为0.1
spring.zipkin.base-url=http://localhost:9411/

也可以通过kafka向zipkin发送

客户端配置文件添加: spring.zipkin.sender.type=kafka

spring.kafka.bootstrap-servers=

zipkin启动: java -DKAFKA_BOOTSTRAP_SERVERS=http://kafkaURL:port/ -jar zipkin.jar