系列文章目录

SpringCloud快速入门到精通各组件原理
专栏传送门

@TOC

前言

好啦，小伙伴们，至此我们的微服务SpringCloud生态中的开发环境已经学习完成啦！我们本栏目主要学习了SpringCloud分布式解决方案的开发使用，敬请期待下个栏目《微服务新王–SpringCloudAlibaba》。
我们总结下都学习了哪些东西吧！

首先，我们学习了SpringCloud的生态

SpringCloud微服务解决方案主要由服务注册中心、服务调用、服务降级、服务网关、服务总线等部分，微服务治理的目的是在于将复杂的单体系统拆分为高内聚的各个微系统，使用框架实现各服务间的发现及互相调用，从而实现更加灵活的使用及资源分配，保障系统的高可用性及易维护性。

然后，我们学习了各个SpringCloud组件的使用及原理

1. 微服务注册中心Eureka、Zookeeper、Consul

SpringCloud实战—第六篇：Eureka注册中心之服务注册
我们学习了三种注册中心在SpringCloud框架中的使用，并了解到其核心原理是服务提供者将服务名称、服务地址等信息注册到注册中心上，服务调用方去注册中心获取服务信息，然后通过HTTP接口进行服务的调用。

AP(Eureka)： AP架构当网络分区出现后，为了保证可用性，系统B可以返回旧值，保证系统的可用性。结论：违背了一致性C的要求，只满足可用性和分区容错，即AP（保障健康的服务，允许心跳停止的服务继续存在）。
CP(Zookeeper/Consul)： CP架构当网络分区出现后，为了保证一致性，就必须拒接请求，否则无法保证一致性结论：违背了可用性A的要求，只满足一致性和分区容错，即CP （保障服务一致，发现心跳停止的服务立即干掉）。

2. 负载均衡器Ribbon

SpringCloud实战–第十二篇：Ribbon从入门到手写负载均衡器

• Nginx负载均衡是集中式的负载均衡（在Nginx服务器上实现负载均衡），Ribbon负载均衡是客户端的负载均衡（服务调用方实现的负载均衡）。
• Ribbon提供了很多负载均衡策略，如轮询、随机、根据响应时间加权等等。
• 给RestTemplate加上@LoadBalanced注解表示开启Ribbon负载均衡。
• 负载均衡的本质是Ribbon从注册中心拿到所有的服务实例，通过对请求进行计算得出要调用哪个实例，然后再进行调用。
• 手写一个负载均衡器可以让你更好的了解Ribbon的原理。
• 学完本篇，你会觉得Ribbon灰常简单（但是！！！骚年，这只是表相，当你知道的越多你就会越明白自己的无知~~）

3. 服务调用OpenFeign

SpringCloud实战—第十三篇：OpenFeign快速上手

OpenFeign在Ribbon的基础上封装了一个框架，目的类似于Mybatis的注解变成，意在让我们使用简洁明了、易读的方式来实现微服务间的调用。

• OpenFeign使用接口+注解的方式来调用远程服务（类似于一种映射配置）
• 在启动类上使用@EnableFeignClients声明OpenFeign客户端。
• 在接口上使用@FeignClient(value = “CLOUD-PAYMENT-SERVICE”)注解来声明是远程调用，其中value跟的是服务名。
• 在接口中编写与对应的远程服务Controller对应的RequestMapping接口相同的参数和回调，然后声明接口地址即可完成映射。
• OpenFeign天然支持了Ribbon负载均衡。
• 配置Ribbon超时时间可以解决客户端和服务端超时时间不一致问题。
• Feign可以灵活的开启日志配置，配合我们开发和线上进行调试。

4. 服务熔断豪猪哥–Hystrix

SpringCloud实战—第十四篇-Ⅰ：Hystrix概念及快速上手
SpringCloud实战—第十四篇-Ⅱ：Hystrix熔断及服务监控

为了防止单点服务出现故障，大量的请求仍然打到这个接口上导致系统线程占用过高，从而系统雪崩整个瘫痪，Hystrix就是一个断路器，当发现某个接口失败的概率很高达到一定的比例后就将该接口进行断了，无论其他接口如何访问都直接返回一个异常的提示信息，然后他还提供了自恢复的机制，过段时间调用失败率降下去之后再重新恢复接口的调用。

• hystrix通过服务降级来实现的解决异常传递问题。
• 服务降级可以这么理解，类似于淘宝，淘宝的支付宝功能出现了问题，支付功能不能用了，如果我们没有错误降级，在淘宝上调用支付时每次都会报出异常，然后大量的用户使用淘宝调用支付，就会导致资源占用，淘宝直接崩溃，使用了降级后，我们再调用时就直接返回一个有好的提示（系统繁忙，请稍后重试），至少能够保障系统的正常运行。
• hystrix的服务降级可以使用再服务调用方和服务提供方，通常服务调用方需要做降级处理。
• hystrix的降级是有一个回调方法，当出现异常时调用配置的回调方法返回预先设置好的符合接口格式的信息，防止异常传递。
• @EnableCircuitBreaker加在主启动类上，用于开启回注
• 调用方启用hystrix需要在配置文件开启，在主启动类上添加@EnableHystrix启用
• @HystrixCommand注解加在方法上，配置的是降级时调用哪个方法及降级触发的条件

5. 服务网关GateWay

SpringCloud实战—第十五篇：微服务网关GateWay

zuul是最早的网关组件，但是由于核心人员的离开及更新不及时，导致zuul2胎死，SpringCloud自己研发了一个GateWay网关组件来替换zuul，因此我们不再学习zuul，学习最新的GateWay。

