springCloud常用组件以及其作用
springCloud是一套微服务组件， 常用的Eureka，Ribbon，Hystrix，Feign，Gateway，Config，Bus（消息总线）等等。
一、Eureka
1、Eureka：提供服务注册和发现功能
1、服务注册：在服务治理框架中，通常都会构建一个注册中心，每个服务单元向注册中心登记自己提供的服务注册中心按照服务名分类组织服务清单，同时还需要以心跳检测的方式去监测清单中的服务是否可用，若不可用需要从服务清单中剔除，以达到排除故障服务的效果。
2、失效剔除：服务注册中心在启动时会创建一个定时任务，默认每隔一段时间 （默认为60秒）将当前清单中超时（默认为90秒）没有续约的服务剔除
3、自我保护：当一个服务未按时进行心跳续约时，Eureka会统计最近15分钟心跳失败的服 务实例的比例是否超过了85%，当EurekaServer节点在短时间内丢失过多客户端（可能发生了网络分区故障）。在 生产环境下，因为网络延迟等原因，心跳失败实例的比例很有可能超标，但是此时就把服务剔除列表并不妥当，因为服务可能没有宕机。Eureka就会把当前实例的注册信息保护起来，不予剔除，在实际中，保证了大多 数服务依然可用。
2、服务提供者：也称为Eureka客户端，提供服务的应用，可以是Spring Boot应用，也可以是其它任意技术实现，只要对外提供的是REST风格服务即 可。
搭建步骤，参考我的随笔：https://www.cnblogs.com/kunmin/p/15097408.html，其中有比较重要的配置就是，
1、服务地址是否使用ip地址
2、续约时间的配置
3.服务消费者：也称为Eureka客户端，消费应用从注册中心获取服务列表，从而得知每个服务方的信息，知道去哪里调用服务方
搭建步骤参考随笔：https://www.cnblogs.com/kunmin/p/15097408.html，服务消费端比较重要的就是：
1、服务拉取时间的配置
二：Ribbon
Spring Cloud Ribbon 是一个基于Http和TCP的客服端负载均衡工具，它是基于Netflix Ribbon实现的。它不像服务注册中心、配置中心、API网关那样独立部署，但是它几乎存在于每个微服务的基础设施中，
就比如配置网关路由时，就指定了负载均衡，feign依赖里面也有对Ribbon的支持。负载均衡是对系统的高可用、网络压力的缓解和处理能力扩容的重要手段之一。常用的负载均衡策略：
1、轮询Round Robin：对注册的服务，轮流进行访问
2、随机Random：从服务列表里面随机进行访问
三，Hystrix：（服务容错保护）
在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。
解决措施：
1、线程隔离：Hystrix为每个依赖服务调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队，加 速失败判定时间。 用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，或者请求超 时，则会进行降级处理
2、服务降级：用户的请求故障时，不会被阻塞，更不会无休止的等待或者看到系统崩溃，至少可以看到一个执行结果（例如返回友好的提示信息），有两种情况会触发服务降级，1、线程池已满 ，2、请求超时
服务降级的案例，参考随笔：https://www.cnblogs.com/kunmin/p/15097408.html，
Hystrix中，还有一个断路器Circuit Breaker，当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN).下图是断路器模型。
Closed：关闭状态（断路器关闭），所有请求都正常访问。
Open：打开状态（断路器打开），所有请求都会被降级。Hystrix会对请求情况计数，当一定时间内失败请求 百分比达到阈值，则触发熔断，断路器会完全打开。默认失败比例的阈值是50%，请求次数最少不低于20 次。
Half Open：半开状态，不是永久的，断路器打开后会进入休眠时间（默认是5S）。随后断路器会自动进入半 开状态。此时会释放部分请求通过，若这些请求都是健康的，则会关闭断路器，否则继续保持打开，再次进 行休眠计时
四、Feign：
是一种声明式、模板化的HTTP客户端。我们在随笔：https://www.cnblogs.com/kunmin/p/15097408.html中，最开始搭建微服务时，就是去访问对应的url地址（如下图），这种方式是十分机械的，而且拓展性不高。feign组件，就是解决这一问题的，他可以让我们使用HTTP请求远程服务时能与调用本地方法一样的编码体验。使用feign优化服务消费者，参考博文:https://www.cnblogs.com/kunmin/p/15097408.html。
总之，feign就是更加优雅的调用远程服务。
五、Gateway：（API网关服务）：作用：安全，路由，限流，监控
微服务一般，简单的分为内部与边缘之分，内部服务顾名思义是为对内暴露服务的结点，供架构内部来调用；边缘服务是对外部网络暴露的服务结点，也就是对外API接口。Gateway就是我们统一的入口。
GateWay，最要就是在于配置文件的编写。常用的配置就是路由的id，一个提供服务的uri，一组断言工厂，一组过滤器，如图的配置就是如果路径之中包含user，就会请求到名为User-service这个服务中。当然我们也可以配置一些过滤器（局部过滤器，全局过滤器，自定义过滤器），配置步骤参考随笔：https://www.cnblogs.com/kunmin/p/15097408.html
六： Config分布式配置中心
分布式系统中，每一个功能模块都能拆分成一个独立的服务，一次请求的完成，可能会调用很多个服务协调来完成，为了方便服务配置文件统一管理，更易于部署、维护，所以就需要分布式配置中心组件了，在spring cloud中，有分布式配置中心组件spring cloud config，它支持配置文件放在在配置服务的内存中，也支持放在远程Git仓库里。我们的外部配置文件就可以集中放置在一个git仓库里，再新建一个config server，用来管理所有的配置文件，维护的时候需要更改配置时，只需要在本地更改后，推送到远程仓库，所有的服务实例都可以通过config server来获取配置文件，这时每个服务实例就相当于配置服务的客户端config client。具体的搭建步骤，参考博文：https://www.cnblogs.com/kunmin/p/15097408.html。
七：spring cloud bus 消息总线
Spring Cloud Bus 将分布式的节点用轻量的消息代理连接起来。它可以用于广播配置文件的更改或者服务之间的通讯，也可以用于监控。Spring cloud bus 通过轻量消息代理连接各个分布的节点。管理和传播所有分布式项目中的消息，本质是利用了MQ的广播机制在分布式的系统中传播消息，目前常用的有Kafka和RabbitMQ。
配置文件更新的过程：搭建步骤看随笔：https://www.cnblogs.com/kunmin/p/15097408.html
- 1、提交代码触发post请求给bus/refresh（需要提前安装\otp_win64_23.0.exe和rabbitmq-server-3.8.5.exe）
- 2、server端接收到请求并发送给Spring Cloud Bus
- 3、Spring Cloud bus接到消息并通知给其它客户端
- 4、其它客户端接收到通知，请求Server端获取最新配置
- 5、全部客户端均获取到最新的配置
以上就是自己目前所学习的微服务组件，如有不足请指出，至于如何搭建微服务框架，参考另一篇随笔：https://www.cnblogs.com/kunmin/p/15097408.html
