SpringCloud就是一个分布式架构的一站式解决方案，它提供了一些组件用来解决分布式微服务架构带来的一些问题，我之前在工作中用到过，Eureka，Ribbon，Feign，Hystrix，Zuul，这些组件，其中Eureka就类似是一个服务注册中心，里面包含了EurekaServer服务端，和EurekaClient客户端，每个微服务当中都有一个客户端来告诉服务端自己所在的机器和端口号，然后在进行服务调用的时候消费者就可以在服务端的注册中心中获取到服务提供者的注册信息之后就可以进行调用了，然后就是Ribbon 它主要为我们提供了一些负载均衡的策略比如轮循啊 随机，轮循权重啊 等等这些，而Feign主要为我们做的就是方便我们远程调用接口了，它可以使得我们调用远程接口就像调用本地方法一样简单，之后就是Hystrix 它主要是负责我们服务调用失败后的熔断 包括降级和资源隔离，而Zuul呢 就类似与一个服务网关，他可以统一我们的网络请求，因为所有需要访问的微服务都要经过zuul服务网关，我们也可以在zuul中设置过滤器，也可以统一解决跨域问题，这就是spring cloud的作用以及组件，接下来和大家详细的说一下每个组件的具体操作和功能。
1.0 Eureka：
1.1 Eureka简介：
Eureka就是一个服务注册中心，里面有EurekaServer服务端和EurekaClient客户端，然后每个微服务中都会有一个EurekaClient客户端来将自己所在的机器端口号一级信息发送给EurekaServer，说白了就是告诉EurekaServer自己在那台机器上监听这那个端口，而EurekaServer是一个注册中心里面有一张注册表，注册表中有所有的机器信息已经对应的端口号，当服务消费者需要调用某个接口的时候只需要吧要调用的服务的端口号Ip地址这些相关信息从注册表中拉取到自己的本地然后缓存起来，紧接着就可以发送一个请求过去调用相关服务的那个接口了。
1.2 Eureka的心跳机制：
Eureka中有一个心跳机制，就是说EurekaClient会每隔三十秒像EurekaServer发送一个自己还存在的心跳，这个心跳的作用就是告诉服务端自己还存活的意思，而EurekaServer如果九十秒内仍然为接收到目标客户端发送的心跳的话就会认为它已经挂掉了 就会将其注销，但是这里的注销不是马上注销，而是在六十秒以后对这个时间段所挂掉的客户端一起注销，如果立即注销的话可能会有很大的影响，我以上所说的都可以自己手动进行配置
1.2 Eureka中的自我保护机制：
自我保护机制就是EurekaServer在15分钟内一直都是有百分之八十五的节点都没有正常的心跳，那么EurekaServer就会认为是自己出现了网络故障 就会进入自我保护机制，进入自我保护机制后，就不会再去接收任何一个节点的心跳了，也不会再去注销任何节点了，等到恢复正常后，再开始进行正常操作，这就是EurekaServer的自我保护机制
1.3 具体怎么使用Eureka搭建注册中心以及怎么把服务注册到服务中心：
首先第一步就是导入EurekaServer的依赖，然后再配置文件中配置Eureka的注册中心端口号，最后在启动类上添加@EnableEurekaServer这个注解，之后在每一个微服务的pom文件中加上EurekaClient的依赖，配置文件中配置自己要注册到的服务端端口，在启动类上添加@EnableeurekaClient这个注解就注册成功了。
1.4 为什么要使用注册中心：
如果没有注册中心，消费者通过ip地址访问服务提供者，如果服务越来越多，调用起来也会变得越来越复杂，一旦服务提供者的ip地址发生改变那么所有访问的地址都要发生改变，维护起来会比较麻烦，而且如果提供者宕机了，所有访问的消费者也会收到影响，通过注册中心可以让服务提供者将自己的信息出则的注册中心去，这样消费者在进行调用的时候就可以通过注册中心来获取地址列表，从列表中选择一个去进行访问，后期维护也会简单点。
2.0 Feign的介绍：
Feign就是一个可以帮助我们更快调用远程接口的工具，说白了如果不用Feign也可以进行远程接口调用，我们可以使用httpclient来自己构造请求然后发送请求和解析响应结果这些操作，但是这样做太麻烦了，使用了feign之后我们调用远程接口就像调用本地方法一样简单了，构造请求发送请求和解析响应结果这种脏活累活feign已经全部都帮我们做了，我们只需要专注于核心业务逻辑就可以了。
2.1 Feign的工作原理：
首先在微服务启动的时候如果启动类上添加了@EnableFeignClients这个注解那么就会去扫描添加了@Feignclient注解的接口，并按照注解的规则去创建接口的代理对象注册到ioc容器中，当借口中的方法被调用时，会根据你在接口中的@Requestmapping 和@PathVariable去动态的构造出你要请求的服务地址，然后针对这个服务地址去进行构造请求 发送请求 解析相应结果。
3.0 Ribbon的介绍：
Ribbon就是一个负责客户端负责均衡的工具，当然了之前我并没有单独使用过ribbon因为我们使用的feign已经内置了负载均衡策略，Ribbon提供了很多负载均衡策略，比如随机，轮循，轮循权重，根据响应时间加权，等等......，如果Ribbon提供的这些负载均衡策略无法满足你的需要的话你也可以自定义负载均衡策略，我们只需要新建一个类去继承ribbon提供的一个什么叫做abstacit ，rule什么的，然后重写抽象方法，在里面实现你的负载均衡策略就可以了
3.1 客户端负载均衡和服务端负载均衡的区别：
客户端负载均衡就是自己来选择，服务端负载均衡就是服务来制定策略，举个现实生活中的例子，比如我们去肯德基点餐，有三个点餐窗口并都有人排队，这个时候如果是我们自己选择排队窗口就是客户端负载均衡，如果是服务员让我们去指定的窗口排队的话就是服务端负载均衡。
4.0 Hystrix的总结：
4.1：什么是服务雪崩：
服务雪崩就是指在你进行服务调用时，A服务要调用B服务，而B服务要调用C服务，这个时候C服务出现了一些问题，那么B服务就也会出现问题，从而A服务就无法调用成功，就好比一个十字路口因为红绿灯问题出现了堵塞，可能会导致后面的所有路口造成大量拥堵，这就是服务雪崩，我们可以利用springcloud中的Hystrix来解决这个问题。‘
4.2：Hystrix是什么：
Hystrix是为我们提供了 熔断，降级以及资源隔离的一个工具组件
4.3：Hystrix怎么做的熔断：
熔断就是说在进行调用某个目标服务的时候，因为其他原因导致无法调用，那么就会进行熔断，不再进行这个调用，直接返回快速释放资源，具体是这样实现的，默认是在十秒钟在二十个请求中有百分之五十的请求无法调用那么Hystrix熔断机制就会从闭合状态更改为打开状态，之后就不会再去调用当前目标方法而是直接返回，然后五秒后熔断机制会变为半打开状态发送一个请求去调用目标方法如果访问通的话就关闭熔断机制，如果仍然存在问题就继续打开熔断机制，然后五秒后再变为半打开状态，这就是Hystrix的熔断机制。
4.4：Hystrix降级：
降级其实就是目标方法调用不通时要走的备用方法，也是为了springcloud的高可用。
4.4：Hystrix的隔离机制：
Hystrix有两种资源隔离方式，一种是线程池隔离一种是信号量隔离，我们默认使用的是线程池隔离，线程池隔离就是你每调用一个服务就会创建一个线程池，如果你使用的是会员微服务那就有会员的线程池，如果调用积分微服务就会创建积分线程池，线程之间相互不干扰，这样就可以将每个微服务隔离开来了，就算你调用的那个服务代码存在bug或者线程池因为某些原因被耗尽也不会对其他服务造成影响，这就是Hystrix的隔离机制。
4.5：feign如何和Hystrix联合使用
我们的项目中是用feign进行远程服务调用的，又因为feign中集成了Hystrix所以可以配合使用，比如我们在项目中的熔断后的降级策略，可以利用Feign中的Feignclient的fullback属性来指定降级时要走的类，这样在目标服务调用失败后就可以走Fallback中的降级类执行方法了，在这个方法中我们可以进行错误信息的日志记录返回null，然后根据判断是否为空来确定这个方法是否走了降级策略然后在进行特殊处理
5.0：Zuul的总结：
5.1：Zuul的简介：
Zuul在我们的架构中充当着注册中心角色，属于一个客户端和服务端的中间层，我们调用接口的所有请求都要先经过Zuul的服务网关，所以我们为了保证每一个微服务的安全可以自定义一个全局过滤器来保证微服务的安全，而且因为是前后端分离，所以前段访问后端可能会出现跨域问题，我们也可以设计一个跨域过滤器来解决。
一会儿在更新。。。。。