springcloud的常用组件，以及它们的用处

1.Eureka注册中心
服务调用
use-service-demo:一个提供根据id查询用户的微服务
consumer-demo:一个服务调用者，通过RestTemplate远程调用user-service-demo
存在问题
在consumer中，我们把url地址硬编码到了代码中，不方便后期维护
consumer需要记忆user-service的地址，如果出现变更，可能得不到通知，地址将失效
consumer不清楚user-service的状态，服务宕机也不知道
user-service只有1台服务，不具备高可用性
即便user-service形成集群，consumer还需自己实现负载均衡
服务管理
如何自动注册和发现
如何实现状态监管
如何实现动态路由
Eureka架构中的三个核心角色:
服务注册中心
Eureka的服务端应用，提供服务注册和发现功能，就是刚刚我们建立的eureka-demo
服务提供者
提供服务的应用，可以是SpringBoot应用，也可以是其它任意技术实现，只要对外提供的是Rest风格服务即 可。本例中就是我们实现的user-service-demo
服务消费者
消费应用从注册中心获取服务列表，从而得知每个服务方的信息，知道去哪里调用服务方。本例中就是我们实现的consumer-demo
高可用的Eureka Server
1.EurekaServer1
server:
port: 10086 # 端口
spring:
application:
name: eureka-server # 应用名称，会在Eureka中显示 eureka:
client:
service-url: # 配置其他Eureka服务的地址，而不是自己，比如10087
defaultZone: http://127.0.0.1:10087/eureka
2.EurekaServer2
server:
port: 10087 # 端口
spring:
application:
name: eureka-server # 应用名称，会在Eureka中显示 eureka:
client:
service-url: # 配置其他Eureka服务的地址，而不是自己，比如10087
defaultZone: http://127.0.0.1:10086/eureka
3.客户端注册服务到集群
eureka:
client:
service-url: # EurekaServer地址,多个地址以’,'隔开
defaultZone: http://127.0.0.1:10086/eureka,http://127.0.0.1:10087/eureka
4.服务续约
lease-renewal-interval-in-seconds:服务续约(renew)的间隔，默认为30秒 lease-expiration-duration-in-seconds:服务失效时间，默认值90秒
2.Ribbon:负载均衡
消费者身上：
@Bean
@LoadBalanced
public RestTemplate restTemplate() {
return new RestTemplate(new OkHttp3ClientHttpRequestFactory());
}
重试机制
spring:
cloud:
loadbalancer:
retry:
enabled: true # 开启Spring Cloud的重试功能 user-service:
ribbon:
ConnectTimeout: 250 # Ribbon的连接超时时间
ReadTimeout: 1000 # Ribbon的数据读取超时时间 OkToRetryOnAllOperations: true # 是否对所有操作都进行重试 MaxAutoRetriesNextServer: 1 # 切换实例的重试次数 MaxAutoRetries: 1 # 对当前实例的重试次数

3.Hystix:熔断器
Hystix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败。
1.在消费者身上
@HystrixCommand(fallbackMethod=“queryUserByIdFallback”) :声明一个失败回滚处理函数 queryUserByIdFallback，当queryUserById执行超时(默认是1000毫秒)，就会执行fallback函数，返回错 误提示。
为了方便查看熔断的触发时机，我们记录请求访问时间。
2.在服务提供者身上
// 为了演示超时现象，我们在这里然线程休眠,时间随机 0~2000毫秒 Thread.sleep(new Random().nextInt(2000));
4.Feign:服务调用
1.你会发现RestTemplate的注册被我删除了。Feign中已经自动集成了Ribbon负载均衡，因此我们不需要自己 定义RestTemplate了
2.另外，我们可以像上节课中讲的那样去配置Ribbon，可以通过 ribbon.xx 来进行全局配置。也可以通过 服务名.ribbon.xx 来对指定服务配置:
user-service:
ribbon:
ConnectTimeout: 250 # 连接超时时间(ms)
ReadTimeout: 1000 # 通信超时时间(ms)
OkToRetryOnAllOperations: true # 是否对所有操作重试
MaxAutoRetriesNextServer: 1 # 同一服务不同实例的重试次数 MaxAutoRetries: 1 # 同一实例的重试次数
5.Zuul:服务网关
对外服务调用：
首先，破坏了服务无状态特点。
为了保证对外服务的安全性，我们需要实现对服务访问的权限控制，而开放服务的权限控制机制将会贯 穿并污染整个开放服务的业务逻辑，这会带来的最直接问题是，破坏了服务集群中REST API无状态的特 点。 从具体开发和测试的角度来说，在工作中除了要考虑实际的业务逻辑之外，还需要额外考虑对接口访问 的控制处理。
其次，无法直接复用既有接口。
当我们需要对一个即有的集群内访问接口，实现外部服务访问时，我们不得不通过在原有接口上增加校验逻辑，或增加一个代理调用来实现权限控制，无法直接复用原有的接口。
1.不管是来自于客户端(PC或移动端)的请求，还是服务内部调用。一切对服务的请求都会经过Zuul这个网 关，然后再由网关来实现 鉴权、动态路由等等操作。Zuul就是我们服务的统一入口。
2.面向服务的路由
3.过滤器
Zuul作为网关的其中一个重要功能，就是实现请求的鉴权。而这个动作我们往往是通过Zuul提供的过滤器来实现
的。
场景非常多:
请求鉴权:一般放在pre类型，如果发现没有访问权限，直接就拦截了
异常处理:一般会在error类型和post类型过滤器中结合来处理。
服务调用时长统计:pre和post结合使用。
4.负载均衡和熔断
6.config配置中心