SpringCloud 消费者框架 API网关 熔断机制

最新推荐文章于 2024-07-13 09:40:56 发布
最新推荐文章于 2024-07-13 09:40:56 发布
阅读量1k 收藏 2
点赞数
分类专栏： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_37928045/article/details/99289434
版权

SpringCloud

微服务设计

服务拆分

  1. 纵向拆分
    1. 用界面层
    2. 应用层
    3. 领域层
    4. 基础设施层
  2. 横向查分
  3. 领域驱动设计

服务注册\服务发现

服务消费

消费模式
  1. 服务直连模式，通过url直接访问
    1. 简单明了
    2. 平台语言无关性
    3. 无法保证服务的可用性
    4. 生产环境使用较少
  2. 客户端发现模式
    1. 运作流程
      1. 服务实例启动后，将自己的位置信息提交到服务注册表
      2. 客户端冲服务注册表进行查询，来获取可用的服务实例
      3. 客户端自行使用负载均衡算法从多个服务实例中选出一个
  3. 服务端发现模式
    1. 他的运作模式和客户端发现模式发现一样，但是**负载均衡是在注册表的服务端上实现的，客户端无序关心负载均衡**
消费者框架
Apache HttpClient

通过url请求获取返回值

依赖：

<dependency>
    <groupId>org.apache.httpcomponents</groupId>
    <artifactId>httpclient</artifactId>
    <version>4.5.3</version>
</dependency>

注入RestTemplate类

@Configuration
public class ConfigBean {
    @Autowired
    private RestTemplateBuilder restTemplateBuilder;

    @Bean
    public RestTemplate getRestTemplate(){
        return restTemplateBuilder.build();
    }
}

使用

private void saveWeatherDate(String url) {
    ResponseEntity<String> restString = restTemplate.getForEntity(url, String.class);
    // . . .
}
Ribbon（后期重点研究负载均衡的实现原理）

实现客户端复杂均衡的工具

Feign

依赖

<!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-openfeign -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
    <version>2.0.0.RELEASE</version>
</dependency>

配置

#服务通信超时时间
feign.client.config.feignName.connectTimeout=100
feign.client.config.feignName.readtTimeout=100

Spring boot 中激活该模块 @EnableFeignClients

@SpringBootApplication
@EnableDiscoveryClient
@EnableFeignClients
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }

}

配置service层

@FeignClient("city") //指定服务名称  多层次路由 @FeignClient(name="服务名",path="路径名")
public interface CityClient {

  	//指定服务中接口名
    @GetMapping("/citys")
    String cityList();

}

调用

@Autowired
private CityClient cityClient;

@GetMapping("/index")
@ResponseBody
public String index(){
    return cityClient.cityList();
}

统一入口(API网关)

意义
  1. 聚合多个API
  2. 统一api入口
利弊
  1. 避免将内部的信息暴露给外部，将内部的微服务api和外部的访问api区分开来
  2. 为微服务提供单独的保护层，系统权限系统的实现
  3. 支持混合通信协议
  4. 降低构建服务的复杂性（api令牌，访问控制，网速限制，从代码层隔离这些功能）
  5. 微服务模拟和虚拟化
  6. 需要额外的编排和管理
  7. 路由逻辑配置需要进行统一的管理
  8. 引发单点故障，api网关的不可用会导致整个服务的不可用
常见的实现方式
nginx
Kong(基于nginx)
zuul

maven依赖

<!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-netflix-zuul -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-zuul</artifactId>
    <version>2.1.2.RELEASE</version>
</dependency>

配置（简单使用）

