SpringCloud知识体系汇总
文章目录
-
- 一、简介
- 二、版本对应
- 三、总体架构及说明
- 四、服务注册中心
-
- 1、Eureka
- 2、Zookeeper
- 3、Consul
- 4、三者的区别
- 五、Ribbon负载均衡服务调用
- 六、Open Feign服务调用
- 七、Hystrix断路器
- 八、Gateway服务网关
- 九、Config分布式配置中心
- 十、Bus消息总线
- 十一、Stream 消息驱动
- 十二、Sleuth分布式请求链路跟踪
-
- 1、为什么要使用它？
- 2、官方文档
一、简介
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
github网址：https://github.com/spring-cloud
英文官网：https://spring.io/projects/spring-cloud
中文文档官网：https://www.springcloud.cc/
二、版本对应
三、总体架构及说明
Spring Cloud Netflix：
- Eureka：一个服务注册与发现框架。这也是分布式微服务的基础。
- Ribbon：客户端负载均衡之组件。nginx是将所有请求都集中起来，然后再进行负载均衡。
- Open Feign：负载均衡+远程调用，即Ribbon+RestTemplate。
- Hystrix：可进行服务限流和服务熔断，通过使用它能提高整个系统的弹性；服务限流推荐使用sentinel。
- Zuul：微服务网关，本文主要介绍gateway，并进行两者区分。
- Config：分布式配置中心。
- Bus：消息总线，实现配置的全局广播和定点通知。
- Stream：消息驱动。实现消息中间件之间的交互，目前只支持kafka与rabbitmq。
- Sleuth：分布式请求链路跟踪，通过Zipkin进行图形化界面展示。
其中五大组件包括：Eureka、Zuul、Feign、Hystrix、Config。
Spring Cloud Alibaba：
- 后续写
四、服务注册中心
1、Eureka
具体内容请看我的另外一篇文章：SpringCloud之Eureka服务注册中心
2、Zookeeper
这里对zookeeper不做介绍，感兴趣可以看看：介绍Spring Cloud Zookeeper
3、Consul
引用别人的文章：Consul详解
4、三者的区别
在看上面图的时候，如果对AP、CP这些定义不了解，请先看关于CAP的一些概念：CAP简介。
看完后我们可得知这三个注册中心的区别主要在于：
- cap，上面已经讲到，eureka是AP，其余两个是CP。
- 对外暴露接口不一样，eureka和consul都能够在浏览器中访问服务信息，zookeeper不可，zookeeper需要通过命令查看服务信息。
- eureka不需要安装软件，consul和zookeeper则需要先安装才可以使用。
五、Ribbon负载均衡服务调用
具体内容请看我的另外一篇文章：springcloud之Ribbon负载均衡简介
Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。简单点说，其主要功能是提供客户端的软件负载均衡算法和服务调用。Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出Load Balancer（简称LB）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接，权重等）去连接这些机器。
六、Open Feign服务调用
具体内容请看我的另外一篇文章：Springcloud之OpenFeign服务调用
当今是微服务横行的时代，各个微服务之间相互调用是一件再平常不过的时候。在采用HTTP协议进行通信的微服务中，我们自己可能去封装一个HttpClient工具类去进行服务间的调用，封装一个HttpClient工具，我们就需要考虑一下这些事情：
- 我们在发送一个HTTP请求时，我们需要选择请求方式GET、POST、DELETE等，我们需要构建请求参数、构建请求头信息等，那么作为一个工具类我们是不是也要提供各种参数的灵活配置；
- 因为采用restful API 风格的HTTP请求参数和返回数据都是字符串的格式，那我们是否需要考虑序列化和反序列化问题；
- 当同一个服务部署到多台服务器的时候，我们是不是应该采用轮询或者随机的方式去选择服务器，这也就是我们常说的负载均衡。从另一方面来说我们的核心是解决服务间的调用，但是我们在设计一个通用HttpClient工具的时候是否也应该支持负载均衡，以及如何和负载均衡高度解耦。
为此，大名鼎鼎的Feign应时而生，我们在学习Feign的实现的时候，我们应该带着这些问题去学习Feign的实现原理。
七、Hystrix断路器
具体内容请看我的另外一篇文章：SpringCloud之Hystrix断路器
Hystrix是一个应用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等，Hystrix 能够保证在一个依赖出问题的情况下，不会导致整个体系服务失败，避免级联故障，以提高分布式系统的弹性。
“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控 (类似熔断保险丝) ，向调用方返回一个服务预期的，可处理的备选响应 (FallBack) ，而不是长时间的等待或者抛出调用方无法处理的异常，这样就可以保证了服务调用方的线程不会被长时间，不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。
八、Gateway服务网关
具体内容请看我的另外一篇文章：SpringCloud之Gateway服务网关
这里其实本应该介绍另外一种服务网关Zuul，毕竟这个才是Spring自己的技术，但是鉴于Zuul1.x与Gateway相比逊色不少，并且Spring自己推出的升级版Zuul2.x暂未整合，因此我们这里主要介绍Gateway。具体Zuul和gateway的区别上面文章里也有写到。
我们这里可以简单的理解服务网关 = 路由转发 + 过滤器：
- 路由转发：接收一切外界请求，转发到后端的微服务上。
- 过滤器：在服务网关中可以完成一系列的横切功能，例如权限校验、限流以及监控等，这些都可以通过过滤器完成（其实路由转发也是通过过滤器实现的）。
九、Config分布式配置中心
具体内容请看我的另外一篇文章：SpringCloud之Config分布式配置中心
SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。
SpringCloud Config分为服务端和客户端两部分。 服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密/解密信息等访问接口，客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理，并且可以通过git客户端工具来方便的管理和访问配置内容。
十、Bus消息总线
具体内容请看我的另外一篇文章：SpringCloud之bus消息总线
十一、Stream 消息驱动
一句话总结就是屏蔽底层消息中间件的差异，降低切换成本，统一消息的编程模型。实现消息中间件之间的交互，目前只支持kafka与rabbitmq。
写的太累了，因为后续我们会继续整理Nacos，因此这个暂时不进行总结，这里提供资料：
官方文档：Spring Cloud Stream 官方文档
Spring Cloud Stream中文指导手册：Spring Cloud Stream中文指导手册
这里提供一个思维导图，大家可以根据这个思路进行学习：
十二、Sleuth分布式请求链路跟踪
1、为什么要使用它？
在微服务框架中，一个由客户端发起的请求在后端系统中会经过多个不同的的服务节点调用来协同产生最后的请求结果，每一个前段请求都会形成一条复杂的分布式服务调用链路，链路中的任何一环出现高延时或错误都会引起整个请求最后的失败。
SpringCloud Sleuth 给我们提供了解决方案，它集成了Zipkin、HTrace 链路追踪工具，用服务链路追踪来快速定位问题。Zipkin使用较多。Zipkin 主要由四部分构成：收集器、数据存储、查询以及 Web 界面。Zipkin 的收集器负责将各系统报告过来的追踪数据进行接收；而数据存储默认使用 Cassandra，也可以替换为 MySQL；查询服务用来向其他服务提供数据查询的能力，而 Web 服务是官方默认提供的一个图形用户界面。
2、官方文档
官方文档：SpringCloud Sleuth官方文档
GitHub路径：spring-cloud/spring-cloud-sleuth