springcloud 小结【持续更新】

// 最近在学习springcloud的一套服务，想用自己的话总结一波。
使用的技术栈是：
服务注册：eureka --> zookeeper、consul、nacos
负载均衡：ribbon/feign --> ribbon、loadBalancer/openFeign
服务熔断，服务降级：hystrix --> resilience4j、sentienl
路由网关：zuul --> zuul2、gateway
服务配置：config --> nacos

这一套服务如今许多技术框架已经迭代，我在箭头后进行了标注。但了解其作用及本质最为重要，所以还是以之前的一套进行总结。
此文不讲具体的实现方式（实现方式基本就是导几个包，加几个注解），主要理解各个框架的内涵。

1. 注册中心

之前的springboot可以完整的完成一个项目的所有内容，同时也意味着如果访问量过大，程序是无法负担的。所以初心是将服务拆分，服务放在不同的服务器上，缓解访问的压力。
首先想到的是将controller层和service层解耦，即把一个项目分成消费者和提供者，将controller层放在一个服务器上，service层放在另一个服务器上。这样做的好处就是，可以设置多个服务提供者，将访问分担到不同的服务器上。如下图所示：（假设图中第一条和第二条属于服务器1的8001端口和8002端口，第三条属于服务器2的8001端口）

问题产生了，如果服务提供者所在服务器宕机或者服务本身出了问题，但消费者还把请求源源不断的发送给出问题的服务提供者，就会导致项目出错。
所以要采用服务注册的形式，作用是发现可用的服务提供者，阻止向不可用的服务提供者发送请求。
但这样做也不是完美的，如果注册中心本身挂掉就gg了。所以将服务注册以集群的方式提供服务，也就是服务注册中心。

2. 负载均衡

在已经解决了服务注册的问题后，如果消费者不能平等的访问不同的服务提供者，那也就失去了多个提供者的意义，于是就有了负载均衡。
ribbon是集成在eureka上的负载均衡框架，内含多种负载均衡策略（比如轮询访问，随机访问等），也可以自由定制。
ribbon和feign作用是一致的，都是集成在消费者端的方式。他们的区别是，ribbon是通过服务id访问提供者，feign是以接口的方式访问提供者，实现方式就是将消费者和提供者的api一一对应。但feign底层就是ribbon，代码更清晰，但效率不如ribbon高。
一个provider对应的是一台服务器上的一个端口

3. 服务熔断

在大型的项目中，一个服务提供者也不会只由一台服务器承担，也会进行拆分但是，当其中一个服务提供者出现了问题，就会导致一个请求持续的等待，更会波及到后续的请求。所以在抛出异常的地方使用服务熔断，当多次请求到异常就会触发熔断。具体操作是熔断后会执行一个新的方法替代原方法。

4. 服务降级

在现实的项目中，不同的服务的访问量是不同的。比如在双十一期间，淘宝付款服务的访问量巨大，但一些售后服务的访问量相对低，于是就选择将售后服务的一部分替换成付款服务。（这里假设淘宝付款服务和售后服务在同一台服务器上。如果在不同服务器，可以通过加入新服务器的方式优化）
服务熔断是对服务中的某个提供者的一个方法进行替换，服务降级就是对服务中的一条负载进行替换，替换成一个不处理，或者简单处理的服务，从而保证同一台服务器上的其他服务能获得更多资源。（图中假设2号服务和3号服务部署在同一台服务器）

服务降级的hystrix是通过修改集成在客户端上的feign实现的。
服务降级也分：超时降级、失败次数降级、故障降级、限流降级

5. 熔断监控

顾名思义就是监控带有熔断机制的方法的流量变化，所以要有hystrix的依赖，并且是注册在服务端。
监控面板可以更好的反应出多个方法的健康情况

6. 路由网关

负责将外部请求转发到微服务实例上，避免了向外部暴露真实地址IP。
同时还有对请求的过滤，有着请求校验和服务聚合等功能。
zuul最终还是会注册进eureka