1、Spring Cloud Config
配置中心组件
作用：通过版本同步工具对配置进行统一管理，使得项目配置自动化，特别对于集群系统，无需手动管理每个子节点系统的配置
使用：启动类加上注解@ConfigApplication；服务端配置获取配置的git地址（或者本地）；客户服务端地址（或在结合Eureka使用时配置服务名）
2、Spring Cloud Eureka
服务发现组件
作用：统一管理各服务，维系各服务状态，实现服务的高可用性；向消费者（客户端）暴露抽象的服务名，隐藏服务实例的细节
使用：
客户端：使用@EnableEurekaClient注解；配置注册中心地址
服务端：使用@EnableEurekaServer注解；配置自身地址
3、Spring Cloud Ribbon
客户端均衡负载组件
作用：在客户端实现对服务实例的负载均衡调用
使用：Eureka客户端依赖已包含了Ribbon依赖，在提供http客户端（RestTemplate或WebClient）的方法上加@LoadBalanced即可自动进行均衡负载调用
原理：在http客户端发送请求时Ribbon将对其进行拦截，并做了以下工作：首先从先前获取的实例列表中查找对应某个服务的那些实例，然后根据负载均衡算法选取一个实例重新构造请求
4、Spring Cloud Hystrix
断路器组件
作用：
在基于传统Web容器构建的复杂项目中，对服务的每次调用都由1个线程完成（同步阻塞的），一旦某个服务运行缓慢或在调用时发生了网络阻塞问题，执行该次调用的线程将一直阻塞不能被释放，而且往后对于此下游服务的所有调用都将发生阻塞，那么在将来的某个时刻，该Web容器线程池中的线程将被耗尽，无法响应任何上游服务的调用，而上游服务也将如该层服务一样无法响应其他服务的调用，最终整个系统将走向崩溃（“雪崩”效应）。
Hystrix可以根据配置对这些意外情况做出处理，如当调用超时时快速失败或触发其他响应等，并且隔离对不同服务的调用
使用：启动类加上@EnableHystrix注解，在需要监控的方法上加@HystrixCommand，并在该注解内配置对故障的处理方案（如超时时长，失败后调用的后备方法、执行线程池等）
原理：Hystrix会对方法进行封装，令其调用发生在指定的线程池内（默认是一个包含20个线程的线程池），当我们对不同服务的调用就相互隔离了，即使负责某个服务的所有线程的全部阻塞对其他服务的调用仍可正常进行。
另外，Spring 自5版本后推出了基于Netty容器的异步非阻塞技术栈WebFlux ，因为Netty不同于传统的Web容器，它对于IO有着自己处理方案，不会有“某一线程等待IO的情况”发生；而且WebFlux自身包含的Reactor库更是提供了超时、重试、背压等特性，所以当使用此套技术栈时也许不需要引入Hystrix。
5、Spring Cloud Zuul
网关组件
作用：将网关作为一项单独的服务抽离出来，为各接口提供统一的动态路由、反向代理、过滤、权限校验、监控等功能
使用：结合Eureka使用，默认已提供了服务名——服务的路由映射，如需更改需要额外配置忽略的原服务
原理：Zuul提供的功能都基于一个个的过滤器实现，当我们需要在某个路由上执行自定义逻辑时就可以定义自己的过滤器，完全控制路由的行为。
