1.2 分布式服务框架

2.SpringCloud常用组件

2.1 Eureka

2.1.1 同为注册中心，Eureka和Zookeeper的区别：

1.前序

在梳理SpringCloud全家桶之前，我觉得有必要先说一下分布式架构。因为我们既然学习使用一种框架或者服务，必然要先了解其优缺点，这样我们才有使用的理由以及优化必要。简言之：知其然，知其所以然。

首先通过一张图，来了解传统项目架构与分布式架构之间的区别：

1.1 分布式的优缺点

1.1.1 分布式优点

增大系统容量，更好的满足业务量
提高系统高可用，不再局限于单体故障而导致整个业务的不可用
模块化、组件化，系统模块重用度更高
分布治理，松耦合
易于拓展

1.1.2 分布式缺点

架构设计变得复杂
部署、维护成本变高
系统一致性、协调性变的复杂（如分布式事务控制）
测试和查错的复杂度增大

1.2 分布式服务框架

目前国内行业中主流的分布式服务框架一般主要就是：SpringCloud全家桶、Dubbo+Zookeeper等。今天本章，我们主要聊一聊SpringCloud微服务架构中的几大常用组件的原理。

2.SpringCloud常用组件

2.1 Eureka

Eureka是SpringCloud中的核心组件，其扮演的角色与作用就是服务的注册与发现。其运行原理如下图：

上图是基于集群配置的eureka；

处于不同节点的eureka通过Replicate进行数据同步
Application Service为服务提供者（其实也是服务消费者）
Application Client为服务消费者
Make Remote Call完成一次服务调用

运行原理简言之：

各个服务启动时，Eureka Client都会将服务注册到Eureka Server的一个注册表中，该表会记录所有注册服务的所在的服务器的IP端口，并且Eureka Client还可以反过来从Eureka Server拉取注册表，并缓存在自己服务器，从而知道其他服务在哪里。

2.1.1 同为注册中心，Eureka和Zookeeper的区别：

1.ZooKeeper保证的是CP,Eureka保证的是AP

ZooKeeper在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的

Eureka各个节点是平等关系,只要有一台Eureka就可以保证服务可用,而查询到的数据并不是最新的

自我保护机制会导致：

Eureka不再从注册列表移除因长时间没收到心跳而应该过期的服务

Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其他节点(高可用)

当网络稳定时,当前实例新的注册信息会被同步到其他节点中(最终一致性)

Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像ZooKeeper一样使得整个注册系统瘫痪

2.ZooKeeper有Leader和Follower角色,Eureka各个节点平等

3.ZooKeeper采用过半数存活原则,Eureka采用自我保护机制解决分区问题

4.Eureka本质上是一个工程,而ZooKeeper只是一个进程

2.2 Feign

对于Feign的作用，我先设想一下，如果没有Feign，那么在我们平时的工作中，我们需要做哪些事？

我们需要对Eureka中的各类服务与接口，自己写请求实现类，来实现各个服务间的请求调用。对请求的网络，协议，请求格式，请求路径，请求结果等做一列封装处理。而这一切，就是Feign会为我们实现的功能。其原理图如下：

运行原理：

Feign的一个关键机制就是使用了动态代理：

首先，如果你对某个接口定义了@FeignClient注解，Feign就会针对这个接口创建一个动态代理
接着你要是调用那个接口，本质就是会调用 Feign创建的动态代理，这是核心中的核心
Feign的动态代理会根据你在接口上的@RequestMapping等注解，来动态构造出你要请求的服务的地址
最后针对这个地址，发起请求、解析响应

2.3 Ribbon

接着上面的Feign来说，如果请求的服务有多个节点或是集群，那么怎么知道会调用到哪个IP端口呢？接下来，就来说说Ribbon

使用过的同学应该知道，Ribbon是一个基于 HTTP 和 TCP 客户端的负载均衡器。Ribbon其实主要是在Spring原有的restTemplate类上做了负载均衡处理。其原理图如下：

运行原理：

Ribbon是结合Eureka，Feign，先会从 Eureka Client里获取到对应的服务注册表，也就知道了所有的服务都部署在了哪些机器上，在监听哪些端口号。
然后Ribbon就可以使用默认的Round Robin算法，从中选择一台机器
Feign就会针对这台机器，构造并发起请求。

2.4 Hystrix

Hystrix是一个熔断器组件。何为熔断器？其实就类似于我们生活中的保险丝。当我们的服务请求链路中，如果某一个环节点出了问题，那么这个时候Hystrix就可以将其熔断，做降级处理等后续操作，保护整个链路的正常进行。不会因为某一个点出现了问题，而导致整条链路失败或是在某个环节卡死。这也就解决了我们平时所说的服务雪崩问题。其原理图如下：

运行原理：

Hystrix在服务运行请求时，会为每个服务创建一个线程池。请求进入后，会由线程池去管理。当线程池满了时，会对后来的请求会立即拒绝请求，而不是排队。当请求失败、被拒绝、超时或短路时，执行回退逻辑。并且，如果这种非正常返回的请求量，服务的错误百分比超过了一个阈值，就会触发一个断路器来停止对特定服务的所有请求，无论是手动的还是自动的。这些处理情况，Hystrix会实时监控指标和配置变化，并可通过HystrixDashboard可视化界面查看具体情况。

2.5 Zuul

Zuul，也就是微服务网关。这个组件是负责网络路由的。网络路由可能有些人不懂什么意思？试想，倘若我们的系统中，有几百乃至上千个微服务，当后台与前端Android，IOS,H5等等这些对接时，如果前端需要对我们这些服务一一对应区分处理，那将是很不合理的情况，也不利于维护。所以，如果有了Zuul，那前端就不必关注我们的服务接口来自哪个服务，只需要请求到网关，可以全部交由网关这边处理，然后由网关层路由分发请求到对应的服务上。

运行原理图如下：