Spring Cloud 理论篇

show me the code and talk to me,做的出来更要说的明白

github同步收录

我是布尔bl，你的支持是我分享的动力！

微服务

在 jsp 时代，应用前后端耦合，前后端 all in 一台服务器，随着流量的增大，代码数量的增加，单体应用不再适合互联网的发展，微服务顺应提出。

微服务是一种用于构建应用的架构方案。区别于更为传统的单体式方案，将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。

参考：https://www.redhat.com/zh/topics/microservices/what-are-microservices

Spring Cloud 版本

在微服务大哥的带领下，各种架构层出不穷，有 Dubbo、gRPC、Thrift、SpringCloud 等等，其中 Spring Cloud 背靠 Spring 生态，脱颖而出。Spring Cloud 框架是在 Springboot 框架基础上编写的，因此在技术选型的时候，我们需要注意 Spring Cloud 版本要与 Springboot 版本对应。

Spring Cloud 社区活跃，已经出了好几个版本，生命力旺盛。值得一提的是他的版本号。SpringCloud 不是使用数字作为版本号，而是将伦敦地铁站作为版本号，这让我想起被地铁支配的恐惧。

目前 SprinCloud官网主推荐版本是 Hoxton SR1。Spring Cloud 与 Spring Boot 有明确的版本对应关系。

Spring Cloud	Spring Boot
Hoxton	2.2.x
Greenwich	2.1.x
Finchley	2.0.x
Edgware	1.5.x
Dalston	1.5.x
Camden	1.4.x
Brixton	1.3.x
Angel	1.2.x

从图表可以看出 Spring Cloud 版本号的首字母是按照字母顺序排列的。
本文主要介绍的是基于 Spring Boot 1.5.x 的 Dalston 版本的 Spring Cloud。

Spring Cloud 是什么

Spring boot 是一个身怀绝技的武林高手，能上九天揽月下五洋捉鳖，反正就是牛，他喜欢结交武林各路英雄豪杰，有 MyBatis 、Redis、RabbitMQ、Kafaka、Elasticsearch 等等各路高手，他们喜欢行侠仗义，助人为乐，慢慢的以 Spring boot 为大佬的帮派越来越多，有一天 Spring boot 和兄弟们说，要不我们成立一个门派把，就叫 Spring Cloud 。

大家一呼百应。但是成立的门派后，需要管理啊，所以 Spring Cloud 成立了 Eureka 分舵（服务中心），负责对各个分舵同步门派的大事件，有新成员（提供者）加入门派，也需要到 Eureka 分舵报道，其他分舵（消费者）需要协助，也像 Eureka 分舵请求支援。分舵也培养新分舵，出现了几个职能相同的分舵（服务带集群），Eureka 分舵看到分舵越来越多，自己也开始培养新分舵（服务中心集群）。同时也建立了一个 Ribbon 分舵（客户端负载均衡），负责对各个分舵进行高效的沟通。 Spring Cloud 门派名声越来越大，加入的人越来越多，Spring Cloud 开始成立了 Zuul 分舵（网关），负责对新加入的人员进行筛选。

江湖还在，Spring Cloud 门派也越来越强大，到处都是他的传说

Spring Cloud 与 Dubbo 区别

目前来说，在 Java 领域，微服务主要是 Spring Cloud 和 Dubbo 的天下，因此，人们经常喜欢比较两种技术，然后选择其中一种进行搭建。

由于 Dubbo 是国人开发的，有详细的开发文档，在 Spring Cloud 的萌芽时，国人凭着满腔热情大力发展 Dubbo，不断试坑，后来 Dubbo 发展停滞，Spring Cloud 的春风开始席卷神州大地。不过，目前 Dubbo 又开始起色，捐给了 Apache 。

技术维度	Dubbo	Spring Cloud
服务注册中心	Zookeeper	Spring Cloud Netflix Eurrke
服务调用方式	RPC	REST API
服务监控	Dubbo-monitor	spring boot admin
断路器	不完善	Spirng Cloud Netflix Hystrix
服务网关	无	Spring Cloud Netflix Zuul
分布式配置	无	Spring Cloud Config

Eureka 组件

