安宁网站建设,网站开发实习内容,河南建设银行官方网站,淘宝网站可以做轮播吗Eureka 注册中心#xff0c;服务的注册与发现 Feign远程调用
Ribbon负载均衡#xff0c;默认轮询
Hystrix 熔断 降级
Zuul微服务网关#xff08;这个组件负责网络路由#xff0c;可以做统一的降级、限流、认证授权、安全#xff09;
Eureka
微服务的功能主要有以下几…Eureka 注册中心服务的注册与发现 Feign远程调用
Ribbon负载均衡默认轮询
Hystrix 熔断 降级
Zuul微服务网关这个组件负责网络路由可以做统一的降级、限流、认证授权、安全
Eureka
微服务的功能主要有以下几个方面
服务的注册和发现
服务的负载均衡
服务的容错
服务网关
服务配置的统一管理
链路追踪
实时日志
一个服务实例注册后会定时向服务注册中心提供 “心跳”以表明自己还处于可用的状态。当一个服务实例停止向服务注册中心提供心跳一段时间后服务注册中心会认为该服务实例不可用会将该服务实例从服务注册列表中剔 除。如果这个被剔除掉的服务实例过一段时间后继续向注册中心提供心跳那么服务注册中心会将该服务实例重新加入服务注册中心的列表中。
Eureka 是一个用于服务注册和发现的组件分为 Server (服务注册中心) 和 Client (服务提供者、服务消费者)。与 Eureka 类似得组件有 Consul 和 ZooKeeper。
Eureka 是 Spring Cloud 首选推荐的服务注册与发现组件可以与 Spring Cloud 其他组件可以无缝对接。
服务启动后向Eureka注册Eureka Server会将注册信息向其他Eureka Server进行同步当服务消费者要调用服务提供者则向服务注册中心获取服务提供者地址然后会将服务提供者地址缓存在本地下次再调用时则直接从本地缓存中取完成一次调用。
当服务注册中心Eureka Server检测到服务提供者因为宕机、网络原因不可用时则在服务注册中心将服务置为DOWN状态并把当前服务提供者状态向订阅者发布订阅过的服务消费者更新本地缓存。
著名的CAP理论指出一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。
3.1 Zookeeper保证CP
会出现这样一种情况当master节点因为网络故障与其他节点失去联系时剩余节点会重新进行leader选举。问题在于选举leader的时间太长30 ~ 120s, 且选举期间整个zk集群都是不可用的这就导致在选举期间注册服务瘫痪。在云部署的环境下因网络问题使得zk集群失去master节点是较大概率会发生的事虽然服务能够最终恢复但是漫长的选举时间导致的注册长期不可用是不能容忍的。
3.2 Eureka保证AP
Eureka在设计时就优先保证可用性。Eureka各个节点都是平等的几个节点挂掉不会影响正常节点的工作剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败则会自动切换至其它节点只要有一台Eureka还在就能保证注册服务可用(保证可用性)只不过查到的信息可能不是最新的(不保证强一致性)。
Eureka还有一种自我保护机制如果在15分钟内超过85%的节点都没有正常的心跳那么Eureka就认为客户端与注册中心出现了网络故障此时会出现以下几种情况
1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求但是不会被同步到其它节点上(即保证当前节点依然可用)
3. 当网络稳定时当前实例新的注册信息会被同步到其它节点中
因此 Eureka可以很好的应对因网络故障导致部分节点失去联系的情况而不会像zookeeper那样使整个注册服务瘫痪。
Feig 动态代理拼接请求地址以http协议发起请求
Ribbon
负载均衡是指将负载分摊到多个执行单元上常见的负载均衡有两种方式
一种是独立进程单元通过负载均衡策略将请求转发到不同的执行单元上例如 Ngnix
另一种是将负载均衡逻辑以代码的形式封装到服务消费者的客户端上服务消费者客户端维护了一份服务提供者的信息列表有了信息列表通过负载均衡策略将请求分摊给多个服务提供者从而达到负载均衡的目的例如 Ribbon
Ribbon默认采用轮询的负载均衡策略
Hystrix
在复杂的分布式系统中可能有几十个服务相互依赖这些服务由于某些原因例如机房的不可靠性、网络服务商的不可靠性等导致某个服务不可用 。 如果系统不隔离该不可用的服务可能会导致整个系统不可用。Hystrix 提供了熔断器功能能够阻止分布式系统中出现联动故障。Hystrix 是通过隔离服务的访问点阻止联动故障的并提供了故障的解决方案从而提高了整个分布式系统的弹性。
Zuul
Zuul 作为路由网关组件在微服务架构中有着非常重要的作用主要体现在以下 6 个方面
Zuul, Ribbon 以及 Eureka 相结合可以实现智能路由和负载均衡的功能Zuul 能够将请求流量按某种策略分发到集群状态的多个服务实例
网关将所有服务的 API 接口统一聚合并统一对外暴露。外界系统调用 API 接口时都是由网关对外暴露的 API 接口外界系统不需要知道微服务系统中各服务相互调用的复杂性。微服务系统也保护了其内部微服务单元的 API 接口 防止其被外界直 接调用导致服务的敏感信息对外暴露
网关服务可以做用户身份认证和权限认证防止非法请求操作 API 接口对服务器起到保护作用
网关可以实现监控功能实时日志输出对请求进行记录
网关可以用来实现流量监控在高流量的情况下对服务进行降级
API 接口从内部服务分离出来方便做测试
Zuul 的核心是一系列过滤器可以在 Http 请求的发起和响应返回期间执行一系列的过滤器
PRE 过滤器在请求路由到具体的服务之前执行这种类型的过滤器可以做安全验证例如身份验证、 参数验证等
ROUTING 过滤器用于将请求路由到具体的微服务实例。在默认情况下它使用 Http Client 进行网络请求
POST 过滤器在请求己被路由到微服务后执行。 一般情况下用作收集统计 信息、指标以及将响应传输到客户端
ERROR 过滤器在其他过滤器发生错误时执行
