SpringCloud是在SpringBoot的基础上构建的，用于快速构建分布式系统的通用模式的工具集。

SpringCloud原始组件

在SpringCloud初生到现在，经历了实际项目中的应用变革，有的组术已经被改革换代，但他们的原理大致相同。所以原始组件还是具有一定的参考性质。

微服务的注册与发现

· 各微服务在启动时，将自己的网络地址等信息注册到服务发现组件中，服务发现组件会存储这些信息。
· 服务消费者可从服务发现组件中查询到对应微服务提供者的网络地址，并使用该地址调用服务提供者的接口。
· 各个微服务与服务发现组件使用一定的机制进行通信。服务发现组件如长时间无法与某微服务进行实例通信，就会注销该实例。
· 微服务网络地址发生变更的时候，会自动重新注册到服务发现组件中。当我们的网络地址发生改变的时候，就无需自主去修改了。

综上，服务注册与发现的组件就应具备服务注册表、服务注册与服务发现、服务检查的功能。

SpringCloud提供了多种服务发现组件的支持，例如Eureka、Zoomkeeper、Consul、Nacos等等。但是随着业务场景的不断冲刷，Eureka的弊端类似于服务注册慢、已停止的微服务节点注销慢或者不注销、所注册的服务状态为UNKNOW而我们只会请求状态为UP的微服务等等的问题，使得Eureka在实际应用中逐渐退出舞台。

负载均衡

在我们启动微服务时，Eureka Client会把自己的网络信息注册到Eureka Server上，一般来说，在生产环境中，各个微服务都会部署多个实例，那么服务消费者要如何将请求分摊到多个服务提供者实例上呢？

我们来介绍一下Ribbon是如何实现客户点侧的负载均衡的。Ribbon是Netflix发布的负载均衡器，有助于控制Http和Tcp客户端的行为。为Ribbon配置服务提供者地址列表后，Ribbon就可以基于负载均衡的算法，自动地帮助服务消费者去请求。除了我们自定义地负载均衡算法，其提供了轮询，随机等。

在SpringCloud中，Ribbon可自动从Eureka Server中获取服务提供者地地址列表，然后根据负载均衡地算法，请求其中地一个服务提供者的实例。

声明式REST调用

举个例子，在我们调用某个接口时，需要传入参数，当我们仅有一个访问参数的时候还好说，加在请求后面就好了，那么如果当我们有多个请求参数的时候呢？十个甚至二十个，也手动去添加到请求的后面吗？显然这样会增加我们的编写成本，如下。

return this.restTemplate.getForObject("http://localhost:8080/user/showAllUserMessage?idNumber="+idNumber+"&userName="+userName+"&password="+password+"&...等等等一系列参数",User.class);

那么Fiegin就很好地帮我们解决了这个问题，他是Netflix开发地声明式、模板化的Http客户端，可以帮助我们更加便捷地、优雅地、规范地调用HTTP API。除了能够使用其自带的注解外，SpringCloud还使Feign可以支持SpringMVC注解。

但是随着真是业务场景的冲刷，Feign也逐渐不行了，后来选择OpenFeign对相应的接口进行调用。

其实这就好比于，我们在进行项目开发的时候，需要调用别人项目中的接口，那怎么让自己项目的接口被其他项目请求到呢？简单来说这个接口被注册到一个服务器上，然后你使用相应的接口文档按照提供的接口调用方式对其调用即可。

微服务的容错处理

在SpringCloud的原始组件中，上面我们提到Eureka实现了微服务的注册与发现，Ribbon实现了负载均衡，Feign实现了声明式的API调用，那么接下来我们要讲的就是Hystrix是实现微服务的容错处理的。

微服务架构的应用系统通常包含多个服务层，微服务之间通过网络进行通信，从而支撑起整个应用系统，因此，微服务之间难免存在一个依赖的关系。

既然各个微服务之间存在依赖，那么我们就要考虑从到一个问题，当某种业务场景的请求方式为A请求B，B请求C从而返回最终结果，如果C此时此刻不可用，那么导致B不可用，进而导致A的不可用。我们把这种现象称为雪崩。官方话语：“基础服务故障”导致“级联故障”。就是一个提供者不可用从而导致了消费者不可用，并且逐渐讲影响扩大的过程。

那我们如何进行容错呢?
· 为网络请求设置超时：在正常情况下，一个请求大概在技术毫秒内就能得到响应结果，如果说依赖的服务不可用或者网络有问题，那么响应的时间就会大大延长。如果涉及到并发数据变更问题，通常一个请求对应者一个线程/进程，或者是一个锁，如果响应太慢，这个请求就得不到释放，此时此刻如果进来更多的请求，资源就会被消耗殆尽，最终导致服务不可用甚至宕机。
· 使用断路器模式：简单来讲就是，如果请求某个微服务由大量的超时，那么此时此刻再去发送请求已经没有什么意义，只会无谓地消耗资源。那么路器地作用是什么呢？就是去检测某一段时间里，是否有一定量的调用失败次数，如果有那么我们就禁止访问再进来了，此时断路器就打开，再将等待的请求通过一个，判断其是否能够请求成功，如果可以，断路器关闭，微服务的调度恢复正常使用，如果不可以，断路器继续执行。

Hystrix就是一个实现了超时机制和断路器模式的工具类库。实现了包裹请求、跳闸机制、资源隔离、监控、回退机制、自我修复功能。回退机制可由开发人员自行定义。

微服务网关

我们假设，用户在发送请求进入业务场景的时候，直接访问各个不同的微服务吗？

如图所示，如果说用户直接请求各个微服务会有什么影响？它不仅仅会增加客户端的复杂性，在处理跨域请求的时候也增加了其复杂性，而且用户请求的时候用户认证也复杂，难不成在每个微服务中都进行一次用户认知？答案是很明显的。

如上图，如果让用户通过网关进行请求，有什么好处呢？
· 易于监控。可直接在微服务网关收集监控数据。
· 易于认证。直接在网关进行认证，然后再将请求转发到各个微服务。
…

简述一下最初的微服务网关Zuul，它的核心是一系列的过滤器。主要实现功能有以下几点，其实通过上图就能对应到以下这几点功能：
①身份认证与安全
②审查与监控
③动态路由
④压力测试
⑤负载分配
⑥静态响应处理
⑦多区域弹性

同样地，Zuul网关在经过迭代后，原有功能已经不足以支撑更多地业务场景，本来要发布地Zuul2也不了了之，后来Gateway的出现代替了Zuul。