Eureka 音译尤里卡，是 Spring Cloud 的注册中心。在分布式系统中，包含很多个节点，这些节点大体分为消费者和提供者。

服务端和客户端就是通过 Eureka 进行管理的。举一个例子，Eureka 就好比小区的快递箱，快递就是服务端，取快递的人就是客户端。我们什么时候可以取快递呢，等快递箱向我们发送短信，我们就可以去取快递了。这就是 Eureka 的作用。这样看来服务中心 Eureka 是十分重要的，为了保证高可用，避免注册中心挂掉，我们两眼一抹黑的尴尬局面，一般来说， Eureka 会做集群，保证高可用。同理可得，服务中心我们也需要集群，保证高可用。

Eureka 作为 Spring Cloud 框架的注册中心，与之对应的是 Dubbo 框架的Zookeeper。他俩有什么区别呢？这里需要引入一个 CAP 定理。所谓 CAP 定理，分布式系统的三个指标 C（一致性）、A（可用性）、P（分区容错性）不可以同时满足了。

一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，剩下的 C 和 A 无法同时做到

参考：https://www.ruanyifeng.com/blog/2018/07/cap.html

而 Eureka 的设计原则是 AP，即可用性和分区容错性。他保证了注册中心的可用性，但舍弃了数据一致性，各节点上的数据有可能是不一致的（会最终一致）。ZK 的设计原则是 CP，即强一致性和分区容错性。他保证数据的强一致性，但舍弃了可用性，如果出现网络问题可能会影响 ZK 的选举，导致 ZK 注册中心的不可用。

参考：https://www.infoq.cn/article/jlDJQ*3wtN2PcqTDyokh

Ribbon

微服务划分成几个节点，他们分布在不同的虚拟机，通讯就成了一个难点，通过我们会想到 HttpClient，如果是 Spring的话，我们可以用 RestTemplate，但是在集群环境下，他们并不能做到负载均衡。因此，Ribbon 出现了。Ribbon 是一款在客户端实行负载均衡的工具。Ribbon 其实现原理就是根据在配置文件中列出的机器，自动按照某种规则（轮询，随机）去连接这些机器。使用者也可以自定义自己的负载均衡算法。负载均衡目的是达到高可用。

Feign

Feign 是有一款客户端负载均衡工具。既然有了 Ribbon ，为什么还要有 Feign 呢？在实际使用 Ribbon 组件中，我们会发现 Ribbon 会让我们硬编码，十分不灵活。因此，在 Ribbon 的基础下，面向接口编程的 Feign 组件就出现了。Feign 让我们可以编写出优雅的代码，因此，实际中，Feign 得到大力使用。

Hystrix

Hystrix 是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix 能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

Hystrix 断路器是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控，向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方不会长时间、不必要占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

提到服务雪崩，我们可以通过一张图来理解。假设我们有三个服务调用 A B C。当其中下游的 C 服务发生故障，就有可能引起服务雪崩。为了解决服务雪崩，我们就需要引入 Hystrix 组件。

Hystrix 主要是通过服务熔断和服务降级来解决服务雪崩问题。那么问题来了，服务熔断和服务降级的区别又是什么？

简单来说服务熔断属于服务降级的一种，而服务降级有很多种降级方式！如开关降级、限流降级、熔断降级。

参考：https://www.cnblogs.com/rjzheng/p/10340176.html

Zuul

Zuul中文是神兽的意思。在Spring Cloud 中，Zuul是一项网关服务，可提供动态路由，监视，弹性，安全性等。

简单的话，Zuul 就是楼下保安亭的大爷，所有进入大楼的人，都需要大爷检查，得到大爷的许可。我们可以通过一张图理解。

Spring Cloud Config

实际工作中，我们可能会有几十上百的微服务节点，每一个节点有需要有配置信息，比如数据库的连接，服务中心的地址等等，当中信息变化的时候，我们可能面临手动一台一台修改的囧境。为了解决上述问题，我们能否借鉴 Git 的思想，有一个标准的配置，当我们配置修改，我们只需要同步刷新一下即可，不用手动搬运呢？答案是有的，我们可以通过 Spring Cloud Config 达到同步更新配置信息。

公众号