SpringCloud原生五大组件简述

---

1 Spring Cloud简易架构图

SpringCloud作为Spring家族中的一员，它将现在非常流行的一些技术整合到一起，实现了微服务中诸如：配置管理，服务发现，智能路由，负载均衡，熔断器，控制总线，集群状态等等功能。

其主要涉及的组件包括：
1.Eureka：注册中心
2.Zuul：服务网关
3.Ribbon：负载均衡
4.Feign：服务调用
5.Hystix：熔断器

Zuul/Spring Cloud Gatway:网关
这么多的系统，电商系统包含了20个子系统，每个子系统有20个核心接口，一共电商系统有400个接口，这么多的接口，直接对外暴露，前后端分离的架构，难道你让前端的同学必须记住你的20个系统的部署的机器，他们去做负载均衡，记住400个接口

微服务那块，网关

灰度发布、统一熔断、统一降级、统一缓存、统一限流、统一授权认证

Hystrix、链路追踪、stream、很多组件，Hystrix这块东西，其实是会放在高可用的环节去说的，并不是说一个普通系统刚开始就必须得用的，没有用好的话，反而会出问题，Hystrix线路熔断的框架，必须得设计对应的一整套的限流方案、熔断方案、资源隔离、降级机制，配合降级机制来做

2 Eureka注册中心

简述：

​ Eureka就好比是一个公司的后台，负责管理、记录服务提供者的信息。我们只要将我们的微服务注册到Eureka中去，我们的服务调用者在调用微服务的时候，就无需自己寻找服务，而是把自己的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你，从而完成微服务的调用。

图解：

Eureka架构中的三个核心角色：
①服务注册中心
Eureka的服务端应用，提供服务注册和发现功能，就是刚刚我们建立的eureka-demo

②服务提供者
提供服务的应用，可以是SpringBoot应用，也可以是其它任意技术实现，只要对外提供的是Rest风格服务即可。

③服务消费者
消费应用从注册中心获取服务列表，从而得知每个服务方的信息，知道去哪里调用服务方。

2 负载均衡Ribbon

简述:

Ribbon是我们SpringCould采用的一种负载均衡器，它的主要作用在于，当我们同一个功能的微服务开启了很多个时，当我们需要调用微服务时所遵循的一种微服务调用的规则，这样我们才能准确的调用响应的微服务。所以，只要我们为Ribbon配置了提供服务者的同一类微服务的地址列表后，我们的Ribbon就可以基于某种负载均衡的算法自动的帮助服务事物消费者去请求服务。Ribbon默认的为我们提供了轮循，随机等负载均衡的算法，同时我们也可以自定义负载均衡的算法。

3 Hystrix熔断器

简述:

熔断器Hystrix是容错管理工具，作用是通过隔离、控制服务从而对延迟和故障提供更强大的容错能力，避免整个系统被拖垮。复杂分布式架构通常都具有很多依赖，当一个应用高度耦合其他服务时非常危险且容易导致失败，这种失败很容易伤害服务的调用者，最后导致一一个接一个的连续错误，应用本身就处在被拖垮的风险中，最后失去控制，就像在一一个高流量的网站中，某个单一的后端一旦发生延迟，将会在数秒内导致所有应用资源被耗尽。如何处理这些问题是有关系统性能和效率的关键性问题。 当在系统高峰时期，大量对微服务的调用可能会堵塞远程服务器的线程池，如果这个线程池没有和主应用服务器的线程池隔离，就可能导致整个服务器挂机。 Hystrix使用自己的线程池，这样和主应用服务器线程池隔离，如果调用花费很长时间，会停止调用，不同的命令或命令组能够被配置使用它们各自的线程池，可以隔离不同的服务。

图解：

正常工作的情况下，客户端请求调用服务API接口：

当有服务出现异常时，直接进行失败回滚，服务降级处理：

Hystrix熔断器主要的作用就是当我们的服务繁忙时，如果服务出现异常，不是粗暴的直接报错，而是返回一个友好的提示，虽然拒绝了用户的访问，但是会返回一个结果。这就好比去买鱼，平常超市买鱼会额外赠送杀鱼的服务。等到逢年过节，超时繁忙时，可能就不提供杀鱼服务了，这就是服务的降级。系统特别繁忙时，一些次要服务暂时中断，优先保证主要服务的畅通，一切资源优先让给主要服务来使用，在双十一、618时，京东天猫都会采用这样的策略。

4 Feign服务的远程调用

微服务架构中，微服务间调用的一个组件。

5 Zuul网关

简述:

​ Zuul是Netfix开源的微服务网关，它可以和Eureka、Ribbon、Hystrix 等组件配合使用。Zuul的核心是一-系列的过滤器，这些过滤器可以完成以下功能。

●身份认证与安全:识别每个资源的验证要求，并拒绝那些与要求不符的请求。

●审查与监控:在边缘位置追踪有意义的数据和统计结果，从而带来精确的生产视图。

●动态路由:动态地将请求路由到不同的后端集群。

●压力测试:逐渐增加指向集群的流量，以了解性能。

●负载分配:为每一~种负载类型分配对应容量,并弃用超出限定值的请求。

●静态响应处理:在边缘位置直接建立部分响应，从而避免其转发到内部集群。

●多区域弹性:跨越AWS Region进行请求路由，旨在实现ELB ( Elastic Load Balancing )使用的多样化，以及让系统的边缘更贴近系统的使用者。

图解:

​ 不管是来自于客户端（PC或移动端）的请求，还是服务内部调用。一切对服务的请求都会经过Zuul这个网关，然后再由网关来实现 鉴权、动态路由等等操作。Zuul就是我们服务的统一入口，即，我们可以通过Zuul网关实现微服务的统一调用。

6 分布式与微服务关系概述:

​ 分布式是指将不同的业务分布在不同的地方。而集群指的是将几台服务器集中在一起，实现同一业务。分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。