Spring Cloud微服务体系的组成

Python016

Spring Cloud微服务体系的组成,第1张

Netflix Eureka是Spring Cloud服务注册发现的基础组件

Eureka提供RESTful风格(HTTP协议)的服务注册与发现

Eureka采用C/S架构,Spring Cloud内置客户端

启用应用,访问 http://localhost:8761

Eureka客户端开发要点

maven依赖spring-cloud-starter-netflix-eureka-client application.yml

配置eureka.client.service-url.defaultZone

入口类增加@EnableEurekaClient

先启动注册中心,在启动客户端,访问 localhost:8761查看eureka注册中心,看到客户端注册

Eureka名词概念

Register - 服务注册, 向Eureka进行注册登记

Renew - 服务续约,30秒/次心跳包健康检查.90秒未收到剔除服务

Fetch Registries - 获取服务注册列表,获取其他微服务地址

Cancel - 服务下线, 某个微服务通知注册中心暂停服务

Eviction - 服务剔除,90秒未续约,从服务注册表进行剔除

Eureka自我保护机制

Eureka在运行期去统计心跳失败率在15分钟之内是否低于 85%

如果低于 85%,会将这些实例保护起来,让这些实例不会被剔除

关闭自我保护:eureka.服务实例.

enable-self-preservation: false

PS: 如非网络特别不稳定,建议关闭

Eureka高可用配置步骤

服务提供者defaultZone指向其他的Eureka

客户端添加所有Eureka 服务实例 URL

Actuator自动为微服务创建一系列的用于监控的端点

Actuator在SpringBoot自带,SpringCloud进行扩展

pom.xml依赖spring-boot-starter-actuator

RestTemplate + @LoadBalanced 显式调用

OpenFeign 隐藏微服务间通信细节

Ribbon是RestTemplate与OpenFeign的通信基础

Feign是一个开源声明式WebService客户端,用于简化服务通信

Feign采用“接口+注解”方式开发,屏蔽了网络通信的细节

OpenFeign是SpringCloud对Feign的增强,支持Spring MVC注解

1.新建Spring boot Web项目,application name 为 product-service

在pom.xml中引入依赖

spring-cloud-starter-alibaba-nacos-discovery作用为向Nacos server注册服务。

spring-cloud-starter-openfeign作用为实现服务调用。

2.修改application.yml配置文件

3.在启动类上添加@EnableDiscoveryClient、@EnableFeignClients注解

4.编写OrderClient Interface

注:/api/v1/order/test 会在下面order-service声明。

OrderClient.java

5.编写Controller和service

ProductController.java

ProductService.java

1.OpenFeign开启通信日志

基于SpringBoot的logback输出,默认debug级别

设置项:feign.client.config.微服务id.loggerLevel

微服务id:default代表全局默认配置

2.通信日志输出格式

NONE: 不输出任何通信日志

BASIC: 只包含URL、请求方法、状态码、执行时间

HEADERS:在BASIC基础上,额外包含请求与响应头

FULL:包含请求与响应内容最完整的信息

3.OpenFeign日志配置项

LoggerLevel开启通信日志

ConnectionTimeout与ReadTimeout

利用httpclient或okhttp发送请求

1.OpenFeign通信组件

OpenFeign基于JDK原生URLConnection提供Http通信

OpenFeign支持Apache HttpClient与Square OkHttp

SpringCloud按条件自动加载应用通信组件

2.应用条件

Maven引入feign-okhttp或者feign-httpclient依赖

设置feign.[httpclient|okhttp].enabled=true

POST方式传递对象使用@RequestBody注解描述参数

GET方式将对象转换为Map后利用@RequestParam注解描述

雪崩效应:服务雪崩效应产生与服务堆积在同一个线程池中,因为所有的请求都是同一个线程池进行处理,这时候如果在高并发情况下,所有的请求全部访问同一个接口,这时候可能会导致其他服务没有线程进行接受请求,这就是服务雪崩效应效应。

服务熔断:熔断机制目的为了保护服务,在高并发的情况下,如果请求达到一定极限(可以自己设置阔值)如果流量超出了设置阈值,让后直接拒绝访问,保护当前服务。使用服务降级方式返回一个友好提示,服务熔断和服务降级一起使用。

1.Hystrix熔断器

Hystrix(豪猪)是Netflix开源的熔断器组件,用于为微服务提供熔断机制预防雪崩,保护整体微服务架构的健康

2.Hystrix功能

预防微服务由于故障,请求长时间等待导致Web容器线程崩溃

提供故障备选方案,通过回退(fallback)机制提供”服务降级”

提供监控仪表盘,实时监控运行状态

3.Hystrix 熔断器工作原理

服务的健康状况 = 请求失败数 / 请求总数.

熔断器开关由关闭到打开的状态转换是通过当前服务健康状况和设定阈值比较决定的.

当熔断器开关关闭时, 请求被允许通过熔断器. 如果当前健康状况高于设定阈值, 开关继续保持关闭. 如果当前健康状况低于

设定阈值, 开关则切换为打开状态.

当熔断器开关打开时, 请求被禁止通过.

当熔断器开关处于打开状态, 经过一段时间后, 熔断器会自动进入半开状态, 这时熔断器只允许一个请求通过. 当该请求调用

成功时, 熔断器恢复到关闭状态. 若该请求失败, 熔断器继续保持打开状态, 接下来的请求被禁止通过.

熔断器的开关能保证服务调用者在调用异常服务时, 快速返回结果, 避免大量的同步等待. 并且熔断器能在一段时间后继续侦测请求执行结果, 提供恢复服务调用的可能.

