Spring Cloud Netflix框架最基础的五大组件介绍

       Spring Cloud Netflix框架也属于Spring Cloud，Spring Cloud开发在绝大多数公司都是主流（现在更多可能是Spring Cloud Alibaba，当然后面也会介绍），不管用还是没用过，对它的几个最基本的组件有个基本了解还是挺重要的。

       这整篇文章是我对官网以及组件有了一定的了解程度才写出，仅仅基于概念而没有涉及开发配置。但篇幅有限，更多使用及介绍可以参考官网Spring Cloud Netflix框架文档版本2.2.8：Spring Cloud Netflix-2.2.8-version

五大组件分别是Eureka+Ribbon+Feign+Hystrix+Zuul

组件名称	组件作用
Eureka	注册中心，服务注册、发现等
Ribbon	负载均衡，多服务时做负载
Feign	服务间内部调用
Hystrix	熔断器，服务熔断、降级
Zuul	服务网关，所有外部请求经过网关进行过滤转发(路由+过滤+转发)

一、Eureka

---

       首先，不知道你们对注册中心有没有个基本的了解，这次说的组件Eureka就是个注册中心，也就是说所有的服务都会注册到Eureka上面。当然还有好多注册中心（zk/consul/nacos...），其实注册中心都差不了多少，学一下然后上手其他的简直轻松的不要不要的~

下面以表格方式介绍一下微服务相关术语

术语	介绍
Eureka服务端	服务注册中心，同其他服务注册中心一样，支持高可用配置。如果Eureka以集群模式部署，当集群中有分片出现故障时，那么Eureka就转入自我保护模式。它允许在分片故障期间继续提供服务的发现和注册，当故障分片恢复运行时，集群中其他分片会把它们的状态再次同步回来。
Eureka客户端	主要处理服务的注册与发现。客户端服务通过注解和参数配置的方式，嵌入在客户端应用程序的代码中，在应用程序运行时，Eureka客户端向注册中心注册自身提供的服务并周期性地发送心跳来续约它的服务租约。同时，它也能从服务端查询当前注册的服务信息并把它们缓存到本地并周期性地刷新服务状态。
服务注册	服务提供者在启动的时候会通过发送REST请求的方式将自己注册到Eureka 服务端上，同时带上了自己服务的一些元数据信息（服务名称、ip地址等）。Eureka 服务端接收到这个REST请求之后，将元数据信息存储在一个双层结构Map中，其中第一层的key是服务名，第二层的key是具体服务的实例名。
服务发现	总的来说，服务发现就是程序如何通过一个标志来获取服务列表，并且这个服务列表是能够随着服务的状态而动态变更的。这个标志可以是注解@EnableEurekaClient，也可以是@EnableDiscoveryClient注解，前者只限定Eureka可以使用，后者可以在其他注册中心使用。
服务同步	两个服务提供者分别注册到了两个不同的服务注册中心上，也就是说，它们的信息分别被两个服务注册中心所维护。此时，由于服务注册中心之间因互相注册为服务，当服务提供者发送注册请求到一个服务注册中心时，它会将该请求转发给集群中相连的其他注册中心，从而实现注册中心之间的服务同步。通过服务同步，两个服务提供者的服务信息就可以通过这两台服务注册中心中的任意一台获取到。
服务续约	在注册完服务之后，服务提供者会维护一个心跳用来持续告诉Eureka 服务端：“我还活着”，以防止Eureka 服务端的剔除任务将该服务实例从服务列表中排除出去，我们称该操作为服务续约。
服务获取	当我们启动服务消费者的时候，它会发送一个REST请求给服务注册中心，来获取上面注册的服务清单。为了性能考虑，Eureka 服务端会维护一份只读的服务清单来返回给客户端，同时该缓存清单会每隔30秒更新一次。
服务调用	服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。在Ribbon中会默认采用轮询的方式进行调用，从而实现客户端的负载均衡。
服务下线	当服务实例进行正常的关闭操作时，它会触发一个服务下线的REST请求给Eureka 服务端，告诉服务注册中心：“我要下线了”。服务端在接收到请求之后，将该服务状态置为下线（DOWN），并把该下线事件传播出去。
服务剔除	Eureka 服务端在启动的时候会创建一个定时任务，默认每隔一段时间（默认为60秒）将当前清单中超时（默认为90秒）没有续约的服务剔除出去。
自我保护机制	这个只有Eureka独有。自我保护机制，Eureka 服务端在运行期间，会统计心跳失败的比例，在15分钟之内是否低于85%，如果出现低于的情况，Eureka 服务端会将当前的实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。开发时尽量关掉它，以确保注册中心可以将不用的实例正确剔除。

       通过上面列表，你可以获得很多关于注册中心以及服务之间的术语知识，了解这些对于学习微服务至关重要。

       当然，如果你是个熟手，你可以阅读更多关于注册中心相关的知识，这里也可以给两个大神文章供参考

       Eureka是基于AP的，AP/CP更多？参考：注册中心之ap/cp，更多注册中心？参考：注册中心 分类

 

二、Ribbon

---

       组件Ribbon是用做客户端负载均衡，上面也提到，服务调用的时候，是获取到服务清单到本地（本地就是客户端）做负载均衡，默认是轮循，至于其他策略我这也不在一一强调。

Ribbon强调两个注意项

1. 请求时Ribbon是客户端代理请求，而Nginx是服务器反向代理请求（属于接收请求后转发请求）。
2. 为了确保Ribbon在重试时不被熔断，需要满足设置Hystrix大于Ribbon的超时时间。

 

三、Feign

---

       组件Feign是微服务之间内部调用常用的手段。Feign 的英文表意为“假装，伪装，变形”， 是一个HTTP请求调用的轻量级框架，可以以Java接口注解的方式调用Http请求，而不用像Java中通过封装HTTP请求报文的方式直接调用。Feign通过处理注解，将请求模板化，当实际调用的时候，传入参数，根据参数再应用到请求上，进而转化成真正的请求，这种请求相对而言比较直观。

 

四、Hystrix

---

       组件Hystrix是熔断器，主要起服务熔断和服务降级作用。这两个概念十分重要，十分重要。

服务熔断

       熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用。响应正常后恢复调用链路。在Spring Cloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，就跟保险丝一样，当服务出现故障、异常等，熔断该节点，从而快速响应错误给消费者，而不是一直等待服务超时（默认是5s内有20次调用服务失败则会熔断服务）。

服务降级

       整体资源快不够用了，忍痛将某些服务先关掉，待渡过难关再开启回来。所谓降级，一般是从整体负荷考虑。就是当某个服务熔断之后，服务将不再被调用，此时客户端可以自己准备一个本地fallback回调，返回一个缺省值。这样做，虽然服务水平下降，但好歹可用，比直接挂掉更强。

 

五、Zuul

---

       组件Zuul是服务网关，当前端与后端服务进行交互时，需要通过Zuul进行过滤，路由转发将实际请求请求到后端服务中。

       Zuul包含了对请求的路由和过滤两个最主要的功能。其中路由功能负责将外部请求转发到具体微服务实例上，是实现外部统一访问入口的基础。而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务。Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转实现。