• GateWay的目标是提供统一的路由方式，且基于Filter链的方式提供了网关的基本功能，例如：安全、监控/指标、限流。
• GateWay是SpringCloud自研的用于替代Zuul1.0的网关。
• GateWay基于WebFlux框架实现，而WebFlux框架的底层使用的是高性能的Reactor模式的通信框架Netty。
  优点
• 基于SpringBoot2.0构建，天然与SpringCloud整合。
• 动态路由：能够匹配任何请求属性。
• 可以对路由指定Predicate（路由）和Filter（过滤器）。
• 集成Hystrix断路器功能。
• 集成SpringCloud服务发现功能。
• 请求限流功能。
• 支持路径重写。
• 易于编写的Predicate和Filter。
• GateWay官网https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.2.1.RELEASE/reference/html/。

6. 服务配置中心Config

SpringCloud实战—第十六篇：微服务配置中心Config

• 随着微服务模块的增多，我们的配置文件需要被管理，否则多个分布式模块配置修改和管理起来很不方便，所以需要配置中心来统一管理配置。
• 微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行，所以一套集中式的、动态的配置管理设施是必不可少的。SpringCloud提供了ConfigServer来解决这个问题，- 我们每一个微服务自己带着一个application.yml，上百个配置文件的管理…/(ㄒoㄒ)/~~
• 是什么 SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。
• 动态的配置切换，开发环境、测试环境、生产环境…
• 公共的配置如数据库连接等等可以统一的放在配置中心，私用的再放在自己的模块（高内聚）
• 集中管理配置文件
• 不同环境不同配置，动态化的配置更新，分环境部署比如dev/test/prod/beta/release
• 运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息
• 当配置发生变动时，服务不需要重启即可感知到配置的变化并应用新的配置
• 将配置信息以REST接口的形式暴露
• 与GitHub整合配置：由于SpringCloud Config默认使用Git来存储配置文件(也有其它方式,比如支持SVN和本地文件)，但最推荐的还是Git，而且使用的是http/https访问的形式
• 官网：https://cloud.spring.io/spring-cloud-static/spring-cloud-config/2.2.1.RELEASE/reference/html/

7. 服务消息总线SpringCloudBus

SpringCloud实战—第十七篇：消息总线SpringCloudBus

• 分布式自动刷新配置功能，通常和Config分布式配置中心一起使用，他的原理是通过RabitMQ或Kafka消息队列，git上的配置修改时发布消息通知，然后配置中心调用我们上篇手动访问的接口来实现自动刷线配置。
• Spring Cloud Bus 配合 Spring Cloud Config 使用可以实现配置的动态刷新。Spring Cloud Bus是用来将分布式系统的节点与轻量级消息系统链接起来的框架，它整合了Java的事件处理机制和消息中间件的功能。Spring Clud Bus目前支持RabbitMQ和Kafka。
• Bus支持两种消息代理：RabbitMQ 和 Kafka
• Spring Cloud Bus能管理和传播分布式系统间的消息，就像一个分布式执行器，可用于广播状态更改、事件推送等，也可以当作微服务间的通信通道。
• 总线在微服务架构的系统中，通常会使用轻量级的消息代理来构建一个共用的消息主题，并让系统中所有微服务实例都连接上来。由于该主题中产生的消息会被所有实例监听和消费，所以称它为消息总线。在总线上的各个实例，都可以方便地广播一些需要让其他连接在该主题上的实例都知道的消息。 基本原理ConfigClient实例都监听MQ中同一个topic(默认是springCloudBus)。当一个服务刷新数据的时候，它会把这个信息放入到Topic中，这样其它监听同一Topic的服务就能得到通知，然后去更新自身的配置。

8. 消息驱动SpringCloudStream

SpringCloud实战—第十八篇：消息驱动SpringCloudStream

• CloudStream屏蔽底层消息中间件的差异,降低切换成本，统一消息的编程模型。
• 官方API：https://docs.spring.io/spring-cloud-stream/docs/current/reference/html/
• Stream中使用的是binder操作消息队列，类似于Hiburnate和Mybatis框架，通用的框架却可以操作多种数据库如mysql、Oracle等。
• 中文指导手册：https://m.wang1314.com/doc/webapp/topic/20971999.html
• Middleware：中间件，目前只支持RabbitMQ和Kafka。
• Binder：是应用和消息中间件之间的封装。
• @Input：注解标识输入通道，通过该输入通道接收到的消息进入应用程序。
• @Output：注解标识输出通道，发布的消息通过该通道发送到消息中间件。
• @StreamListener：监听队列，用于消费者队列的消息接收。
• @EnableBinding：指信道channel和exchange绑定在一起。

9. 分布式请求链路跟踪SpringCloudSleuth

SpringCloud实战—第十九篇：分布式请求链路跟踪Sleuth

• 在微服务框架中，一个由客户端发起的请求在后端系统中会经过多个不同的的服务节点调用来协同产生最后的请求结果，每一个前段请求都会形成一条复杂的分布式服务调用链路，链路中的任何一环出现高延时或错误都会引起整个请求最后的失败。
• 官网：https://github.com/spring-cloud/spring-cloud-sleuth
• Spring Cloud Sleuth提供了一套完整的服务跟踪的解决方案。
• 在分布式系统中提供追踪解决方案并且兼容支持了zipkin。
• 简单来说，Sleuth就是链路调用监控工具，通过zipkin可以实现图形化的调用链路监测。

至此，我们已经学习完成了SpringCloud完整的框架，这种保障微服务高可用、高并发性能的思想十分值得我们学习。

这套体系已经足够我们通常开发使用，但是技术总是在更替。

现在出现了新的、更优秀的微服务框架《SpringCloudAlibaba》，如果您感兴趣，请持续关注下个栏目。