江苏龙网

  1. 主页 > 生活百科 > >

微服务：Eureka，Ribbon，Hystrix

微服务

网关组件 Zuul 性能一般，未来将退出 Spring Cloud 生态圈，所以直接使用 GateWay，把 GateWay 划分到第一代 Spring Cloud 核心组件中 。
各组件整体结构如下：
Gateway：所有服务的入口；日志、黑白名单、鉴权 。Ribbon：负载均衡 。?Hystrix：熔断器，服务熔断，服务降级 。?Feign：远程调用 。?Eureka：服务注册与发现；微服务名称、IP、端口号 。?Config：搭建配置中心微服务；实现对配置文件的统一管理，配置自动刷新 - bus 。?Actor---> Gateway 网关--转发--> {[搜索微服务，搜索微服务]，[商品微服务，商品微服务]，[支付微服务，支付微服务]，[秒杀微服务，秒杀微服务]，RestTemplate + Ribbon + Hystrix 或 Feign}---->{服务注册中心 Eureka，配置中心 Config}从形式上来说，Feign 一个顶三，Feign = RestTemplate + Ribbon + Hystrix 。
 
Eureka 服务注册中心常用的服务注册中心：Eureka、Nacos、Zookeeper、Consul 。
关于服务注册中心注意：服务注册中心本质上是为了解耦服务提供者和服务消费者 。
服务消费者 -> 服务注册中心 -> 服务提供者 。
对于任何一个微服务，原则上都应存在或者支持多个提供者（比如商品微服务部署多个实例），这是由微服务的分布式属性决定的 。
更进一步，为了支持弹性扩、缩容特性，一个微服务的提供者的数量和分布往往是动态变化的，也是无法预先确定的 。因此，原本在单体应用阶段常用的静态 LoadBalance 机制就不再适用了，需要引入额外的组件来管理微服务提供者的注册与发现，而这个组件就是服务注册中心 。
注册中心实现原理1. 启动：容器 --> 服务注册中心容器 --> 服务提供者容器 --> 服务消费者?2. 注册：服务消费者 --> 服务注册中心服务提供者 --> 服务注册中心?3. 获取服务信息：服务消费者 <--获取服务信息--> 服务注册中心?4. Invoke：服务消费者 --负载均衡-熔断机制--> 服务提供者分布式微服务架构中，服务注册中心用于存储服务提供者地址信息、服务发布相关的属性信息，消费者通过主动查询和被动通知的方式获取服务提供者的地址信息，而不再需要通过硬编码方式得到提供者的地址信息 。消费者只需要知道当前系统发布了那些服务，而不需要知道服务具体存在于什么位置，这就是透明化路由 。
1）服务提供者启动 。
2）服务提供者将相关服务信息主动注册到注册中心 。
3）服务消费者获取服务注册信息：Pull 模式 - 服务消费者可以主动拉取可用的服务提供者清单；Push 模式 - 服务消费者订阅服务，当服务提供者有变化时，注册中心也会主动推送更新后的服务清单给消费者 。
4）服务消费者直接调用服务提供者 。
另外，注册中心也需要完成服务提供者的健康监控，当发现服务提供者失效时需要及时剔除 。
主流服务中心对比Zookeeper：
Dubbo + Zookeeper?zookeeper = 存储 + 监听通知?Zookeeper 是一个分布式服务框架，是 Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等 。?Zookeeper 用来做服务注册中心，主要是因为它具有节点变更通知功能，只要客户端监听相关服务节点，服务节点的所有变更，都能及时的通知到监听客户端，这样作为调用方只要使用 Zookeeper 的客户端就能实现服务节点的订阅和变更通知功能了，非常方便 。另外，Zookeeper 可用性也可以，因为只要半数以上的选举节点存活，整个集群就是可用的，最少节点数为 3 。Eureka：
Eureka 由 Netflix 开源，并被 Pivatal 集成到 Spring Cloud 体系中，它是基于 RestfulAPI 风格开发的服务注册与发现组件 。Consul：
Consul 是由 HashiCorp 基于 Go 语言开发的支持多数据中心分布式高可用的服务发布和注册服务软件，采用 Raft 算法保证服务的一致性，且支持健康检查 。Nacos：
Nacos 是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台 。简单来说 Nacos 就是注册中心 + 配置中心的组合，帮助我们解决微服务开发必会涉及到的服务注册与发现，服务配置，服务管理等问题 。Nacos 是 Spring Cloud Alibaba 核心组件之一，负责服务注册与发现，还有配置 。CAP 定理：
CAP 定理又称 CAP 原则，指的是在一个分布式系统中，Consistency 一致性、 Availability 可用性、Partition tolerance 分区容错性，最多只能同时三个特性中的两个，三者不可兼得 。?P：分区容错性 - 分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务（一定的要满足的） 。?C：数据一致性 - all nodes see the same data at the same time.?A：高可用 - Reads and writes always succeed.?CAP 不可能同时满足三个，要么是 AP，要么是 CP 。


推荐阅读


上一篇：使用 Go 打造另一款简单实用的 ORM

下一篇：InnoDB自增原理都搞不清楚，还怎么CRUD？