Day14_Spring Cloud

快速回忆

分布式、集群、微服务的区别

分布式：一个大业务分拆多个子业务，部署在不同的服务器上。一个节点垮了，那这个大业务就不可访问了。

集群：同一个业务，部署在多个服务器上

微服务：与分布式比较相似，微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，一个服务做一件事，服务之间互相协调、互相配合，拥有自己独立的数据库，并且能够被独立地部署到生产环境。

什么是 Spring Cloud？

spring cloud 是将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供服务注册中心--服务调用--服务网关---服务总线---服务配置---服务降级

springcloud核心组件及其作用

服务注册中心：Eureka、Zookeeper、Nacos
Eureka：服务注册中心。每个服务都向Eureka Server登记自己提供服务的元数据，包括服务的ip地址、端口号、版本号、通信协议等。eureka server将各个服务维护在了一个服务清单中。Eureka的Client连接到 Eureka Server并维持心跳连接，这样系统的维护人员就可以通过 Eureka Server来监控系统中各个微服务是否正常运行。eureka注册的服务之间调用不需要指定服务地址，而是通过服务名向注册中心咨询，并获取所有服务实例清单(缓存到本地)，然后实现服务的请求访问。
Zookeeper：说一下“Eureka和zookeeper都可以提供服务注册与发现的功能，两者的区别”

服务调用：Ribbon、Feign
Ribbon：Ribbon+RestTemplate是自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤比较繁琐。
Feign：在Ribbon的基础上进行了一次改进，采用接口调用的方式，将需要调用的其他服务的方法定义成抽象方法即可，不需要自己构建http请求，不过要注意的是抽象方法的注解、方法签名要和提供方的完全一致。

服务总线：Bus
Spring Cloud Config做配置中心时需要用到Spring Cloud Bus，而且Spring Cloud config实时刷新也必须采用 SpringCloud Bus消息总线

灰度发布是什么？

灰度发布（又名金丝雀发布）：先分配一小部分请求流量到新版本，看看有没有问题，没问题的话，再一点点地增加流量，最终让所有流量都切换到新版本。

蓝绿发布

蓝绿发布通过同时运行两个完全相同的生产环境：一个蓝色环境（生产环境）和一个绿色环境（测试环境）。

• 蓝绿发布：使用并行环境来同时部署新旧版本的应用程序：蓝色环境（生产环境），绿色环境（测试环境）
• 灰度发布：则不需要并行环境，而是先分配一小部分请求流量到新版本，看看有没有问题，没问题的话，再一点点地增加流量，最终让所有流量都切换到新版本。

如何提高系统的并发能力？

• 使用分布式系统：在一个项目里维护所有的模块，一个简单的需求改动都需要发布整个服务，代价太大
• 集群模式：减少单点故障。
• Redis：需要考虑缓存击穿、缓存穿透的可能性；而且Redis可以使用哨兵或Cluster；多级缓存
• 数据库：分库分表，读写分离
• MQ：如果一个请求，后台操作却很多（查询库存、下单、扣库存）等，所以可以直接给前端先返回一个成功，剩余的操作让MQ异步处理
• ES：业务线的查询维度比较复杂（比如说有十几亿的数据量且查询的条件可能是用户名、某单号等等的查询），可以引入ES
• 熔断限流降级：避免被瞬时的流量高峰冲垮
• 幂等性的保证

大白话比较三个服务注册中心

Eureka在CAP中保证AP，Zookeeper和Consul在CAP中保证CP

Zookeeper因为master挂了后需要重新进行选举，所以它不可能保证高可用；而Eureka各个节点都是平等的，保证了高可用

负载均衡：Ribbon和Nginx的区别

Nginx是服务端的负载均衡，客户端所有请求都会交给nginx，然后由Nginx负责把访问请求通过某种策略转发到服务的提供方。

Ribbon是客户端的负载均衡，Ribbon 是从 eureka 注册中心服务器端上获取服务注册信息列表，缓存到本地，当需要调用时Ribbon根据负载均衡规则获取到一个实例，然后调用这个实例的接口。

Nginx性能要好。

服务调用：Ribbon和Feign的区别

Ribbon+RestTemplate是自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤比较繁琐。

