做水晶接单在哪个网站接,专业企业网站设计,wordpress如何调用标签,免费网站诊断一、创建SpringBoot项目 用mavan搭建也可以。#xff08;重要的是后面pom里应该引入那些依赖#xff0c;application.yml怎么配置#xff09; 由于开始构建项目时选择了Eureka Server#xff0c;所以pom.xml中不需要手动添加依赖了
首先在启动类SpringcloudApplicatio…一、创建SpringBoot项目 用mavan搭建也可以。重要的是后面pom里应该引入那些依赖application.yml怎么配置 由于开始构建项目时选择了Eureka Server所以pom.xml中不需要手动添加依赖了
首先在启动类SpringcloudApplication中添加EurekaServer的注解EnableEurekaServer
二、application.yml
server:port: 9000 #eureka注册中心服务端口eureka:instance:hostname: localhostclient:register-with-eureka: false #不向eureka注册中心注册。也就是为了关闭自己向自己注册eureka默认要向自己注册fetch-registry: falseservice-url:defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/访问注册中心按照配置的端口号访问。我这里配了9000端口随意如下图代表Eureka注册中心部署成功了。 显示没有实例在此中心注册。没事接下来我们开始配置zuul网关它也是一个服务需要注册到此注册中心来。
三、提供Service服务
eurekaservice01eurekaservice02eurekaservice03eurekaservice04第一个如下第二三四个按着第一个的建修改一下名字端口号还有方法返回值 需要用到mvc 服务提供者同样需要注册到注册中心
接下来是同样的套路改yml启动类添加注解EnableEurekaClient yml配置如下因为是测试所有很简陋
server:port: 8900 # 服务提供方# 指定当前eureka客户端的注册地址,
eureka:client:service-url:defaultZone: http://${eureka.instance.hostname}:9000/eureka/instance:hostname: localhost#当前服务名称
spring:application:name: eurekaservice1注意当前服务名称。这里用于注册到注册中心的名字还可以启动很多同样为eurekaservice1的名字的微服务到注册中心zuul从注册中心Eureka Server获取所有服务名为eurekaservice01的服务列表后会采用负载均衡策略访问其中一台服务提供者获取资源。
下图我们之前zuul中的配置serviceId就是指向这里的服务名称这是微服务调用的精髓通过服务名调用。 既然是服务提供者 这里要编写controller类了新建controller包新建Test01类编写REST的方法。返回服务1 按照服务提供者1的搭建方式现在搭建服务提供者2 同样是新建模组名字改为…02yml配置文件中端口号与服务1要不同服务名称相同为了测试负载均衡REST方法返回值设为服务2。
server:port: 8901 # 服务提供方# 指定当前eureka客户端的注册地址,
eureka:client:service-url:defaultZone: http://${eureka.instance.hostname}:9000/eureka/instance:hostname: localhost#当前服务名称
spring:application:name: eurekaservice1同样的方法再建两个服务提供者3和4服务名称都为eurekaservice2端口号分别为8902和8903。REST方法返回值分别为服务3和服务4。
四、Zuul网关服务
搭建了注册中心和服务的提供者我们现在开始搭建Zuul网关服务最后通过zuul访问注册中心获取服务列表然后访问服务提供者。 这里模组名设为zuul。包名设置为zuul等会生成的启动类就会是带有zuul了。EurekaServer也可以这样只是我开始搭的时候没有注意到。 要Eureka的客户端组件和zuul组件点next 模组名设为zuul不强制 项目结构 在启动类配置注解 EnableEurekaClientEnableZuulProxyEnableZuulProxy可以称为EnableZuulServer的增强版当Zuul与Eureka、Ribbon等组件配合使用时我们使用EnableZuulProxy 配置pom文件 启动项目 再去注册中心看就能看见zuul服务已经被注册到注册中心了
五、Zuul的访问
有一个网关服务zuul一个注册中心eurekaserver4个服务提供者eurekaservice4个服务提供者
其中两个提供服务名为eurekaservice1的服务另外两个提供eurekaservice2的服务现在我们来启动4个服务提供者在注册中心查看并通过网关访问测试网关的服务是否正常。
总项目结构 启动后注册中心查看
如之前所想两个服务名下各两台服务提供者。 现在回想之前zuul的路由配置 访问zuul网关的test01/**下的任何服务都会给我转发到服务名为eurekaservice1下的01和02服务下。
第一次访问test01 第二次访问test01 可以看见zuul网关做了转发和负载均衡使用的是ribbon轮询的方式负载均衡。 那么可以猜想到我们访问test02zuul网关会在服务名为eurekaservice2的服务3和服务4之间去访问了。我们来看看 至此已经实践完成zuul网关的基本功能转发和负载均衡。
Zuul网关的应用
通过zuul访问服务的URL地址默认格式为http://zuulHostIp:port/要访问的服务名称/服务中的URL
服务名称properties配置文件中的spring.application.name 服务的URL就是对应的服务对外提供的URL路径监听
一、网关依赖注入
!-- spring cloud Eureka Client 启动器 --
dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-eureka/artifactId
/dependency
dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-zuul/artifactId
/dependency
!-- zuul网关的重试机制不是使用ribbon内置的重试机制是借助spring-retry组件实现的重试开启zuul网关重试机制需要增加下述依赖--
dependencygroupIdorg.springframework.retry/groupIdartifactIdspring-retry/artifactId
/dependency二、启动类
/*** EnableZuulProxy - 开启Zuul网关。* 当前应用是一个Zuul微服务网关。会在Eureka注册中心中注册当前服务。并发现其他的服务。* Zuul需要的必要依赖是spring-cloud-starter-zuul。*/
SpringBootApplication
EnableZuulProxy
public class ZuulApplication {public static void main(String[] args) {SpringApplication.run(ZuulApplication.class, args);}
}三、配置文件网关全局变量配置
# URL路径匹配
# 使用路径方式匹配路由规则。
# 参数key结构zuul.routes.customName.pathxxx
# 用于配置路径匹配规则。
# 其中customName自定义。通常使用要调用的服务名称方便后期管理
# 可使用的通配符有* ** ?
# ? 单个字符
# * 任意多个字符不包含多级路径
# ** 任意多个字符包含多级路径
zuul.routes.eureka-application-service.path/api/**
# 参数key结构zuul.routes.customName.urlxxx
# url用于配置符合path的请求路径路由到的服务地址。
zuul.routes.eureka-application-service.urlhttp://127.0.0.1:8080/# 服务名称匹配
# service id pattern 通过服务名称路由
# key结构 zuul.routes.customName.pathxxx
# 路径匹配规则 符合path的请求路径直接路由到customName对应的服务上
zuul.routes.eureka-application-service.path/api/**
# key结构 zuul.routes.customName.serviceIdxxx
# serviceId用于配置符合path的请求路径路由到的服务名称。如果只配置path不配置serviceId。则customName相当于服务名称
zuul.routes.eureka-application-service.serviceIdeureka-application-service# 路由排除配置
# 配置不被zuul管理的服务列表。多个服务名称使用逗号,分隔。
# 配置的服务将不被zuul代理。
zuul.ignored-serviceseureka-application-service# 此方式相当于给所有新发现的服务默认排除zuul网关访问方式只有配置了路由网关的服务才可以通过zuul网关访问
# 通配方式配置排除列表。
zuul.ignored-services*
# 使用服务名称匹配规则配置路由列表相当于只对已配置的服务提供网关代理。
zuul.routes.eureka-application-service.path/api/**# 通配方式配置排除网关代理路径。所有符合ignored-patterns的请求路径都不被zuul网关代理。
zuul.ignored-patterns/**/test/**
zuul.routes.eureka-application-service.path/api/**# 路由前缀配置
# prefix URL pattern 前缀路由匹配
# 配置请求路径前缀所有基于此前缀的请求都由zuul网关提供代理。
zuul.prefix/api
# 使用服务名称匹配方式配置请求路径规则。
# 这里的配置将为http://ip:port/api/appservice/**的请求提供zuul网关代理可以将要访问服务进行前缀分类。
# 并将请求路由到服务eureka-application-service中。
zuul.routes.eureka-application-service.path/appservice/**网关配置方式有多种默认、URL、服务名称、排除|忽略、前缀。 网关配置没有优劣好坏应该在不同的情况下选择合适的配置方案。
zuul网关其底层使用ribbon来实现请求的路由并内置Hystrix可选择性提供网关fallback逻辑。使用zuul的时候并不推荐使用Feign作为application client端的开发实现。毕竟Feign技术是对ribbon的再封装使用Feign本身会提高通讯消耗降低通讯效率只在服务相互调用的时候使用Feign来简化代码开发就够了。而且商业开发中使用RibbonRestTemplate来开发的比例更高。
四、路由网关过滤器
Zuul中提供了过滤器定义可以用来过滤代理请求提供额外功能逻辑。如权限验证日志记录等。
Zuul提供的过滤器是一个父类。父类是ZuulFilter。通过父类中定义的抽象方法filterType来决定当前的Filter种类是什么。有前置过滤、路由后过滤、后置过滤、异常过滤。
前置过滤是请求进入Zuul之后立刻执行的过滤逻辑路由后过滤是请求进入Zuul之后并Zuul实现了请求路由后执行的过滤逻辑路由后过滤是在远程服务调用之前过滤的逻辑。后置过滤远程服务调用结束后执行的过滤逻辑。异常过滤是任意一个过滤器发生异常或远程服务调用无结果反馈的时候执行的过滤逻辑。无结果反馈就是远程服务调用超时。
过滤器实现方式
继承父类ZuulFilter。在父类中提供了4个抽象方法分别是filterType, filterOrder, shouldFilter, run。其功能分别是
filterType方法返回字符串数据代表当前过滤器的类型。可选值有-pre, route, post, error。pre - 前置过滤器在请求被路由前执行通常用于处理身份认证日志记录等route - 在路由执行后服务调用前被调用error - 任意一个filter发生异常的时候执行或远程服务调用没有反馈的时候执行超时通常用于处理异常post - 在route或error执行后被调用一般用于收集服务信息统计服务性能指标等也可以对response结果做特殊处理。filterOrder返回int数据用于为同filterType的多个过滤器定制执行顺序返回值越小执行顺序越优先shouldFilter返回boolean数据代表当前filter是否生效run具体的过滤执行逻辑。如pre类型的过滤器可以通过对请求的验证来决定是否将请求路由到服务上如post类型的过滤器可以对服务响应结果做加工处理如为每个响应增加footer数据。
过滤器的生命周期
/*** Zuul过滤器必须继承ZuulFilter父类。* 当前类型的对象必须交由Spring容器管理。使用Component注解描述。* 继承父类后必须实现父类中定义的4个抽象方法。* shouldFilter、 run、 filterType、 filterOrder*/
Component
public class LoggerFilter extends ZuulFilter {private static final Logger logger LoggerFactory.getLogger(LoggerFilter.class);/*** 返回boolean类型。代表当前filter是否生效。* 默认值为false。* 返回true代表开启filter。*/Overridepublic boolean shouldFilter() {return true;}/*** run方法就是过滤器的具体逻辑。* return 可以返回任意的对象当前实现忽略。spring-cloud-zuul官方解释* 直接返回null即可。*/Overridepublic Object run() throws ZuulException {// 通过zuul获取请求上下文RequestContext rc RequestContext.getCurrentContext();HttpServletRequest request rc.getRequest();logger.info(LogFilter1.....method{},url{},request.getMethod(),request.getRequestURL().toString());// 可以记录日志、鉴权给维护人员记录提供定位协助、统计性能return null;}/*** 过滤器的类型。可选值有* pre - 前置过滤* route - 路由后过滤* error - 异常过滤* post - 远程服务调用后过滤*/Overridepublic String filterType() {return pre;}/*** 同种类的过滤器的执行顺序。* 按照返回值的自然升序执行。*/Overridepublic int filterOrder() {return 0;}
}五、Zuul网关的容错与Hystrix的无缝结合
在spring cloud中Zuul启动器中包含了Hystrix相关依赖在Zuul网关工程中默认是提供了Hystrix Dashboard服务监控数据的(hystrix.stream)但是不会提供监控面板的界面展示。可以说在spring cloud中zuul和Hystrix是无缝结合的。
1、Zuul中的服务降级处理
在Edgware版本之前Zuul提供了接口ZuulFallbackProvider用于实现fallback处理。从Edgware版本开始Zuul提供了ZuulFallbackProvider的子接口FallbackProvider来提供fallback处理。
Zuul的fallback容错处理逻辑只针对timeout异常处理当请求被Zuul路由后只要服务有返回包括异常都不会触发Zuul的fallback容错逻辑。
因为对于Zuul网关来说做请求路由分发的时候结果由远程服务运算的。那么远程服务反馈了异常信息Zuul网关不会处理异常因为无法确定这个错误是否是应用真实想要反馈给客户端的。
2、代码示例
/*** 如果需要在Zuul网关服务中增加容错处理fallback需要实现接口ZuulFallbackProvider* spring-cloud框架在Edgware版本(包括)之后声明接口ZuulFallbackProvider过期失效* 提供了新的ZuulFallbackProvider的子接口 - FallbackProvider* 在老版本中提供的ZuulFallbackProvider中定义了两个方法。* - String getRoute()* 当前的fallback容错处理逻辑处理的是哪一个服务。可以使用通配符‘*’代表为全部的服务提供容错处理。* 如果只为某一个服务提供容错返回对应服务的spring.application.name值。* - ClientHttpResponse fallbackResponse()* 当服务发生错误的时候如何容错。* 新版本中提供的FallbackProvider提供了新的方法。* - ClientHttpResponse fallbackResponse(Throwable cause)* 如果使用新版本中定义的接口来做容错处理容错处理逻辑只运行子接口中定义的新方法。也就是有参方法。* 是为远程服务发生异常的时候通过异常的类型来运行不同的容错逻辑。*/
Component
public class TestFallBbackProvider implements FallbackProvider {/*** return - 返回fallback处理哪一个服务。返回的是服务的名称* 推荐 - 为指定的服务定义特性化的fallback逻辑。* 推荐 - 提供一个处理所有服务的fallback逻辑。* 好处 - 服务某个服务发生超时那么指定的fallback逻辑执行。如果有新服务上线未提供fallback逻辑有一个通用的。*/Overridepublic String getRoute() {return eureka-application-service;}/*** fallback逻辑。在早期版本中使用。* Edgware版本之后ZuulFallbackProvider接口过期提供了新的子接口FallbackProvider* 子接口中提供了方法ClientHttpResponse fallbackResponse(Throwable cause)。* 优先调用子接口新定义的fallback处理逻辑。*/Overridepublic ClientHttpResponse fallbackResponse() {System.out.println(ClientHttpResponse fallbackResponse());ListMapString, Object result new ArrayList();MapString, Object data new HashMap();data.put(message, 服务正忙请稍后重试);result.add(data);ObjectMapper mapper new ObjectMapper();String msg ;try {msg mapper.writeValueAsString(result);} catch (JsonProcessingException e) {msg ;}return this.executeFallback(HttpStatus.OK, msg, application, json, utf-8);}/*** fallback逻辑。优先调用。可以根据异常类型动态决定处理方式。*/Overridepublic ClientHttpResponse fallbackResponse(Throwable cause) {System.out.println(ClientHttpResponse fallbackResponse(Throwable cause));if(cause instanceof NullPointerException){ListMapString, Object result new ArrayList();MapString, Object data new HashMap();data.put(message, 网关超时请稍后重试);result.add(data);ObjectMapper mapper new ObjectMapper();String msg ;try {msg mapper.writeValueAsString(result);} catch (JsonProcessingException e) {msg ;}return this.executeFallback(HttpStatus.GATEWAY_TIMEOUT, msg, application, json, utf-8);}else{return this.fallbackResponse();}}/*** 具体处理过程。* param status 容错处理后的返回状态如200正常GET请求结果201正常POST请求结果404资源找不到错误等。* 使用spring提供的枚举类型对象实现。HttpStatus* param contentMsg 自定义的响应内容。就是反馈给客户端的数据。* param mediaType 响应类型是响应的主类型 如application、text、media。* param subMediaType 响应类型是响应的子类型 如json、stream、html、plain、jpeg、png等。* param charsetName 响应结果的字符集。这里只传递字符集名称如utf-8、gbk、big5等。* return ClientHttpResponse 就是响应的具体内容。* 相当于一个HttpServletResponse。*/private final ClientHttpResponse executeFallback(final HttpStatus status, String contentMsg, String mediaType, String subMediaType, String charsetName) {return new ClientHttpResponse() {/*** 设置响应的头信息*/Overridepublic HttpHeaders getHeaders() {HttpHeaders header new HttpHeaders();MediaType mt new MediaType(mediaType, subMediaType, Charset.forName(charsetName));header.setContentType(mt);return header;}/*** 设置响应体* zuul会将本方法返回的输入流数据读取并通过HttpServletResponse的输出流输出到客户端。*/Overridepublic InputStream getBody() throws IOException {String content contentMsg;return new ByteArrayInputStream(content.getBytes());}/*** ClientHttpResponse的fallback的状态码 返回String*/Overridepublic String getStatusText() throws IOException {return this.getStatusCode().getReasonPhrase();}/*** ClientHttpResponse的fallback的状态码 返回HttpStatus*/Overridepublic HttpStatus getStatusCode() throws IOException {return status;}/*** ClientHttpResponse的fallback的状态码 返回int*/Overridepublic int getRawStatusCode() throws IOException {return this.getStatusCode().value();}/*** 回收资源方法* 用于回收当前fallback逻辑开启的资源对象的。* 不要关闭getBody方法返回的那个输入流对象。*/Overridepublic void close() {}};}
}六、Zuul网关的限流保护
Zuul网关组件也提供了限流保护。当请求并发达到阀值自动触发限流保护返回错误结果。只要提供error错误处理机制即可。
Zuul的限流保护需要额外依赖spring-cloud-zuul-ratelimit组件。
dependencygroupIdcom.marcosbarbero.cloud/groupIdartifactIdspring-cloud-zuul-ratelimit/artifactIdversion1.3.4.RELEASE/version
/dependency1、全局限流配置
使用全局限流配置zuul会对代理的所有服务提供限流保护。
# 开启限流保护
zuul.ratelimit.enabledtrue
# 60s内请求超过3次服务端就抛出异常60s后可以恢复正常请求
zuul.ratelimit.default-policy.limit3
zuul.ratelimit.default-policy.refresh-interval60
# 针对IP进行限流不影响其他IP
zuul.ratelimit.default-policy.typeorigin2、局部限流配置 使用局部限流配置zuul仅针对配置的服务提供限流保护。
# 开启限流保护
zuul.ratelimit.enabledtrue
# hystrix-application-client服务60s内请求超过3次服务抛出异常。
zuul.ratelimit.policies.hystrix-application-client.limit3
zuul.ratelimit.policies.hystrix-application-client.refresh-interval60
# 针对IP限流。
zuul.ratelimit.policies.hystrix-application-client.typeorigin3、限流参数简介
七、Zuul网关性能调优网关的两层超时调优
使用Zuul的spring cloud微服务结构图 从上图中可以看出。整体请求逻辑还是比较复杂的在没有zuul网关的情况下app client请求app service的时候也有请求超时的可能。那么当增加了zuul网关的时候请求超时的可能就更明显了。
当请求通过zuul网关路由到服务并等待服务返回响应这个过程中zuul也有超时控制。zuul的底层使用的是Hystrixribbon来实现请求路由。结构如下 zuul中的Hystrix内部使用线程池隔离机制提供请求路由实现其默认的超时时长为1000毫秒。ribbon底层默认超时时长为5000毫秒。如果Hystrix超时直接返回超时异常。如果ribbon超时同时Hystrix未超时ribbon会自动进行服务集群轮询重试直到Hystrix超时为止。如果Hystrix超时时长小于ribbon超时时长ribbon不会进行服务集群轮询重试。
那么在zuul中可配置的超时时长就有两个位置Hystrix和ribbon。具体配置如下
# 开启zuul网关重试
zuul.retryabletrue
# hystrix超时时间设置
# 线程池隔离默认超时时间1000ms
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds8000# ribbon超时时间设置建议设置比Hystrix小
# 请求连接的超时时间: 默认5000ms
ribbon.ConnectTimeout5000
# 请求处理的超时时间: 默认5000ms
ribbon.ReadTimeout5000
# 重试次数MaxAutoRetries表示访问服务集群下原节点同路径访问MaxAutoRetriesNextServer表示访问服务集群下其余节点换台服务器
ribbon.MaxAutoRetries1
ribbon.MaxAutoRetriesNextServer1
# 开启重试
ribbon.OkToRetryOnAllOperationstrueSpring-cloud中的zuul网关重试机制是使用spring-retry实现的。工程必须依赖下述资源
dependencygroupIdorg.springframework.retry/groupIdartifactIdspring-retry/artifactId
/dependency