# 设置请求转发 将hi路径下的请求转发到名为city的微服务下
zuul.routes.hi.path= /hi/**
zuul.routes.hi.service-id=city

功能列表：

  1. 认证
  2. 压力测试
  3. 金丝雀测试
  4. 动态路由
  5. 负载消减
  6. 安全
  7. 静态响应处理
  8. 主动/主动交还管理

配置管理

集中化配置的意义
  1. 微服务数量多，配置多
  2. 手工管理配置繁琐
配置分类
  1. 配置来源划分：开发环境，测试环境，预发环境，生产环境
  2. 配置的集成阶段划分：编译时，打包时，运行时
  3. 配置的加载方式：启动加载，动态加载
服务端实现

依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
    <version>2.1.3.RELEASE</version>
</dependency>

启用config-server

通过注解启用spring-cloud-config-server: @EnableConfigServer

配置

spring.application.name=config
server.port=8888
#服务中心地址
eureka.client.service-url.defaultZone= http://localhost:8761/eureka/

#仓库地址
spring.cloud.config.server.git.uri=https://github.com/luohengyi/springCloudConfig.git
#指定仓库中的文件夹
spring.cloud.config.server.git.search-paths=config-repo

访问

通过路径auther/dev（该url框架自带！） 来访问初始化页面http://localhost:8888/auther/dev

客户端实现

依赖

<!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-config-server -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
    <version>2.1.3.RELEASE</version>
</dependency>

配置

spring.application.name=config-client
eureka.client.service-url.defaultZone= http://localhost:8761/eureka/

server.port=8889

#当前服务职会读取该服务名称+profile的配置文件
spring.cloud.config.profile=dev
#配置服务器的地址
spring.cloud.config.uri=http://localhost:8888

启用

无需单独使用注解启动，配置服务器后自动调用配置

熔断机制

概述

防止由于某一个服务的死亡导致整个系统的死亡，对该服务的调用执行熔断。对于后学请求，不在继续调用，该目标服务，而是直接返回。从而可以快速的释放资源，实现原理类似电路的断路器，调用超过负载的服务会通过断路器直接返回一个默认信息，断路器的状态分为：1.打开、2.关闭(当服务正常时关闭，但是会做一些失败次数的统计，当失败次数达到阀值时，断路器会打开，将异常信息直接返回给调用者)、3.半打开（关闭一段时间后，断路器会放开一些请求，当这些请求都能正常执行时，断路器会认为，服务已经恢复正常，这时断路器会关闭），

功能
  1. 异常处理
  2. 日志记录
  3. 测试失败的操作
  4. 手动复位
  5. 并发
  6. 加速短路
  7. 重试失败请求
熔断框架hystrix

依赖

<!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-netflix-hystrix -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
    <version>2.1.0.RELEASE</version>
</dependency>

启动

  1. 使用注解 @EnableCircuitBreaker

  2. @GetMapping
//配置默认方法，当该服务接口无法使用时候，调用defaults返回给调用者
@HystrixCommand(fallbackMethod = "defaults")
public List<City> cityList() throws Exception{
    return cityDateService.listCity();
}

public List<City> defaults(){
    return  null;
}

制动扩展

Cloud子项目

配置管理 config

服务注册/服务发现(Eureka)

服务端

依赖

<!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-netflix-eureka-server  注意soring 和cloud的版本对应问题 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
    <version>1.4.7.RELEASE</version>
</dependency>

配置

server.port=8761
eureka.instance.hostname= localhost
#禁用客户端
eureka.client.registerWithEureka=false
eureka.client.fetchRegistry=false


#服务地址配置
eureka.client.service-url.defaultZone= http://${eureka.instance.hostname}:${server.port}/eureka/

注解方式 @EnableEurekaServer 注解启用Eureka server 可以通过访问localhost:8761查看 Eureka server信息

@SpringBootApplication
@EnableEurekaServer
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }

}
客户端

依赖

<!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-netflix-eureka-server -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
    <version>2.0.0.RELEASE</version>
</dependency>

配置

#该客户端的名称，该服务注册到服务端后显示的名字
spring.application.name=myeurekaclien

#服务端地址配置，将该服务注册到该服务端上
eureka.client.service-url.defaultZone= http://localhost:8761/eureka/

注解方式启用客户端

@SpringBootApplication
@EnableDiscoveryClient
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }

}

客户端服务可以启动多个来实现分布式

断路器

负载均衡

智能路由

服务间调用

一次性令牌

微代理

思维导图模版

全局锁

控制总线

领导选举

分布式会话

集群状态

分布式消息

qq_37928045
关注
专栏目录
基于SpringCloud Gateway的API网关设计与实现
AI天才研究院
08-02 1354
随着互联网技术的飞速发展、软件架构的演进，越来越多的人开始意识到“边界服务”的重要性。越来越多的公司面临“如何快速响应用户需求”、“保证系统稳定运行”等诸多问题，为了应对这些挑战，微服务架构已经成为一个热门话题。但微服务架构带来的问题也很明显，不仅需要考虑分布式事务、服务治理、弹性伸缩、限流降级等诸多问题，还面临新旧服务版本兼容、服务拆分重组、跨域调用等复杂的技术难题，使得传统的SOA架构方案无法满足要求。
微服务-API网关-熔断降级
炮哥技术分享
08-26 5098
介绍 在微服务架构中，各个服务之间往往是级联在一起的，一个服务发生故障时可能会造成以下灾难： 服务依赖方调用超时，导致任务队列打满，引起链式反应，最终导致整个集群雪崩。 服务依赖方调用返回失败，引起链式反应，最终导致整个集群不可用。 所以需要在微服务不可用时切断故障服务与其他服务的通讯。 熔断是对服务提供者说的，由于某些原因（比如网络不通、服务挂了、请求处理不过来）造成服务提供者不能提供服务时，服务提供者就需要切断和服务调用者的连接，不然就造成资源浪费或者队列打满，从而导致链式反应。 降级是对服务调用者
api网关kong对高频的慢接口进行熔断
天草二十六
05-30 991
本文通过线上实际发生的一个生产事故，梳理了我们的解决思路，对于高频慢接口的访问，最后只能通过kong的熔断来解决。事实证明，重启银弹和扩容银弹并不适用此，对于fullgc等jvm内存问题可能适用。这个生产事故，也给我们一个提醒，需要及时排查慢接口和数据库的慢查询，它们就像是航船的漏洞一样，小洞如果不及时堵上，等变大了，想堵就来不及了。
微服务和API网关限流熔断实现关键逻辑思路（深度好文）
Java搜索工程技术栈
06-21 839
今天准备谈下微服务架构和API网关中的限流熔断，当前可以看到对于Spring Cloud框架本身也提供了Hystrix，主流的开源API网关产品类似Kong网关本身也包括了限流熔断能力。当然也有完全较为独立的限流熔断开源实现，比如阿里的Sentinel即是我们经常会用到的限流熔断开源产品，而且可以和Dubbo，SpringCloud等各种微服务框架无缝集成。由于网上大家能够搜索到的关于各开源产品实现的限流熔断功能和使用的文章都很多，因此这篇文章不打算再去介绍这些开源产品，而是从业务场景出发来思考下一个限流熔
嗡汤圆的Spring Cloud自学（PART.3）：API熔断与监控（hystrix）
嗡汤圆的博客
10-13 5770
前言结合上篇博客”嗡汤圆的Spring Cloud自学（PART.2）：eureka服务注册与代理端使用” 中API服务代理的使用，我们将用户请求交由代理完成API调用以及后端的负载均衡。 同时，通过代理，我们也可以很方便的将后端的异常捕获并处理。比如发生后端API错误，或者后端无可用的微服务的情况时的异常处理，我们称之为API熔断（Circuit Break），起到保护客户端与代理间程序正常运行
网关的熔断控制
weixin_44196002的博客
02-21 429
网关熔断
springcloud熔断机制
01-24
springcloud家族中关于springcloud熔断机制的框架介绍
Spring Cloud实战：Zuul API网关与请求过滤解析
在Spring Cloud框架中，Zuul作为API网关的主要角色是将客户端请求分发到不同的微服务中，这样可以减少客户端与各个微服务之间的直接交互，简化了系统的架构。Zuul 使用Ribbon 进行客户端负载均衡，通过Eureka服务...
springcloud: 服务熔断与网关
qq_51277443的博客
12-02 1284
Hystrix是一个用于处理分布式系统的延迟和容错的开源库, 在分布式系统里,许多依赖不可避免的会调用失败,比如超时、异常等,Hystrix能够保证在一个依赖出问题的情况下， 不会导致整体服务失败,避免级联故障，以提高分布式系统的弹性。（理念设计和思想） Hystrix重要概念-服务降级fallback，服务熔断break，服务限流flowlimit； 服务降级：fallback 1，服务器忙，不让客户端等待立即返回一个友好提示 2，哪些情况会发出降级：程序运行异常，超时，服务熔断触发服务降级..
springcloud系列课程-服务网关
01-25
【Spring Cloud 服务网关】是Spring Cloud框架中的一个重要组件，用于实现微服务架构中的服务路由、过滤和安全控制等功能。在Spring Cloud体系中，服务网关通常指的是Zuul或Gateway，它们作为所有外部请求进入微服务...
API网关—Ocelot之限流熔断
weixin_37648525的博客
04-19 1188
API网关—Ocelot之限流熔断限流熔断 限流 在微服务架构下，若大量请求超过微服务的处理能力时，可能会将服务打跨，甚至产生雪崩效应、影响系统的整体稳定性。比如说你的用户服务处理能力是1w/s，现在因为异常流量或其他原因，有10w的并发请求访问你的服务，那服务肯定扛不住啊。这种情况下，我们可以在流量超出承受阈值时，直接进行”限流”、拒绝部分请求，从而保证系统的整体稳定性。 Ocelot提供限流功能，这个功能是由张善友大大贡献的，只要通过配置就可以实现，我们可以将以下配置放在全局配置中。 "RateLim
win32 判断窗口是否前置的api_微服务和API网关限流熔断实现关键逻辑思路
weixin_39761573的博客
12-10 208
今天准备谈下微服务架构和API网关中的限流熔断，当前可以看到对于Spring Cloud框架本身也提供了Hystrix，主流的开源API网关产品类似Kong网关本身也包括了限流熔断能力。当然也有完全较为独立的限流熔断开源实现，比如阿里的Sentinel即是我们经常会用到的限流熔断开源产品，而且可以和Dubbo，SpringCloud等各种微服务框架无缝集成。由于网上大家能够搜索到的关于各...
APISIX源码解析-插件-API 熔断【api-breaker】
a_12321_123的博客
01-11 1779
api-breaker API 熔断插件。 关键属性 熔断超时逻辑 由代码逻辑自动按触发不健康状态的次数递增运算： 每当上游服务返回unhealthy.http_statuses配置中的状态码(比如：500)，达到unhealthy.failures次时(比如：3 次)，认为上游服务处于不健康状态。 第一次触发不健康状态，熔断 2 秒。 然后，2 秒过后重新开始转发请求到上游服务，如果继续返回unhealthy.http_statuses状态码，记数再次达到unhealthy.failures次时，熔断
微服务分布式系统熔断实战-为何我们需要API级别熔断？
weixin_33967071的博客
10-31 371
熔断在分布式系统的作用已经被强调过很多次了可以通过这篇文章来了解价值,Netflix在自己的分布式系统中应用熔断技术来保护系统blog.51cto.com/developeryc…内部的实现机制可以参考martinfowler.com/bliki/Circu…本篇文章将介绍go chassis如何通过熔断机制，隔离上游服务，保护下游服务。Go chassis如何保证上游错误不影响下游系统go ch...
第4章 Sentinel--服务容错
勇哥V587
10-28 1131
第4章 Sentinel–服务容错 4.1 高并发带来的问题 在微服务架构中，我们将业务拆分成一个个的服务，服务与服务之间可以相互调用，但是由于网络 原因或者自身的原因，服务并不能保证服务的100%可用，如果单个服务出现问题，调用这个服务就会 出现网络延迟，此时若有大量的网络涌入，会形成任务堆积，最终导致服务瘫痪。 接下来，我们来模拟一个高并发的场景 1 编写java代码 @RestController @Slf4j public class OrderController2 { @Autowired pr
SpringCloud核心组件ZuulAPI网关
最新发布
kkchenjj的博客
07-13 958
Zuul的架构设计基于Spring MVC和Servlet容器，它通过使用Spring的注解来启动，这个注解会开启Zuul的代理功能，包括路由、过滤器等。Zuul的过滤器是其工作原理的关键，它们被组织在不同的生命周期阶段，如preroutingpost和error，每个阶段都有特定的过滤器来处理请求的不同方面。Zuul作为Spring Cloud中的API网关，提供了强大的路由功能，包括静态路由配置和动态路由管理。通过配置中心，我们可以灵活地管理路由规则，而无需重启服务。Zuul的路由功能是通过。
springcloud 服务消费及熔断
qq_62898618的博客
12-10 868
传统情况下在java代码里访问restful服务，一般使用Apache的HttpClient。不过此种方法使用起来太过繁琐。spring提供了一种简单便捷的模板类来进行操作，这就是RestTemplate。
spring cloud之网关熔断、降级
Nestor的博客
04-13 786
业务场景 在传统的项目中，当访问一个路径出现不可访问比如404，浏览器不同在加载甚至在10几秒后才会反馈出404，这明显对用户不友好，如果用户在加载404等还在不停的刷新当前网页将会导致后台不同的请求。这就需要我们做熔断降级 在当前的网关服务中，熔断降级主要是使用hystrix来实现服务降级，当访问的内部url超过限定的时间救出自动出现 代码层面 spring: cloud: gate...
Feign(声明式客户端)和Zuul(api网关)使用区别
weixin_49127991的博客
08-05 610
Feign 部署在微服务内部，服务和服务之间调用 不推荐使用hystrix熔断 1.每个feign调用位置都启用hystrix，会造成混乱 2.一般是在最前面添加断路器，就想入户的电闸 3.有特殊情况，可以启用hystrix Zuul 部署在最前面，作为入口 不推荐使用ribbon的重试 1.在最前面进行重试，会造成后台服务压力翻倍增加 2.重试功能尽量往后加 ...
Apache APISIX 初体验
DevOps持续集成的博客
01-12 3535
Apache APISIX 是一个基于 OpenResty 和 Etcd 实现的动态、实时、高性能的 API 网关，目前已经是 Apache 的顶级项目。提供了丰富的流量管理功能，如负载均...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值