4.什么情况下会触发服务降级

FAILURE: 执行失败,抛出异常

TIMEOUT:执行超时(默认1秒)

SHORT_CIRCUITED:熔断器状态为Open

THREAD_POOL_REJECTED:线程池拒绝

SEMAPHORE_REJECTED:信号量拒绝

5.使用Hystrix步骤

1.引入pom文件依赖

6.OpenFeign与Hystrix整合

OpenFeign中使用Hystrix

OpenFeign内置Hystrix,feign.hystrix.enable开启即可

feign: hystrix: enabled: true

在@FeignClient增加fallback属性说明Fallback类

@FeignClient(name="message-service",fallback = MessageServiceFallback.class) public interface MessageService { @GetMapping("/sendsms") public CallbackResult sendSMS(@RequestParam("mobile") String mobile , @RequestParam("message") String message)}

Fallback类要实现相同接口,重写服务降级业务逻辑

@Component public class MessageServiceFallback implements MessageService { @Override public CallbackResult sendSMS(String mobile, String message) { return new CallbackResult("INVALID_SERVICE","消息服务暂时无法使用,短信发送失败")} }

7.Hystrix超时设置

8.部署Hystrix Dashboard监控

Hystrix Client依赖hystrix-metrics-event-stream

Hystrix Client注册HystrixMetricsStreamServlet

监控微服务依赖spring-cloud-starter-netflix-hystrix-dashboard

监控微服务利用@EnableHystrixDashboard开启仪表盘

9.Hystrix熔断设置

产生熔断的条件:

当一个Rolling Window(滑动窗口)的时间内(默认:10秒),最近20次调用请求,请求错误率超过50%,则触发熔断5秒,期间快速失败。

TIPS: 如10秒内未累计到20次,则不会触发熔断

Hystrix熔断设置项:

统一访问出入口,微服务对前台透明

安全、过滤、流控等API管理功能

易于监控、方便管理

Netflix Zuul

Spring Cloud Gateway

Zuul 是Netflix开源的一个API网关, 核心实现是Servlet

Spring Cloud内置Zuul 1.x

Zuul 1.x 核心实现是Servlet,采用同步方式通信

Zuul 2.x 基于Netty Server,提供异步通信

认证和安全

性能监测

动态路由

负载卸载

静态资源处理

压力测试

Spring Cloud Gateway,是Spring“亲儿子”

Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式

Gateway基于Spring 5.0与Spring WebFlux开发,采用Reactor响应式设计

1.使用三部曲

依赖spring-cloud-starter-netflix-zuul

入口增加 @EnableZuulProxy

application.yml 增加微服务映射

2.微服务映射

Spring Cloud Zuul内置Hystrix

服务降级实现接口:FallbackProvider

1.微服务网关流量控制

微服务网关是应用入口,必须对入口流量进行控制

RateLimit是Spring Cloud Zuul的限流组件

https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit

RateLimit采用“令牌桶”算法实现限流

2.什么是令牌桶

1.Zuul的执行过程

2.Http请求生命周期

1.需要实现ZuulFilter接口

shouldFilter() - 是否启用该过滤器

filterOrder() - 设置过滤器执行次序

filterType() - 过滤器类型:pre|routing|post

run() - 过滤逻辑

2.Zuul内置过滤器

3.Zuul+JWT跨域身份验证

1.Spring Cloud Config

2.携程 Apollo

3.阿里巴巴Nacos

1.依赖"spring-cloud-starter-config"

2.删除application.yml,新建bootstrap.yml

3.配置"配置中心"服务地址与环境信息

1、微服务依赖"spring-boot-starter-actuator"

2、动态刷新类上增加@RefreshScope注解

3、通过/actuator/refresh刷新配置

1、通过加入重试机制、提高应用启动的可靠性

2、重试触发条件1:配置中心无法与仓库正常通信

3、重试触发条件2:微服务无法配置中心正常通信

最近刚入坑微服务,总是会碰到很多坑,一个坑一个脚印,默默记下。

Problem 1:

其中一个微服务模块,启动,本身没有问题,postman测试接口也没有问题。同时在网关中配置了相关转发,例如:

但是通过网关访问就会出现问题,通过API网关路由来访问微服务,zuul默认路由规则 : http://zuul 的Host地址:zuul端口/要调用的服务名/服务方法地址,报错:

com.netflix.zuul.exception.ZuulException: Forwarding error......

Caused by: com.netflix.client.ClientException: null......

Caused by: java.lang.RuntimeException: java.net.SocketTimeoutException: Read timed out

是因为接口调用的时间过长,超过了等待时长,于是配置一下时长,在网关模块中application.yml配置

以及

还有

进行这样的配置之后,可以通过API网关路由来访问服务了,postman接口测试正常。

Problem 2:

微服务之间通讯的时候,由于配置了熔断器,发现A服务中每次调用B的时候,都会进入fallback,由此判断调用过程出现了问题。

其实还是上面说到的时间问题,我将fallback去掉之后,在controller 中try...catch捕获到了错误,定位错误:spring cloud java.util.concurrent.TimeoutException

【此处记录下,不去掉fallback也能捕捉错误,在client中try...catch就可以】

首先我尝试了在A服务的application.yml中设置了熔断器的检测时间:(熔断器检测时间(默认1秒))

但是并没有效果, 后来就关闭熔断器超时检测时间功能,也就是不超时

OK,到此问题都解决了,微服务自身运行正常,API网官访问也正常,微服务间通讯也正常