微服务

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

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

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 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 。

Eureka 组件#

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

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

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

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

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

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 主要是通过服务熔断和服务降级来解决服务雪崩问题。那么问题来了，服务熔断和服务降级的区别又是什么？

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

Zuul

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

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

Spring Cloud Config

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