文章目录
常见面试题
1.1、什么是微服务?
1.2、微服务之间是如何独立通讯的?
1.3、SpringCloud 和Dubbo有哪些区别?
1.4、SpringBoot和SpringCloud, 请你谈谈对他们的理解
1.5、 什么是服务熔断?什么是服务降级
1.6、微服务的优缺点是分别是什么?说下你在项目开发中遇到的坑
1.7、你所知道的微服务技术栈有哪些?请列举一二
1.8、eureka和zookeeper都可以提供服务注册与发现的功能,请说说两个的区别?
微服务概念
●就目前而言,对于微服务,业界并没有一个统一的,标准的定义
●但通常而言,微服务架构是一种架构模式,或者说是一种架构风格,它提倡将单一的应用程序划分成一组小的服务,每个服务运行在其独立的自己的进程内,服务之间互相协调,互相配置,为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通,每个服务都围绕着具体的业务进行构建,并且能够被独立的部署到生产
环境中,另外,应尽量避免统-的,集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言,工具对其进行构建,可以有一个非常轻量级的集中式管理来协调这些服务,可以使用不同的语言来编写服务,也可以使用不同的数据存储;
可能有的人觉得官方的话太过生涩,我们从技术维度来理解下:
●微服务化的核心就是将传统的一站式应用,根据业务拆分成一个一个的服务,彻底地去耦合,每一个微服务提供单个业务功能的服务,一个服务做一件事情,从技术角度看就是一种小而独立的处理过程, 类似进程的概念,能够自行单独启动或销毁,拥有自己独立的数据库。
微服务和微服务架构
微服务:
强调的是服务的大小,他关注的是某一个点, 是具体解决某一个问题提供落地对应服务的一一个服务应用,狭义的看,可以看做是IDEA中的一个个微服务工程,或者一个个Moudel
微服务架构:
微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调,互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务于服务间采用轻量级的通信机制互相协作,每个服务都围绕着具体的业务进行构建,并且能够被独立的部署到生产环境中,另外,应尽量避免统一的,集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言,工具对其进行构建。
微服务的优缺点
优点
●单一职责原则
●每个服务足够内聚,足够小,代码容易理解,这样能聚焦一个指定的业务功能或业务需求;
●开发简单,开发效率提高,-个服务可能就是专一的只干一件事;
●微服务能够被小团队单独开发,这个小团队是2~5人的开发人员组成;
●微服务是松耦合的,是有功能意义的服务,无论是在开发阶段或部署阶段都是独立的。
●微服务能使用不同的语言开发。
●易于和第三方集成,微服务允许容易且灵活的方式集成自动部署,通过持续集成工具,如jenkins, Hudson,bamboo
●微服务易于被一一个开发人员理解,修改和维护,这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
●微服务允许你利用融合最新技术。
●微服务只是业务逻辑的代码,不会和HTML,CSS 或其他界面混合
●每个微服务都有自己的存储能力,可以有自己的数据库,也可以有统一数据库
缺点:
●开发人员要处理分布式系统的复杂性
●多服务运维难度,随着服务的增加,运维的压力也在增大
●系统部署依赖
●服务间通信成本增加
●数据的一致性
●系统集成测试
SpringCloud和SpringBoot关系
●SpringBoot专注于快速方便的开发单个个体微服务。- Jar
●SpringCloud是 关注全局的微服务协调整理治理框架,它将SpringBoot开发的- -个个单体微服务整合并管理起来,为各个微服务之间提供:配置管理,服务发现,断路器,路由,微代理,事件总线,全局锁,决策竞选,分布式会话等等集成服务。
●SpringBoot可以离开SpringClooud独立使用,开发项目,但是SpringCloud离不开SpringBoot,属于依赖关系
●SpringBoot专注于快速、 方便的开发单个个体微服务, SpringCloud关注全局的服务治理框架
springcloud介绍
传统成熟的服务架构:应用服务化拆分+消息中间件
SpringCloud 和Dubbo有哪些区别?
最大区别: SpringCloud抛弃了Dubbo的RPC通信,采用的是基于HTTP的REST方式。
严格来说,这两种方式各有优劣。虽然从一定程度上来说,后者牺牲了服务调用的性能,但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活,服务提供方和调用方的依赖只依靠一纸契约, 不存在代码级别的强依赖,这在强调快速演化的微服务环境下,显得更加合适。
类似品牌机和组装机的区别,springcloud功能比Dubbo覆盖的范围广,和spring其他的项目完美融合。而使用Dubbo就像组装电脑一样,选择的自由度很高但是需要很强的架构能力。
社区支持和更新力度的区别,dubbo2017年停止了更新,需要公司自行扩展升级。springcloud适合小型公司。
●https://springcoud.cc/spring-cloud-netflix.html
●中文API|文档: https://springcloud.cc/spring-cloud-dalston.html
●SpringCloud中国社区 htp://springcloud.cn/
●SpringCloud中文网 https://springcloud.cc
微服务之间是如何独立通讯的?
同步的有:RPC(远程过程调用)和基于HTTP的RESTful
异步:消息队列,要考虑消息的可靠传输、高性能,以及编程模型的变化等。
springcloud的版本选择:
一般使用G版本。
springcloud入门
父工程pom文件:
<!--打包方式 pom-->
<packaging>pom</packaging>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<junit.version>4.12</junit.version>
<log4j.version>1.2.17</log4j.version>
<lombok.version>1.16.18</lombok.version>
</properties>
<dependencyManagement>
<dependencies>
<!--springCloud的依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>Greenwich.SR1</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!--SpringBoot-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>2.1.4.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!--数据库-->
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.47</version>
</dependency>
<!--数据源-->
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>druid</artifactId>
<version>1.1.10</version>
</dependency>
<!--SpringBoot 启动器-->
<dependency>
<groupId>org.mybatis.spring.boot</groupId>
<artifactId>mybatis-spring-boot-starter</artifactId>
<version>1.3.2</version>
</dependency>
<!--日志和测试-->
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>1.2.3</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${junit.version}</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>${log4j.version}</version>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>${lombok.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
创建一个子工程springcloud-api
pom文件:
<!--当前Module自己需要的依赖,如果父工程已经配置了版本就不需要写了-->
<dependencies>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
</dependency>
</dependencies>
创建一个实体类,和数据库对应,形成类表关系映射:
@Data
@NoArgsConstructor
@Accessors(chain = true) //链式写法
public class Dept implements Serializable {
private Long deptno;
private String dname;
//判断这个数据是存在哪个数据库的字段
private String db_source;
public Dept(String dname) {
this.dname = dname;
}
}
创建一个子工程springcloud-provider-dept-8001 (服务提供者)
pom文件:
<dependencies>
<!--我们需要拿到实体类,所以需要配置api-->
<dependency>
<groupId>org.example</groupId>
<artifactId>springcloud-api</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
导如了api 的依赖我们就可以在这个模块使用api模块的实体类
配置yml文件:
server:
port: 8001
#mybatis配置
mybatis:
type-aliases-package: com.lv.springcloud.pojo
config-location: classpath:mybatis/mybatis-config.xml
mapper-locations: classpath:mybatis/mapper/*.xml
#spring配置
spring:
application:
name: springcloud-provider-dept
datasource:
type: com.alibaba.druid.pool.DruidDataSource #数据源
driver-class-name: org.gjt.mm.mysql.Driver
url: jdbc:mysql://localhost:3306/db01?useUnicode=true&characterEncoding=utf-8
data-username: root
data-password: root
解析:
- mybatis配置中config-location的意思是配置文件的位置,mapper-locations的意思是mapper文件的位置
- spring的配置中数据源的配置中useUnicode=true&characterEncoding=utf-8是必须的,建议背下来。
mybatis-config.xml:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE configuration
PUBLIC "-//mybatis.org//DTD Config 3.0//EN"
"http://mybatis.org/dtd/mybatis-3-config.dtd">
<configuration>
<settings>
<!--开启二级缓存-->
<setting name="cacheEnabled" value="true"/>
</settings>
</configuration>
先写mapper(dao)层:
@Mapper
@Repository
public interface DeptMapper {
public boolean addDept(Dept dept);
public Dept queryDeptById(Long id);
public List<Dept> queryAll();
}
再写mapper调用数据库的xml文件:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper
PUBLIC "-//mybatis.org//DTD Config 3.0//EN"
"http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.lv.springcloud.mapper.DeptMapper">
<insert id="addDept" parameterType="Dept">
insert into db01.dept (dname, db_source)
values (#{dname},DATABASE());
</insert>
<select id="queryDeptById" resultType="Dept" parameterType="Long">
select * from db01.dept where deptno = #{deptno};
</select>
<select id="queryAll" resultType="Dept">
select * from db01.dept;
</select>
</mapper>
然后service层调用mapper:
public interface DeptService {
public boolean addDept(Dept dept);
public Dept queryDeptById(Long id);
public List<Dept> queryAll();
}
@Service
public class DeptServiceImpl implements DeptService {
@Autowired
private DeptMapper deptMapper;
@Override
public boolean addDept(Dept dept) {
return deptMapper.addDept(dept);
}
@Override
public Dept queryDeptById(Long id) {
return deptMapper.queryDeptById(id);
}
@Override
public List<Dept> queryAll() {
return deptMapper.queryAll();
}
}
controller层调用service:
@RestController
@RequestMapping("/dept")
public class DeptController {
@Autowired
private DeptService deptService;
@PostMapping("/add")
public boolean addDept(Dept dept){
return deptService.addDept(dept);
}
@GetMapping("/get/{id}")
public Dept getById(@PathVariable("id") Long id){
return deptService.queryDeptById(id);
}
@GetMapping("/list")
public List<Dept> queryAll(){
return deptService.queryAll();
}
}
最后创建springboot启动器:
@SpringBootApplication
public class DeptProvider_8001 {
public static void main(String[] args) {
SpringApplication.run(DeptProvider_8001.class,args);
}
}
在网站输入http://localhost:8001/dept/list 即可。
到此,服务的提供者创建完成。
服务消费者
创建一个新的子模块,springcloud-consumer-dept-80
RestTemplate
是Spring用于同步client端的核心类,简化了与http服务的通信,并满足RestFul原则,程序代码可以给它提供URL,并提取结果。RestTemplate能大幅简化了提交表单数据的难度,并且附带了自动转换JSON数据的功能
把RestTemplate 注册到容器中
@Configuration
public class ConfigBean {
@Bean
public RestTemplate getRestTemplate(){
return new RestTemplate();
}
}
这样消费者就可以使用RestTemplate 远程访问
@RestController
public class DeptConsumerController {
@Autowired
private RestTemplate restTemplate;
private static final String REST_URL_PREFIX = "http://localhost:8001";
@RequestMapping("/consumer/dept/add")
public boolean add(Dept dept){
return restTemplate.patchForObject(REST_URL_PREFIX+"/dept/add",dept,Boolean.class);
}
@RequestMapping("/consumer/dept/get/{id}")
public Dept get(@PathVariable("id") Long id){
return restTemplate.getForObject(REST_URL_PREFIX+"/dept/get/"+id,Dept.class);
}
@RequestMapping("/consumer/dept/list")
public List<Dept> list(){
return restTemplate.getForObject(REST_URL_PREFIX+"/dept/list",List.class);
}
}
在消费者模块中直接通过controller就可以访问服务者模块的service层,只需要定义一个:REST_URL_PREFIX = "http://localhost:8001"
,然后再利用RestTemplate的api:比如getForObject拼接成http://localhost:8001/dept/list
的形式,然后写上返回值就可以通过url访问。
在浏览器:http://localhost/consumer/dept/list 既可以访问了
Eureka
Eureka是Netflix的一个子模块,也是核心模块之一。Eureka是一 个基于REST的服务,用于定位服务,以实现云端中间层服务发现和故障转移,服务注册与发现对于微服务来说是非常重要的,有了服务发现与注册,只需要使用服务的标识符,就可以访问到服务,而不需要修改服务调用的配置文件了,功能类似于Dubbo的注册中心,比如Zookeeper
Eureka包含两个组件: Eureka Server和Eureka Client。
Eureka Server提供服务注册服务,各个节点启动后,会在EurekaServer中进行注册,这样Eureka Server中的服务注册表中将会村粗所有可用服务节点的信息,服务节点的信息可以在界面中直观的看到。
Eureka Client是一个Java客户端, 用于简化EurekaServer的交互,客户端同时也具备一个内置的,使用轮询负载算法的负载均衡器。在应用启动后,将会向EurekaServer发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳,EurekaServer将会从服务注册表中把这个服务节点移除掉(默认周期为90秒)
Eureka Server之间通过复制的方式完成数据的同步,Eureka还提供了客户端缓存机制,即使所有的Eureka Server都挂掉,客户端依然可以利用缓存中的信息消费其他服务的API。综上,Eureka通过心跳检查、客户端缓存等机制,确保了系统的高可用性、灵活性和可伸缩性。
注册中心Eureka Server的创建
新建一个子模块springcloud-eureka-7001
导入依赖:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
<version>1.4.6.RELEASE</version>
</dependency>
如下配置:
server:
port: 7001
#Eureka配置
eureka:
instance:
hostname: localhost #Eureka服务端的实例名称
client:
fetch-registry: false #false表示自己是注册中心
register-with-eureka: false #表示是否像注册中心注册自己
service-url: #监控的页面
defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
启动类:
@SpringBootApplication
@EnableEurekaServer
public class EurekaService_7001 {
public static void main(String[] args) {
SpringApplication.run(EurekaService_7001.class);
}
}
@EnableEurekaServer:启动eureka服务器。
在浏览器输入:http://localhost:7001/ 即可访问eureka服务监控中心。
服务注册
导入依赖:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
<version>1.4.6.RELEASE</version>
</dependency>
配置:
#eureka配置
eureka:
client:
service-url:
defaultZone: http://localhost:7001/eureka/
instance:
instance-id: springcloud-provider-dept-8001 #修改默认状态描述信息
启动类增加注解:@EnableEurekaClient
刷新页面可以看到8001注册成功。
如果遇到爆红。
这是触发了Eureka的自我保护机制。可以通过在yml中配置来关停自我保护:
eureka:
server:
enable-self-preservation:false#关闭自我保护模式(缺省为打开)
一句话总结自我保护机制:某时刻某一个微服务不可以用了 ,eureka不会立刻清理,依旧会对该微服务的信息进行保存!
●默认情况下,如果EurekaServer在一 定时间内没有接收到某 个微服务实例的心跳,EurekaServer将 会注销该实例(默认90秒)。但是当网络分区故障发生时,微服务与Eureka之间无法正常通行,以上行为可能变得非常危险了-因为微服务本身其实是健康的,此时本不应该注销这个服务。Eureka通过 自我保护机制来解决这个问题–当EurekaServer节点在短时间内丢失过多客户端时(可能发生了网络分区故障),那么这个节点就会进入自我保护模式。-旦进入该模式,EurekaServer就 会保护服务注册表中的信息,不再删除服务注册表中的数据(也就是不会注销任何微服务)。当网络故障恢复后,该EurekaServer节 点会自动退出自我保护模式。
●在自我保护模式中,EurekaServer会保护服务注册表中的信息,不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时,该EurekaServer节 点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息,也不盲目注销任何可能健康的服务实例。
●综上,自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务(健康的微服务和不健康的微服务都会保留),也不盲目注销任何健康的微服务。使用自我保护模式,可以让Eureka集群更加的健壮和稳定。
eureka和zookeeper都可以提供服务注册与发现的功能,请说说两个的区别?
CAP是什么?
●C (Consistency) 强一致性
●A(Availability) 可用性
●P (Partition tolerance) 分区容错性
CAP的三进二: CA. AP、CP
CAP理论的核心
●一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求
●根据CAP原理,将NoSQL数据库分成了满足CA原则,满足CP原则和满足AP原则三大类:
。CA:单点集群,满足一致性,可用性的系统,通常可扩展性较差
。CP:满足-致性,分区容错性的系统,通常性能不是特别高
。AP:满足可用性,分区容错性的系统,通常可能对一致性要求低一-些
●Zookeeper保证的是CP;
●Eureka保证的是AP;
Eureka看明白了这一点,因此在设计时就优先保证可用性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时,如果发现连接失败,则会自动切换至其他节点,只要有一台Eureka还在,就能保住注册服务的可用性,只不过查到的信息可能不是最新的,除此之外,Eureka还有一 种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:
- Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
- Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其他节点上(即保证当前节点依然可用)
- 当网络稳定时,当前实例新的注册信息会被同步到其他节点中
因此,Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使整 个注册服务瘫痪
Ribbon
ribbon是什么?
●Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。
●简单的说,Ribbon是Netflix发布的开源项目,主要功能是提供客户端的软件负载均衡算法,将NetFlix的中间层服务连接在一起。Ribbon的客户端组件提供一系列完整的配置项如:连接超时、重试等等。简单的说,就是在配置文件中列出LoadBalancer (简称LB:负载均衡)后面所有的机器,Ribbon会 自动的帮助你基于某种规则(如简单轮询,随机连接等等)去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法
ribbonn能干嘛?
LB,即负载均衡(Load Balance),在微服务或分布式集群中经常用的一种应用。
负载均衡简单的说就是将用户的请求平摊的分配到多个服务上,从而达到系统的HA (高可用)。
springcloud继承Ribbon
导入依赖:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-ribbon</artifactId>
<version>1.4.6.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
<version>1.4.6.RELEASE</version>
</dependency>
@LoadBalanced可以实现负载均衡。
Ribbon 和Eureka 整合以后,客户端可以直按调用,不用关心IP地址和端口号
Feign
Feign能干什么?
●Feign旨在使编写Java Http客户端变得更容易
●前面在使用Ribbon + RestTemplate时, 利用RestTemplate对Http请求的封装处理, 形成了一套模板化的调用方法。但是在实际开发中,由于对服务依赖的调用可能不止一处,往往一个接口会被多处调用, 所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。所以,Feign在此基础. 上做了进一步封装,由他来帮助我们定义和实现依赖服务接口的定义,在Feign的实现下,我们只需要创建一个接口并使用注解的方式来配置它(类似于以前Dao接口上标注Mapper注解,现在是一个微服务接口 上面标注一个Feign注解即可。)即可完成对服务提供方的接口绑定,简化了使用Spring Cloud Ribbon时,自动封装服务调用客户端的开发量。
Feign继承了Ribbon
使用:
导入依赖
在服务层写一个接口,添加注解:@FeignClient
value值是需要去找的服务自动完成负载均衡。
Hystrix
分布式系统面临的问题
复杂分布式体系结构中的应用程序有数十个依赖关系,每个依赖关系在某些时候将不可避免的失败
服务雪崩
多个微服务之间调用的时候,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其他的微服务,这就是所谓的“扇出"、如果扇出的链路上某个微服务的调用响应时间过长或者不可用,对微服务A的调用就会占用越来越多的系统资源,进而引起系统崩溃,所谓的"雪崩效应"。
对于高流量的应用来说,单- -的后端依赖可能会导致所有服务器上的所有资源都在几秒中内饱和。比失败更糟糕的是,这些应用程序还可能导致服务之间的延迟增加,备份队列,线程和其他系统资源紧张,导致整个系统发生更多的级联故障,这些都表示需要对故障和延迟进行隔离和管理,以便单个依赖关系的失败,不能取消整个应用程序或系统。
什么是Hystrix?
Hystrix是一个用于处理分布式系统的延迟和容错的开源库,在分布式系统里,许多依赖不可避免的会调用失败,比如超时,异常等,Hystrix能够保证在一个依赖出问题的情况下, 不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性。
“断路器”本身是一种开关装置, 当某个服务单元发生故障之后,通过断路器的故障监控(类似熔断保险丝) ,
向调用方返回-个服务预期的,可处理的备选响应(FallBack) ,而不是长时间的等待或者抛出调用方法无法处理的异常,这样就可以保证了服务调用方的线程不会被长时间,不必要的占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩
Hystrix能干嘛
●服务降级
●服务熔断
●服务限流
●接近实时的监控
Hystrix使用
服务熔断:
熔断机制是对应雪崩效应的一种微服务链路保护机制。
当扇出链路的某个微服务不可用或者响应时间太长时,会进行服务的降级,进而熔断该节点微服务的调用,快速返回错误的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况, 当失败的调用到一定阈值,缺省是5秒内20次调用失败就会启动熔断机制。
熔断机制的注解是@HystrixCommand
导入依赖
@HystrixCommand
的fallbackMethod方法可以让该方法失败时调用备选方法。
在启动类添加注解:
@EnableCircuitBreaker
//添加对熔断的支持
即可完成。
服务降级
服务熔断:服务端
某个服务超时或者异常,引起熔断,达到保险丝的功能
服务降级:客户端
从整体网站请求负载考虑,当某个服务熔断或者关闭之后,服务将不再被调用,我们可以准备一个FailbackFactory(接口),返回一个默认值。
Zuul 路由网关
Zuul包含了对请求的路由和过滤两个最主的功能:
其中路由功能负责将外部请求转发到具体的微服务实例上,是实现外部访问统一入口的基础, 而过滤器功能则负责对请求的处理过程进行干预,是实现请求救验,服务聚合等功能的基础。Zuul和Eureka进行整合,将Zuu自身注册为Eureka服务治理下的应用,同时从Ereka中获得其他微服务的消息,也即以后的访问微服务都是通过Zuul跳转后获得。
注意: Zuul服务最终还是会注册进Eureka
提供:代理+路由+过滤 三个功能