Springcloud 主要组件

1. Eureka：注册中心
      Eureka就好比是一个公司的后台，负责管理、记录服务提供者的信息。我们只要将我们的微服务注册到Eureka中去，我们的服务调用者在调用微服务的时候，就无需自己寻找服务，而是把自己的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你，从而完成微服务的调用。
   Eureka架构中的三个核心角色：
   ①服务注册中心
   Eureka的服务端应用，提供服务注册和发现功能，就是刚刚我们建立的eureka-demo
   ②服务提供者
   提供服务的应用，可以是SpringBoot应用，也可以是其它任意技术实现，只要对外提供的是Rest风格服务即可。
   ③服务消费者
   消费应用从注册中心获取服务列表，从而得知每个服务方的信息，知道去哪里调用服务方。

2. Zuul：服务网关
       Zuul是Netfix开源的微服务网关，它可以和Eureka、Ribbon、Hystrix 等组件配合使用。Zuul的核心是一-系列的过滤器，这些过滤器可以完成以下功能。

   • 身份认证与安全:识别每个资源的验证要求，并拒绝那些与要求不符的请求。
   • 审查与监控:在边缘位置追踪有意义的数据和统计结果，从而带来精确的生产视图。
   • 动态路由:动态地将请求路由到不同的后端集群。
   • 压力测试:逐渐增加指向集群的流量，以了解性能。
   • 负载分配:为每一~种负载类型分配对应容量,并弃用超出限定值的请求。
   • 静态响应处理:在边缘位置直接建立部分响应，从而避免其转发到内部集群。
   • 多区域弹性:跨越AWS Region进行请求路由，旨在实现ELB ( Elastic Load Balancing )使用的多样化，以及让系统的边缘更贴近系统的使用者。
     具体的案例请看:关于微服务Zuul网关的详细案例讲解

3. Ribbon：负载均衡
       Ribbon是我们SpringCould采用的一种负载均衡器，它的主要作用在于，当我们同一个功能的微服务开启了很多个时，当我们需要调用微服务时所遵循的一种微服务调用的规则，这样我们才能准确的调用响应的微服务。所以，只要我们为Ribbon配置了提供服务者的同一类微服务的地址列表后，我们的Ribbon就可以基于某种负载均衡的算法自动的帮助服务事物消费者去请求服务。Ribbon默认的为我们提供了轮循，随机等负载均衡的算法，同时我们也可以自定义负载均衡的算法。

4. Feign：服务调用
   微服务架构中，微服务间调用的一个组件。

5. Hystix：熔断器
       熔断器Hystrix是容错管理工具，作用是通过隔离、控制服务从而对延迟和故障提供更强大的容错能力，避免整个系统被拖垮。复杂分布式架构通常都具有很多依赖，当一个应用高度耦合其他服务时非常危险且容易导致失败，这种失败很容易伤害服务的调用者，最后导致一一个接一个的连续错误，应用本身就处在被拖垮的风险中，最后失去控制，就像在一一个高流量的网站中，某个单一的后端一旦发生延迟，将会在数秒内导致所有应用资源被耗尽。如何处理这些问题是有关系统性能和效率的关键性问题。 当在系统高峰时期，大量对微服务的调用可能会堵塞远程服务器的线程池，如果这个线程池没有和主应用服务器的线程池隔离，就可能导致整个服务器挂机。 Hystrix使用自己的线程池，这样和主应用服务器线程池隔离，如果调用花费很长时间，会停止调用，不同的命令或命令组能够被配置使用它们各自的线程池，可以隔离不同的服务。
       Hystrix熔断器主要的作用就是当我们的服务繁忙时，如果服务出现异常，不是粗暴的直接报错，而是返回一个友好的提示，虽然拒绝了用户的访问，但是会返回一个结果。这就好比去买鱼，平常超市买鱼会额外赠送杀鱼的服务。等到逢年过节，超时繁忙时，可能就不提供杀鱼服务了，这就是服务的降级。系统特别繁忙时，一些次要服务暂时中断，优先保证主要服务的畅通，一切资源优先让给主要服务来使用，在双十一、618时，京东天猫都会采用这样的策略。
   具体的案例请看:Hystrix熔断器的使用
   熔断器具体说明

6. Config：配置中心

   • 提供服务端和客户端支持（Spring Cloud Config Server 和 Spring Cloud Config Client）
   • 集中式管理分布式环境下的应用部署
   • 属性值的加密和解密（对称加密和非对称加密）
   • 基于 Spring 环境，无缝与 Spring 应用集成
   • 可用于任何语言开发的程序
   • 默认实现基于 Git ，可以进行版本管理