// 最近在学习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