SpringCloud五大核心组件
- 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 过滤器：在其他过滤器发生错误时执行
