Spring Cloud
最近终于终于啃完翟永超的《Spring Cloud微服务实战》。看完之后，对于这些牛逼的东西，我只能说我终于知道Spring Cloud是想干嘛了（叹气。jpg）。对此总结一下。
实施Spring Cloud，即想通过把原本单独的大系统，拆分为多个的微服务，以达到系统解耦的目的。但为了依旧提供完整的服务，各个微服务仍然存在着业务依赖。而这些业务依赖则通过rpc等方式进行调用。因此微服务里存在着两个根本角色：服务提供者和服务消费者。当然，对于某一个微服务而言，他自己可以既是服务提供者也是服务消费者，因为他即为其他微服务提供服务，也使用其他微服务的服务。然而这么做问题会出现一大堆，Spring Cloud就是为了解决这些问题而开发或者封装其他工具诞生的。这里先罗列几个这些问题：
- 作为服务消费者，怎么知道服务提供者在哪
- 作为服务消费者，怎样调用服务提供者的服务
- 作为服务消费者，万一服务提供者挂了该怎么办。不可能晾着其他请求一直等这位服务提供者恢复吧！？
- 拆分后，微服务数量众多，又各自为政。接口自行变更，管理混乱，怎么办？
- 拆分后，微服务数量众多，又各自为政。微服务之间怎样互通消息？
- 拆分后，微服务数量众多，又各自为政。如果要修改配置，岂不是要一改就要改好几十甚至上百台机？
注册中心：知道服务提供者在哪
每一个微服务提供一种服务，为了知道我需要的微服务往哪里调用，Spring
Cloud引入了一个注册中心，让各个微服务把自己提供的服务名称在注册中心里登记。这样子，服务消费者只需要往注册中心里查询所需要的服务名称，注册中心就会返回提供写个服务的微服务的网络地址。其中Netflix爸爸的Eureka实现了注册中心的功能，Spring
Cloud对Eureka进行了封装，成为了Spring Cloud
Eureka组件。为了注册中心自身的高可用，注册中心往往也会启动几个，注册中心可以把自己组成到注册中心里，这样其他注册中心就会直到自己也是注册中心了。
客户端均衡负载与声明式服务调用：调用服务提供者的服务
服务消费者调用服务的基础版本是通过Spring
Cloud封装好的RestTempla对象。除了入参以外，指定服务的url的主机地址被替换为服务名，即http://服务名/path，来与具体的服务提供者解耦，具体有那些服务提供者需要到注册中心查询。提供同样服务的服务提供者有多个，需要在这些服务提供者之间均衡负载。又是Netflix爸爸的Ribbon实现了服务消费者调用和均衡负载的功能。我们能直接使用Spring
Cloud封装好的Ribbon，但是太麻烦了。所以不知道谁开源出来的Feign，又在Ribbon的基础上进行了封装，使得我们只需要声明一个接口，写好接口里的方法，与服务提供者提供的服务对应。Feign就会帮我们实现这个接口，就能注入调用。就像mybatis一样。
熔断器：解决服务提供者挂了
拆分为微服务后，可能会出现B依赖于A，C依赖于A，D依赖于A等等。一旦A挂了，如果BCD都无休止等待A的响应，那可以说整个系统都蹦了。但是如果只是简单报个错，又会影响用户体验。所以熔断器会监控统计服务提供者的监控情况，并设定服务调用的超时时间。一旦服务调用超时，熔断器允许我们指定一个备用的方法以调用，起码有点东西返回，说句我报错了也好。这种调用备用方法的叫做服务降级。又是Netflix爸爸的Hystrix实现了熔断器的功能，经过Spring
Cloud封装为Spring Cloud
Hystrix组件。在Hystrix的实现中，Hystrix会为每个服务配一个线程池来调用服务。这是为了其中一个服务炸了，不会阻塞掉全部的线程而影响到其他正常服务的调用。
API网关：统一管理接口
API网关除了重新配置接口实现路由以外，还会进行均衡负载。一般调用服务需要一定的权限，但是如果每个微服务都进行权限校验就混乱复杂了。所以API网关需要做权限校验的功能。所以感觉API网关有点像一个增强版的Nginx，能够让运维跟简单维护数量众多的微服务之间的路由与权限。没错，又是Netflix爸爸的Zuul实现了API网关。
消息总线：微服务之间互通消息
微服务独立开发，独立部署，所以互通消息就比较麻烦。目前我消息总线还不是很理解，感觉跟之后说的消息驱动或者zookeeper有点模糊。但跟在面的配置中心结合使用有点像对全部或者指定的微服务进行广播消息的功能。而有两个软件（需要独立安装或者启动）：RabbitMQ和Apache的Kafka都实现了消息总线的功能，并被Spring
Cloud封装的好好的。
配置中心：统一管理配置
如上问题所说，为了解决几十上百台机的配置，其实最好就是设定一个配置中心，把配置都放在配置中心统一管理。微服务启动的时候，往配置中心自己拿配置。并且结合git或者SVN，云一份，配置中心本地一份，哪怕云挂了也有本地的旧配置可以返回。配置中心好像是Spring Cloud自己实现的Spring Cloud Config组件。这里还有个问题，例如git上配置文件改了，但是这么多微服务并不知道配置更新了。所以可以结合消息总线。大约的逻辑是：先更新了git的配置，通过配置中心暴露的接口通知配置中心git上的配置更新了，然后配置中心会让消息总线通知相应的微服务来拿最新的配置，消息总线通知了相应的微服务，微服务各自到配置总线那最新的配置，全部微服务的配置更新完毕。
其他
消息驱动（理解是微服务之间的生产消费异步队列），好像是Spring Cloud自己实现的Spring Cloud Stream组件。
服务跟踪（用于跟踪记录统计各个微服务之间调用的时间之类的），好像是Spring Cloud自己实现的Spring Cloud Sleuth组件，貌似还能跟其他一些不知道什么鬼的软件配合使用。
参考文章：
Spring Cloud微服务实战（翟永超）