springcloud各个组件介绍

Posted 2021-03-09 娜一抹微笑

几个Spring Cloud核心组件，在微服务架构中，分别扮演的角色：

• Eureka：各个服务启动时，Eureka Client都会将服务注册到Eureka Server，并且Eureka Client还可以反过来从Eureka Server拉取注册表，从而知道其他服务在哪里
• Ribbon：服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台
• Feign：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求
• Hystrix：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题
• Zuul：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务

////////////////////////////////////////////////////////

Feign

feign 一般是用于服务消费，什么叫服务消费呢， 譬如你有A服务，B服务。在B服务中需要调用A服务 （即B作为服务提供者，A作为服务消费者），获取结果，进行下一步动作，这个时候你可以使用resttemplate,也可以使用feign来写。

 

zuul

zuul起一个路由，分发服务（比如https://www.oschina.net/tweet/路径交给feign，而https://www.oschina.net/blog/交给bibbon）的作用，偶尔还能和自定义的过滤器协同工作。feign和ribbon都是做负载均衡（服务消费）的，和hystrix结合可以爆发强大的威力。

其余的组件，例如eureka、config client/server、zipkin、hystrixdashboard、sleuth、consul、turbine根据项目需要使用。

 

Ribbon，客户端负载均衡，特性有区域亲和、重试机制。

 

Hystrix，客户端容错保护，特性有服务降级、服务熔断、请求缓存、请求合并、依赖隔离。

 

Feign，声明式服务调用，本质上就是Ribbon+Hystrix

 

Stream，消息驱动，有Sink、Source、Processor三种通道，特性有订阅发布、消费组、消息分区。

 

Bus，消息总线，配合Config仓库修改的一种Stream实现，

 

Sleuth，分布式服务追踪，需要搞清楚TraceID和SpanID以及抽样，如何与ELK整合。

 

独挑大梁，独自启动不需要依赖其它组件。

 

Eureka，服务注册中心，特性有失效剔除、服务保护。

 

Dashboard，Hystrix仪表盘，监控集群模式和单点模式，其中集群模式需要收集器Turbine配合。

 

Zuul，API服务网关，功能有路由分发和过滤。

 

Config，分布式配置中心，支持本地仓库、SVN、Git、Jar包内配置等模式，

 

每个组件都不是平白无故的产生的，是为了解决某一特定的问题而存在。

 

Eureka和Ribbon，是最基础的组件，一个注册服务，一个消费服务。

 

Hystrix为了优化Ribbon、防止整个微服务架构因为某个服务节点的问题导致崩溃，是个保险丝的作用。

 

Dashboard给Hystrix统计和展示用的，而且监控服务节点的整体压力和健康情况。

 

Turbine是集群收集器，服务于Dashboard的。

 

Feign是方便我们程序员写更优美的代码的(消费服务)

 

Zuul是加在整个微服务最前沿的防火墙和代理器，隐藏微服务结点IP端口信息，加强安全保护的。

 

Config是为了解决所有微服务各自维护各自的配置，设置一个统一的配置中心，方便修改配置的。

 

Bus是因为config修改完配置后各个结点都要refresh才能生效实在太麻烦，所以交给bus来通知服务节点刷新配置的。

 

Stream是为了简化研发人员对MQ使用的复杂度，弱化MQ的差异性，达到程序和MQ松耦合。

 

Sleuth是因为单次请求在微服务节点中跳转无法追溯，解决任务链日志追踪问题的。

 

特殊成员Zipkin，之所以特殊是因为从jar包和包名来看它不属于Spring Cloud的一员，但是它与Spring Cloud Sleuth的抽样日志结合的天衣无缝。乍一看它与Hystrix的Dashboard作用有重叠的部分，但是他们的侧重点完全不同。Dashboard侧重的是单个服务的统计和是否可用，Zipkin侧重的监控环节时长。简言之，Dashboard侧重故障诊断，Ziokin侧重性能优化。

//////////////////////////////////////////////////////

1. Spring Cloud Config：配置管理开发工具包，可以让你把配置放到远程服务器，目前支持本地存储、Git以及Subversion。
2. 　Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud Config联合实现热部署。
3. 　Spring Cloud Netflix：针对多种Netflix组件提供的开发工具包，其中包括Eureka、Hystrix、Zuul、Archaius等。
4. Netflix Eureka：云端负载均衡，一个基于 REST 的服务，用于定位服务，以实现云端的负载均衡和中间层服务器的故障转移。
5. Netflix Hystrix：容错管理工具，旨在通过控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。
6. 　Netflix Zuul：边缘服务工具，是提供动态路由，监控，弹性，安全等的边缘服务。
7. 　Netflix Archaius：配置管理API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。
8. 　Spring Cloud for Cloud Foundry：通过Oauth2协议绑定服务到CloudFoundry，CloudFoundry是VMware推出的开源PaaS云平台。
9. Spring Cloud Sleuth：日志收集工具包，封装了Dapper,Zipkin和HTrace操作。
10. Spring Cloud Data Flow：大数据操作工具，通过命令行方式操作数据流。
11. Spring Cloud Security：安全工具包，为你的应用程序添加安全控制，主要是指OAuth2。
12. 　Spring Cloud Consul：封装了Consul操作，consul是一个服务发现与配置工具，与Docker容器可以无缝集成。
13. Spring Cloud Zookeeper：操作Zookeeper的工具包，用于使用zookeeper方式的服务注册和发现。
14. Spring Cloud Stream：数据流操作开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。
15. Spring Cloud CLI：基于 Spring Boot CLI，可以让你以命令行方式快速建立云组件。

///////////////////////////////////////////////////

Eureka/Consul：服务发现 （根据情况选择一个）

Hystrix：断路器

Zuul：智能路由

Ribbon/Feign：客户端负载均衡 （Feign用的更多）

Turbine：集群监控

Springcloud-config：远程获取配置文件

////////////////////////////////////////////////

我们从整体上来看一下Spring Cloud各个组件如何来配套使用：

 

从上图可以看出Spring Cloud各个组件相互配合，合作支持了一套完整的微服务架构。

其中Eureka负责服务的注册与发现，很好将各服务连接起来

Hystrix 负责监控服务之间的调用情况，连续多次失败进行熔断保护。

Hystrix dashboard,Turbine 负责监控 Hystrix的熔断情况，并给予图形化的展示

Spring Cloud Config 提供了统一的配置中心服务

当配置文件发生变化的时候，Spring Cloud Bus 负责通知各服务去获取最新的配置信息

所有对外的请求和服务，我们都通过Zuul来进行转发，起到API网关的作用

最后我们使用Sleuth+Zipkin将所有的请求数据记录下来，方便我们进行后续分析

Spring Cloud从设计之初就考虑了绝大多数互联网公司架构演化所需的功能，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。这些功能都是以插拔的形式提供出来，方便我们系统架构演进的过程中，可以合理的选择需要的组件进行集成，从而在架构演进的过程中会更加平滑、顺利。

微服务架构是一种趋势，Spring Cloud提供了标准化的、全站式的技术方案，意义可能会堪比当前Servlet规范的诞生，有效推进服务端软件系统技术水平的进步。

从现在开始，我这边会将近期研发的spring cloud微服务云架构的搭建过程和精髓记录下来，帮助更多有兴趣研发spring cloud框架的朋友，希望可以帮助更多的好学者。大家来一起探讨spring cloud架构的搭建过程及如何运用于企业项目。