Feign则是在Ribbon的基础上进行了一次改进，采用接口调用的方式，将需要调用的其他服务的方法定义成抽象方法即可，不需要自己构建http请求，不过要注意的是抽象方法的注解、方法签名要和提供方的完全一致。

什么是Hystrix断路器？我们需要它吗？

庞大的微服务系统中，如果某一个微服务发生了故障了，调用这个服务的其他服务也会发生了故障，这样就会将服务的不可用逐步扩大到各个其他服务中，从而使整个项目的服务宕机崩溃。在这种情况下使用Hystrix我们定义了一个回退方法，返回一些默认值。

如果被调用的方法异常继续发生，则Hystrix电路将中断，并且使用者将一起跳过这个方法，并直接调用回退方法。这样给发生故障的方法留出时间去恢复。

半开: 短时间内 有恢复迹象 断路器会将部分请求发给该服务，正常调用时 断路器关闭
关闭：当服务一直处于正常状态 能正常调用

大白话谈限流、降级、熔断

浏览器直接访问/test那么我们可以对/test做个流控（限制每秒请求不能超过多少啦等等），
但是浏览器直接访问gulimall-product然后product远程调用gulimall-seckill的/test就需要用到熔断降级

（1）服务熔断

服务熔断最常见的就是gulimall-product调用gulimall-seckill，结果gulimall-seckill宕机，以前不使用sentinel的熔断的时候直接调用会报错；现在使用sentinel的熔断保护机制，远程调用失败后，会给gulimall-seckill进行服务降级，熔断对gulimall-seckill微服务的调用，gulimall-product调用自己的熔断回调方法。当检测到gulimall-seckill微服务调用响应正常后恢复调用链路。

熔断的流程就是：先给对方服务进行降级，熔断对远程微服务的调用，我们自己调用熔断回调方法，正常以后恢复链路（降级—>熔断—>恢复）

（2）服务降级

方式一：服务调用方指定降级策略（推荐）

guimal-produc调用gulimal-seckil的时候，我在调用方guimal-produc配置一下：如果请求数量很高，而gulimal-seckil在某时间以内做不出响应时，我们就不调用gulimall-seckill了

方式二：服务提供方指定降级策略（不推荐）

guimal-produc调用gulimal-seckil的时候，我在被调用方gulimal-seckil配置一下：如果请求数量很高，而我们在某时间以内做不出响应时，我们就返回一个默认的降级数据

我们一般都是在调用方qulimal-product指定降级策略
因为一旦被调用方被降级了，调用方就不远程调用了，直接走熔断回调方法，省了一次远程调用

什么是服务熔断？什么是服务降级？

服务熔断：熔断机制是应对雪崩效应的一种微服务链路保护机制。
当某个微服务不可用或者响应时间太长时，会对该微服务进行服务降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。

服务降级：
服务降级是当服务器压力剧增的情况下，对一些服务和页面有策略的降级（进行低优先级的处理），说白了，就是尽可能的把系统资源让给优先级高的服务。保证核心任务的正常运行。（当某个微服务不可用或者响应时间太长时，会对该微服务进行服务降级，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。）

一、微服务

1.什么是微服务？

微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，一个服务做一件事，服务之间互相协调、互相配合，拥有自己独立的数据库，并且能够被独立地部署到生产环境。

1.分布式、集群、微服务的区别

去饭店吃饭就是一个完整的业务，饭店的厨师、配菜师、传菜员、服务员就是分布式；厨师、配菜师、传菜员和服务员都不止一个人，这就是集群；

分布式：一个大业务分拆多个子业务，部署在不同的服务器上。一个节点垮了，那这个大业务就不可访问了。

集群：同一个业务，部署在多个服务器上

好的设计应该是分布式和集群的结合，先分布式再集群

微服务：与分布式比较相似，微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，一个服务做一件事，服务之间互相协调、互相配合，拥有自己独立的数据库，并且能够被独立地部署到生产环境。

1.微服务有哪些优缺点？

优点：

• 服务被拆分了，所以每个微服务的代码均只专注于完成该单个业务范畴的事情，这样代码的可读性好；在系统中出现问题的时候仅仅只会影响单个微服务，故障隔离性好；每个开发人员专心搞自己的东西，团队协作起来更易于沟通