cloud的服务的最开始都是基于Eureka的注册中心的
生产者：
1.Eureka server
就是注册中心，服务的提供端，所有的消费者都是在这里拿服务，可以根据名称和端口名字在网页上面可视化。
2. Eureka client
是具体服务的提供者，创建一个服务提供者，具体配置在yml文件里面，例如名称 端口号以及服务名称
以上的两者都是服务的提供方，又client提供服务然后由server（注册中心）发布出去。
消费者：
1.ribbon：
Spring cloud有两种服务调用方式，一种是ribbon+restTemplate，另一种是feign。在这一篇文章首先讲解下基于ribbon+rest，在通过url进行服务调用的时候因为会进行负载均衡，例如在不同端口的client进行生产的时候，即使名称是一样的，ribbon会根据url再对服务调用，因为名称一样所用呈现的内容会交替。
2.feign：
Feign是一个声明式的伪Http客户端，它使得写Http客户端变得更简单。使用Feign，只需要创建一个接口并注解。它具有可插拔的注解特性，可使用Feign 注解和JAX-RS注解。Feign支持可插拔的编码器和解码器。Feign默认集成了Ribbon，并和Eureka结合，默认实现了负载均衡的效果。
路由网关：
zuul：
zuul的作用主要是进行路由以及过滤，通过自身yml文件的编写，然后将ribbon和feign暴露的接口重新进行路由，然后在进行url的重新设置。
zuul不仅可以路由还可以进行一些安全的验证，在使用的时候要继承ZuulFilter类然后对以下方法进行调用，实现过滤的效果。
filterType：返回一个字符串代表过滤器的类型，在zuul中定义了四种不同生命周期的过滤器类型，具体如下：
pre：路由之前
routing：路由之时
post： 路由之后
error：发送错误调用
filterOrder：过滤的顺序
shouldFilter：这里可以写逻辑判断，是否要过滤，本文true,永远过滤。
run：过滤器的具体逻辑。可用很复杂，包括查sql，nosql去判断该请求到底有没有权限访问。
断路器（Hystrix）
在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以相互调用（RPC），在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。
为了解决这个问题，业界提出了断路器模型。
较底层的服务如果出现故障，会导致连锁故障。当对特定的服务的调用的不可用达到一个阀值（Hystric 是5秒20次） 断路器将会被打开。
然后如果一个service的内容没有呈现就会返回一个固定值，从而避免上述的雪崩效应。
分布式配置中心
在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在Spring Cloud中，有分布式配置中心组件spring cloud config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。在spring cloud config 组件中，分两个角色，一是config server，二是config client
config server：
是在分布式中对于注册中心进行，进行统一配置的
在boot的启动类上面加上@EnableConfigServer注解开启配置服务器的功能，
在其pom.xml文件加上EurekaClient的起步依赖spring-cloud-starter-eureka，可以进行多台的，高可用的分布式配置中心
config client：
可以进行yml文件的书写然后读取server里面的配置信息。
Spring Cloud Bus（消息总线）
Spring Cloud Bus 将分布式的节点用轻量的消息代理连接起来。它可以用于广播配置文件的更改或者服务之间的通讯，也可以用于监控。本文要讲述的是用Spring Cloud Bus实现通知微服务架构的配置文件的更改。就例如刚刚上面面的分布式配置中心 将config server里面的属性进行修改之后，就可以通过这个bus来进行通知，可以通过rabbitMq来进行消息的传输
Spring Cloud Sleuth（链路追踪）
Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 zipkin，你只需要在pom文件中引入相应的依赖即可。
高可用的服务注册中心
在大量的服务面前一个注册中心有的时候负荷不了，所以需要将Eureka的集群化，需要对注册中心里面的yml文件进行修改，然后向一个注册中心注册的服务就可以在别的注册中心上面也可以看见，降低了这个注册中心的负载度