更新时间：2019年7月19日
前言
springCloud系列文章：
springCloud的了解（一）：juejin.cn/post/684490…
springCloud的了解（二）：juejin.cn/post/684490…
昨天我们学习了springCloud的四个组件，Netflix Eureka——服务发现，Netflix Ribbon——客服端负载均衡，Netflix Zuul——服务网关，Netflix Hystrix——断路器。
从学习这四个组件中，我们可以观察到，实际上springCloud并没有大包大揽的将所有的活都自己来干，它只是把市面上的一些成熟的东西拿过来，然后补上一些没有的但又是确确实实需要的组件，从而组成了一个大的而且能满足市面上所有人的需求的容器。
springCloud想做的就是提供一个完美的分布式解决方案，而不是我们所说的是一个框架，某种程度上来讲，它甚至不是一个容器，它只是一个思路。
从用户提交一个请求，到zuul网关进行权限控制，然后zuul网关从Eureka上获取可以使用的微服务，通过Ribbon来进行负载均衡，分发到具体的后端服务上面，进行业务处理。如果一个微服务需要调用另外一个微服务上面的接口，那么可以通过Feign来进行调用。如果一个微服务在被调用的时候，出现了错误，那么我们通过Hystrix来进行熔断，避免出现整体的雪崩效应。
大体的springCloud的运作过程就是这样，当然，还有Turbine监控服务间的调用和焠断相关指标，一起进行分布式配置的Config。还有很多其他的组件组合到一起，这就形成了一个庞大的分布式解决方案。
springCloud决不是一个框架，也不仅仅是一个容器，而是一个越来越趋向于完美的分布式解决方案。
今天，我们将继续深入的学习springCloud的其他组件。
ps：在party开始之前，我又不得不向大家推荐一首我贼喜欢的歌曲，《火车行驶于云外，梦安魂于九霄》，是刺猬乐队的歌曲，特别喜欢其中的一句歌词“一代人终将老去，但总有人正年轻！”，建议大家去听一听，毕竟刺猬乐队的主唱是程序员里面最会唱歌的啊！(^▽^)
springCloud的其他组件
昨天在学习了springCloud的四大组件：
Netflix Eureka——服务发现
Netflix Ribbon——客服端负载均衡
Netflix Zuul——服务网关
Netflix Hystrix——断路器
在前言中，我已经大概回顾了一下这四大组件的作用，以及在springCloud中运作流程。如果对具体的博文感兴趣的话，可以通过我给的链接来看我之前的博文。
但是除了这四个组件，springCloud还有着许许多多的组件，这剩下的组件中，有spring自己的，也有市面上其他厂商的。
1. Spring Cloud Config--分布式配置中心
首先，我们要理解的一点是，为什么springCloud需要一个分布式配置中心呢？因为springCloud是为分布式微服务服务的，那么，因为每一个微服务都需要进行配置，那么对于开发人员来说，这样的维护成本是非常高的。
而且涉及到的安全问题是，如果每一个微服务都需要开发人员配置的话，那么也就是说每一个开发人员都有修改配置的权利，那么对于一个成熟的开发团队来说，这一点是非常不对的，对于整个程序来说，几乎是已经算不上安全了。
而且每一个微服务在修改配置后，基本都需要重启程序，这是一个十分庞大且费时的开销。尤其是对于一个已经上线的项目来说，完全是不能接受的。
为了解决这些问题，springCloud推出了springCloud config这个组件。
config支持配置文件放在在配置服务的内存中，也支持放在远程Git仓库里。因此，一般的开发团队都是在引入config之后，将所有的配置文件都放到git仓库中，可以创建一个config server，用来管理所有的配置文件，当需要修改配置的时候，直接在本地修改了，推送到git仓库中。
所有的服务实例都可以通过config server来获取配置文件，这时每个服务实例就相当于配置服务的客户端config client。
为了保证系统的稳定，配置服务端config server可以进行集群部署，即使某一个实例，因为出现错误了不能提供服务，也还有其他的实例保证服务的继续进行。
从网上找到一个图片，分享给大家：
2. Spring Cloud Turbin--集群监控
在之前的讲解之中，Hystrix本身是有监控功能，Hystrix DashBoard是具备监控单个微服务的功能的，我们可以在Eureka注册一个单个的微服务，用来监控所有的在Eureka上注册的微服务。在springCloud上面新建一个微服务用来监控非常简单，大家可以自行百度。
给大家看一张图，是Hystrix DashBoard的一张监控图：
Turbin是聚合服务器发送事件流数据的一个工具，用来监控集群Hystrix下的微服务的情况的，它有一个重要的功能就是汇聚监控信息，并将汇聚到的监控信息提供给Hystrix Dashboard来集中展示和监控。
也是说，Turbin的实际功能就是监控各个微服务中的数据，然后把这些数据整合，发送到Hystrix DashBoard中进行展示。
3. NetFlix Feign--声明式rest服务调用
当我们在开发的时候，很多时候都是通过对业务的切分从而将我们的程序切分成了多个微服务，但是在开发单个微服务的过程中，我们难免会碰到会需要调用其他微服务的数据的情况，在没有Feign的时候，我们选择使用RestTemplate来进行调用。
但是使用RestTemplate所需要的参数须在请求的URL中进行拼接，如果参数少的话或许我们还可以忍受，一旦有多个参数的话，这时拼接请求字符串就会效率低下。
于是springCloud在市场上给我们找到了一个工具：Feign。
Feign是一个声明式的web service客户端，它的目的就是让微服务的互相调用变得更加简单。Feign提供了Http调用的模板，且支持可插拔编码器和解码器，通过插入注解和编写简单的接口，定义好HTTP请求的参数、格式、地址等信息，就能直接调用其他微服务的接口。
在使用Feign调用其他微服务的接口的时候，我们就像简单的调用方法一样。
总结一下Feign的特性如下：
可插拔的注解支持，包括Feign注解和JAX-RS注解;
支持可插拔的HTTP编码器和解码器;
支持Hystrix和它的Fallback;
支持Ribbon的负载均衡;
支持HTTP请求和响应的压缩。
其实这些特性都不用说明，既然Feign是在SpringCloud中的，那么必然是配合其他组件的功能的，而且Feign又是NetFlix开发的，那针对NetFlix开发的其他组件，必然是配合度极高的。所有Feign有以上的这些特性，不足为怪。
既然是微服务之间的互相调用，那么我们也必须注意一些地方，Feign在使用的时候，是有超时时间的，但是Hystrix在熔断的时候，也是有超时时间的，那么在这种情况下，情况大概是这样的：
1.假如Feign的超时时间是3s，而Hystrix的超时时间是1s，那么当在调用Feign的时候，还没
等到Feign的超时时间到，就等到了Hystrix的超时时间到了，那么就会直接熔断，Feign的
超时时间也就失去了意义。
2.假如Feign的超时时间是2s，而Hystrix的超时时间是3s，当Feign调用其他微服务的接口的
时候出现了问题，超时了，那么Feign就会进行重试调用，会调用接口第二次，但是这个时
候Hystrix的超时时间到了，那么，这个Hystrix的熔断不会影响到Feign的第二次调用接口。
4. Spring Cloud Bus--消息总线
在之前我们对config的分析中，我们发现当我们更新了配置文件之后，然后将本地配置文件发送到了远程git仓库中，但是我们得通知每一个微服务，我们修改了配置文件，那么就得通过post请求来一个一个发，这是我们不能接受的。
因此就引入了SpringCloud Bus。
Bus就是典型的将消息队列的订阅发布模式引入到springCloud中去，让所有为服务来订阅这个事件，当这个事件发生改变了，就可以通知所有微服务去更新它们的内存中的配置信息。这时Bus消息总线就能解决，你只需要在springcloud Config Server端发出refresh，就可以触发所有微服务更新了。
又默默的从网络上搜到一张图来解释这个问题：
Bus不仅仅是可以应用到配置文件的修改，而且可以应用到很多地方，比如微服务之间的通讯。
小结
几天我们基本上将SpringCloud的大部分重要组件都粗略的了解了，但是在我们实际开发中，如果仅仅是这样粗略的了解这些组件，那么是远远不够的，我们还需要更加的去深入了解，最好我们能够自己动手搭建一个springCloud出来，这样才能更加深入的了解springCloud。
明天，我们开始学习springCloud相关的分布式事务问题。
ps:最后，作为一个《乐队的夏天》的忠实粉丝，我又给大家推荐一首贼适合在上班听的歌曲，旺福乐队的一首歌《两个恰恰好》，很俏皮的一首歌。(✪ω✪)
