你想了解的「SpringCloud」都在这里

时间 2019-12-06

标签了解 springcloud 都在这里繁體版

原文原文链接

前言： 以前咱们已经了解了「什么是微服务？」，如今咱们开始了解「微服务」关键字下比较热门的「Spring Cloud」...html

1、传统架构发展史

部分引用自：从架构演进的角度聊聊Spring Cloud都作了些什么？ - 纯洁的微笑前端

单体架构

单体架构在小微企业比较常见，典型表明就是一个应用、一个数据库、一个web容器就能够跑起来。java

在两种状况下可能会选择单体架构：一是在企业发展的初期，为了保证快速上线，采用此种方案较为简单灵活；二是传统企业中垂直度较高，访问压力较小的业务。在这种模式下对技术要求较低，方便各层次开发人员接手，也能知足客户需求。git

下面是单体架构的架构图：程序员

在单体架构中，技术选型很是灵活，优先知足快速上线的要求，也便于快速跟进市场。github

垂直架构

在单体架构发展一段时间后，公司的业务模式获得了承认，交易量也慢慢的大起来，这时候有些企业为了应对更大的流量，就会对原有的业务进行拆分，好比说：后台系统、前端系统、交易系统等。web

在这一阶段每每会将系统分为不一样的层级，每一个层级有对应的职责，UI层负责和用户进行交互、业务逻辑层负责具体的业务功能、数据库层负责和上层进行数据交换和存储。spring

下面是垂直架构的架构图：数据库

服务化架构

若是公司进一步的作大，垂直子系统会变的愈来愈多，系统和系统之间的调用关系呈指数上升的趋势。在这样的背景下，不少公司都会考虑服务的 SOA 化。SOA 表明面向服务的架构，将应用程序根据不一样的职责划分为不一样的模块，不一样的模块直接经过特定的协议和接口进行交互。这样使整个系统切分红不少单个组件服务来完成请求，当流量过大时经过水平扩展相应的组件来支撑，全部的组件经过交互来知足总体的业务需求。c#

SOA服务化的优势是，它能够根据需求经过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，能够直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

服务化架构是一套松耦合的架构，服务的拆分原则是服务内部高内聚，服务之间低耦合。

下面是服务化架构图：

在这个阶段可使用 WebService 或者 Dubbo 来服务治理。

咱们发现从单体架构到服务化架构，应用数量都在不断的增长，慢慢的下沉的就成了基础组建，上浮的就成为业务系统。从上述也能够看出架构的本质就是不断的拆分重构：分的过程是把系统拆分为各个子系统/模块/组件，拆的时候，首先要解决每一个组件的定位问题，而后才能划分彼此的边界，实现合理的拆分。合就是根据最终要求，把各个分离的组件有机整合在一块儿。拆分的结果使开发人员可以作到业务聚焦、技能聚焦，实现开发敏捷，合的结果是系统变得柔性，能够因需而变，实现业务敏捷。

微服务架构

微服务是一种软件架构风格，它是以专一于单一责任与功能的小型功能区块为基础，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关的 API（例如 REST）集相互通信，且每一个服务能够被单独部署，它具有如下三个核心特色：

微服务为大型系统而生。随着业务的快速增加，会带来系统流量压力和复杂度的上升，系统的可维护性和可扩展性成为架构设计的主要考虑因素，微服务架构设计理念经过小而美的业务拆分，经过分而自治来实现复杂系统的优雅设计实现。
微服务架构是面向结果的。微服务架构设计风格的产生并不是是出于学术或为标准而标准的设计，而是在软件架构设计领域不断演进过程当中，面对实际工业界所遇到问题，而出现的面向解决实际问题的架构设计风格。
专一于服务的可替代性来设计。微服务架构设计风格核心要解决的问题之一即是如何便利地在大型系统中进行系统组件的维护和替换，且不影响总体系统稳定性。

SOA 与 微服务 的不一样在于：

服务拆分粒度更细。微服务能够说是更细维度的服务化，小到一个子子模块，只要该模块依赖的资源与其余模块都没有关系，那么就能够拆分红一个微服务。
服务独立部署。每一个服务都严格遵循独立打包部署的准则，互不影响。好比一台物理机上能够部署多个 Docker 实例，每一个 Docker 实例能够部署一个微服务的代码。
服务独立维护。每一个微服务均可以交由一个小团队甚至我的来开发、测试、发布和运维，并对整个生命周期负责。
服务治理能力要求高。由于拆分为微服务以后，服务的数量变多，所以须要有统一的服务治理平台，来对各个服务进行管理。

2、引入 Spring Cloud

什么是 Spring Cloud?

Spring 全家桶在 Java 开发中拥有举足轻重的地位，其中的一系列产品不只仅大大简化和方便了 Java 的开发，其中的 AOP 和 IoC 等一系列的理念也深入地影响着 Java 程序员们。

Spring 全家桶产品众多，总结起来大概就是：

Spring 一般指 Spring IOC。
Spring Framework 包含了 Spring IOC，同时包含了 Spring AOP，并实现与其它 J2EE 框架的整合。
Spring Boot 是对 Spring Framework 的补充，让框架的集成变得更简单，致力于快速开发独立的 Spring 应用。
Spring Cloud 是基于 Spring Boot 设计的一套微服务规范，并加强了应用上下文。

咱们也不妨来看看官网的介绍：

总结起来就是： Spring Cloud 是一系列框架的有序集合。咱们可以使用基于 Spring Boot 设计的 Spring Cloud 方便快速的搭建起本身的可靠、协调一致的分布式系统。

为何是 Spring Cloud？

微服务的框架那么多好比：Dubbo、Kubernetes，为何就要使用 Spring Cloud 的呢？

产出于 Spring 你们族，Spring 在企业级开发框架中无人能敌，来头很大，能够保证后续的更新、完善。好比 Dubbo 如今就差很少死了
有 Spring Boot 这个独立干将能够省不少事，大大小小的活 Spring Boot 都搞的挺不错。
做为一个微服务治理的你们伙，考虑的很全面，几乎服务治理的方方面面都考虑到了，方便开发开箱即用。
Spring Cloud 活跃度很高，教程很丰富，遇到问题很容易找到解决方案。
轻轻松松几行代码就完成了熔断、均衡负载、服务中心的各类平台功能。

3、Spring Cloud 可以帮咱们作什么？

前面咱们说到了，「Spring Cloud」是一系列框架的集合，能够帮助咱们解决分布式/微服务的各类问题，那么「Spring Cloud」究竟能帮助咱们作什么呢？

SpringCloud的基础功能包括：

服务治理： Spring Cloud Eureka
客户端负载均衡： Spring Cloud Ribbon
服务容错保护： Spring Cloud Hystrix
声明式服务调用： Spring Cloud Feign
API网关服务： Spring Cloud Zuul
分布式配置中心： Spring Cloud Config

固然 Spring Cloud 还包括一些高级的功能：

消息总线： Spring Cloud Bus
消息驱动的微服务： Spring Cloud Stream
分布式服务跟踪： Spring Cloud Sleuth

服务治理：Eureka

微服务很重要的一点就是「无状态」，也就是说每个服务之间应该是独立的，因此当微服务架构搭起来以后各个独立的「微服务」之间应该如何通信成了首要的问题。

假设咱们的 A服务须要访问 B服务，那么咱们首先须要知道对方的 ip地址，因此咱们调用起来可能就像：

彷佛并无什么问题，可是若是 B服务的 ip地址 变动了，那么咱们就只能手动的去更改 A服务的配置，若是咱们的服务有不少，而且不止 A服务调用了 B服务，那么手动更改这些配置将会是一场噩梦。

Eureka 是 Netflix 开源的一款提供服务注册和发现的产品，它提供了完整的 Service Registry 和 Service Discovery 实现。也是 Spring Cloud 体系中最重要最核心的组件之一。

用大白话讲，Eureka 就是一个服务中心，将全部的能够提供的服务都注册到它这里来管理，其它各调用者须要的时候去注册中心获取，而后再进行调用，避免了服务之间的直接调用，方便后续的水平扩展、故障转移等。以下图：

固然服务中心这么重要的组件一但挂掉将会影响所有服务，所以须要搭建 Eureka 集群来保持高可用性，生产中建议最少两台。随着系统的流量不断增长，须要根据状况来扩展某个服务，Eureka 内部已经提供均衡负载的功能，只须要增长相应的服务端实例既可。那么在系统的运行期间某个实例挂了怎么办？Eureka 内容有一个心跳检测机制， 若是某个实例在规定的时间内没有进行通信则会自动被剔除掉，避免了某个实例挂掉而影响服务。

所以使用了Eureka就自动具备了注册中心、负载均衡、故障转移的功能。若是想对Eureka进一步了解能够参考这篇文章：注册中心Eureka

客户端负载均衡： Ribbon

Ribbon 是一个基于 HTTP 和 TCP 客户端的负载均衡器。Ribbon 能够在经过客户端中配置的 ribbonServerList 服务端列表去轮询访问以达到均衡负载的做用。

当 Ribbon 与 Eureka 联合使用时，ribbonServerList 会被 DiscoveryEnabledNIWSServerList 重写，扩展成从 Eureka 注册中心中获取服务端列表。同时它也会用 NIWSDiscoveryPing 来取代 IPing，它将职责委托给 Eureka 来肯定服务端是否已经启动。

实战：

Spring Cloud构建微服务架构（二）服务消费者 - http://blog.didispace.com/springcloud2/

服务容错保护： Hystrix

在微服务架构中一般会有多个服务层调用，基础服务的故障可能会致使级联故障，进而形成整个系统不可用的状况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用致使“服务消费者”的不可用,并将不可用逐渐放大的过程。

以下图所示：A做为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引发了B的不可用，并将不可用像滚雪球同样放大到C和D时，雪崩效应就造成了。

在这种状况下就须要整个服务机构具备故障隔离的功能，避免某一个服务挂掉影响全局。在 Spring Cloud 中 Hystrix 组件就扮演这个角色。

Hystrix 会在某个服务连续调用 N 次不响应的状况下，当即通知调用端调用失败，避免调用端持续等待而影响了总体服务。Hystrix 间隔时间会再次检查此服务，若是服务恢复将继续提供服务。

继续了解Hystrix能够参考：熔断器Hystrix

Hystrix Dashboard 和 Turbine

当熔断发生的时候须要迅速的响应来解决问题，避免故障进一步扩散，那么对熔断的监控就变得很是重要。熔断的监控如今有两款工具：Hystrix-dashboard 和 Turbine

Hystrix-dashboard 是一款针对Hystrix进行实时监控的工具，经过 Hystrix Dashboard 咱们能够直观地看到各 Hystrix Command 的请求响应时间, 请求成功率等数据。可是只使用 Hystrix Dashboard 的话, 你只能看到单个应用内的服务信息, 这明显不够. 咱们须要一个工具能让咱们汇总系统内多个服务的数据并显示到 Hystrix Dashboard 上, 这个工具就是 Turbine. 监控的效果图以下：

想了解具体都监控了哪些指标，以及如何监控能够参考这篇文章：熔断监控Hystrix Dashboard和Turbine

声明式服务调用：Feign

上面咱们介绍了 Ribbon 和 Hystrix 了，能够发现：这两个能够做为基础工具类普遍的嵌入到各个微服务中。为了简化咱们的开发，Spring Cloud Feign 出现了！它基于 Netflix Feign 实现，整合了 Spring Cloud Ribbon 与 Spring Cloud Hystrix, 除了整合这二者的强大功能以外，它还提供了声明式的服务调用(再也不经过RestTemplate)。

Feign 是一种声明式、模板化的HTTP客户端。在 Spring Cloud 中使用 Feign, 咱们能够作到使用HTTP请求远程服务时能与调用本地方法同样的编码体验，开发者彻底感知不到这是远程方法，更感知不到这是个 HTTP 请求。

下面就简单看看Feign是怎么优雅地实现远程调用的：

服务绑定：

// value --->指定调用哪一个服务
// fallbackFactory--->熔断器的降级提示
@FeignClient(value = "MICROSERVICECLOUD-DEPT", fallbackFactory = DeptClientServiceFallbackFactory.class)
public interface DeptClientService {

    // 采用Feign咱们可使用SpringMVC的注解来对服务进行绑定！
    @RequestMapping(value = "/dept/get/{id}", method = RequestMethod.GET)
    public Dept get(@PathVariable("id") long id);

    @RequestMapping(value = "/dept/list", method = RequestMethod.GET)
    public List<Dept> list();

    @RequestMapping(value = "/dept/add", method = RequestMethod.POST)
    public boolean add(Dept dept);
}

Feign 中使用熔断器：

/**
 * Feign中使用断路器
 * 这里主要是处理异常出错的状况(降级/熔断时服务不可用，fallback就会找到这里来)
 */
@Component // 不要忘记添加，不要忘记添加
public class DeptClientServiceFallbackFactory implements FallbackFactory<DeptClientService> {
    @Override
    public DeptClientService create(Throwable throwable) {
        return new DeptClientService() {
            @Override
            public Dept get(long id) {
                return new Dept().setDeptno(id).setDname("该ID：" + id + "没有没有对应的信息,Consumer客户端提供的降级信息,此刻服务Provider已经关闭")
                        .setDb_source("no this database in MySQL");
            }

            @Override
            public List<Dept> list() {
                return null;
            }

            @Override
            public boolean add(Dept dept) {
                return false;
            }
        };
    }
}

调用：

引用自：
外行人都能看懂的 Spring Cloud - https://juejin.im/post/5b83466b6fb9a019b421cecc#heading-12

API 网关服务：Zuul

在微服务架构模式下，后端服务的实例数通常是动态的，对于客户端而言很难发现动态改变的服务实例的访问地址信息。所以在基于微服务的项目中为了简化前端的调用逻辑，一般会引入 API Gateway 做为轻量级网关，同时 API Gateway 中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。

Spring Cloud 体系中支持 API Gateway 落地的技术就是 Zuul。Spring Cloud Zuul 路由是微服务架构中不可或缺的一部分，提供动态路由，监控，弹性，安全等的边缘服务。Zuul 是 Netflix 出品的一个基于 JVM 路由和服务端的负载均衡器。

它的具体做用就是服务转发，接收并转发全部内外部的客户端调用。使用 Zuul 能够做为资源的统一访问入口，同时也能够在网关作一些权限校验等相似的功能。

具体使用参考这篇文章：服务网关zuul

分布式配置中心：Config

随着业务的不断发展，咱们的「微服务」可能会愈来愈多，而每个微服务都会有本身的配置文件，在研发过程当中有测试环境、UAT环境、生产环境，所以每一个微服务又对应至少三个不一样环境的配置文件。这么多的配置文件，若是须要修改某个公共服务的配置信息，如：缓存、数据库等，不免会产生混乱，这个时候就须要引入 Spring Cloud 另一个组件：Spring Cloud Config。

Spring Cloud Config 是一个解决分布式系统的配置管理方案。它包含了 Client 和 Server 两个部分，Server 提供配置文件的存储、以接口的形式将配置文件的内容提供出去，Client 经过接口获取数据、并依据此数据初始化本身的应用。

其实就是 Server 端将全部的配置文件服务化，须要配置文件的服务实例去 Config Server 获取对应的数据。将全部的配置文件统一整理，避免了配置文件碎片化。配置中心git实例参考：配置中心git示例；

若是服务运行期间改变配置文件，服务是不会获得最新的配置信息，须要解决这个问题就须要引入 Refresh。能够在服务的运行期间从新加载配置文件，具体能够参考这篇文章：配置中心svn示例和refresh

当全部的配置文件都存储在配置中心的时候，配置中心就成为了一个很是重要的组件。若是配置中心出现问题将会致使灾难性的后果，所以在生产中建议对配置中心作集群，来支持配置中心高可用性。具体参考：配置中心服务化和高可用

消息总线：Bus

上面的 Refresh 方案虽然能够解决单个微服务运行期间重载配置信息的问题，可是在真正的实践生产中，可能会有 N 多的服务须要更新配置，若是每次依靠手动 Refresh 将是一个巨大的工做量，这时候 Spring Cloud 提出了另一个解决方案：Spring Cloud Bus

Spring Cloud Bus 经过轻量消息代理链接各个分布的节点。这会用在广播状态的变化（例如配置变化）或者其它的消息指令中。Spring Cloud Bus 的一个核心思想是经过分布式的启动器对Spring Boot应用进行扩展，也能够用来创建一个或多个应用之间的通讯频道。目前惟一实现的方式是用 AMQP 消息代理做为通道。

Spring Cloud Bus 是轻量级的通信组件，也能够用在其它相似的场景中。有了 Spring Cloud Bus 以后，当咱们改变配置文件提交到版本库中时，会自动的触发对应实例的 Refresh，具体的工做流程以下：

也能够参考这篇文章来了解：配置中心和消息总线

消息驱动的微服务：Stream

Spring Cloud Stream 是一个用来为微服务应用构建消息驱动能力的框架。它能够基于 Spring Boot 来建立独立的、可用于生产的 Spring 应用程序。它经过使用 Spring Integration 来链接消息代理中间件以实现消息事件驱动的微服务应用。

下图是官方文档中对于 Spring Cloud Stream 应用模型的结构图。从中咱们能够看到，Spring Cloud Stream 构建的应用程序与消息中间件之间是经过绑定器 Binder 相关联的，绑定器对于应用程序而言起到了隔离做用，它使得不一样消息中间件的实现细节对应用程序来讲是透明的。因此对于每个 Spring Cloud Stream 的应用程序来讲，它不须要知晓消息中间件的通讯细节，它只须要知道 Binder 对应用程序提供的概念去实现便可。以下图案例，在应用程序和 Binder 之间定义了两条输入通道和三条输出通道来传递消息，而绑定器则是做为这些通道和消息中间件之间的桥梁进行通讯。

Spring Cloud Stream 为一些供应商的消息中间件产品提供了个性化的自动化配置实现，而且引入了发布-订阅、消费组以及消息分区这三个核心概念。简单的说，Spring Cloud Stream 本质上就是整合了 Spring Boot 和 Spring Integration，实现了一套轻量级的消息驱动的微服务框架。经过使用 Spring Cloud Stream，能够有效地简化开发人员对消息中间件的使用复杂度，让系统开发人员能够有更多的精力关注于核心业务逻辑的处理。因为 Spring Cloud Stream 基于 Spring Boot 实现，因此它秉承了 Spring Boot 的优势，实现了自动化配置的功能帮忙咱们能够快速的上手使用，可是目前为止 Spring Cloud Stream 只支持 RabbitMQ 和 Kafka 两个著名的消息中间件的自动化配置：

实战：
Spring Cloud构建微服务架构：消息驱动的微服务（入门）【Dalston版】 - http://blog.didispace.com/spring-cloud-starter-dalston-7-1/

分布式服务跟踪：Sleuth

随着服务的愈来愈多，对调用链的分析会愈来愈复杂，如服务之间的调用关系、某个请求对应的调用链、调用之间消费的时间等，对这些信息进行监控就成为一个问题。在实际的使用中咱们须要监控服务和服务之间通信的各项指标，这些数据将是咱们改进系统架构的主要依据。所以分布式的链路跟踪就变的很是重要，Spring Cloud 也给出了具体的解决方案：Spring Cloud Sleuth 和 Zipkin

Spring Cloud Sleuth 为服务之间调用提供链路追踪。经过 Sleuth 能够很清楚的了解到一个服务请求通过了哪些服务，每一个服务处理花费了多长时间。从而让咱们能够很方便的理清各微服务间的调用关系。

Zipkin 是 Twitter 的一个开源项目，容许开发者收集 Twitter 各个服务上的监控数据，并提供查询接口

分布式链路跟踪须要 Sleuth + Zipkin 结合来实现，具体操做参考这篇文章：分布式链路跟踪(Sleuth)

总结

咱们从总体上来看一下Spring Cloud各个组件如何来配套使用：

从上图能够看出 Spring Cloud 各个组件相互配合，合做支持了一套完整的微服务架构。

其中 Eureka 负责服务的注册与发现，很好将各服务链接起来
Hystrix 负责监控服务之间的调用状况，连续屡次失败进行熔断保护。
Hystrix dashboard,Turbine 负责监控 Hystrix 的熔断状况，并给予图形化的展现
Spring Cloud Config 提供了统一的配置中心服务
当配置文件发生变化的时候，Spring Cloud Bus 负责通知各服务去获取最新的配置信息
全部对外的请求和服务，咱们都经过 Zuul 来进行转发，起到 API 网关的做用
最后咱们使用 Sleuth + Zipkin 将全部的请求数据记录下来，方便咱们进行后续分析

Spring Cloud 从设计之初就考虑了绝大多数互联网公司架构演化所需的功能，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。这些功能都是以插拔的形式提供出来，方便咱们系统架构演进的过程当中，能够合理的选择须要的组件进行集成，从而在架构演进的过程当中会更加平滑、顺利。

微服务架构是一种趋势，Spring Cloud 提供了标准化的、全站式的技术方案，意义可能会堪比当前 Servlet 规范的诞生，有效推动服务端软件系统技术水平的进步。

引用自：从架构演进的角度聊聊Spring Cloud都作了些什么？ - http://www.ityouknow.com/springcloud/2017/11/02/framework-and-springcloud.html

4、Spring Cloud 版本

刚接触的「Spring Cloud」的童鞋可能会对它的版本感到奇怪，什么 Angle、Brixton、Finchley，这些都是啥啊？「为何会有这么多种看起来不一样的 Spring Cloud？」

从上面咱们能够知道：Spring Cloud 是一个拥有诸多子项目的大型综合项目（功能不止上面的介绍），原则上其子项目也都维护着本身的发布版本号。那么每个Spring Cloud的版本都会包含不一样的子项目版本，为了要管理每一个版本的子项目清单，避免版本名与子项目的发布号混淆，因此没有采用版本号的方式，而是经过命名的方式。

这些版本名字采用了伦敦地铁站的名字，根据字母表的顺序来对应版本时间顺序，好比：最先的Release版本：Angel，第二个Release版本：Brixton，以此类推……

当一个项目到达发布临界点或者解决了一个严重的 BUG 后就会发布一个 "service Release" 版本，简称 SR（X）版本，x 表明一个递增数字。

引用自：
聊聊Spring Cloud版本的那些事儿 - http://blog.didispace.com/springcloud-version/

Spring Cloud & Spring Boot 版本对照表

经过查阅官网：https://spring.io/projects/spring-cloud，咱们能够看到一个「Release train Spring Boot compatibility」表：

Release Train	Boot Version
Greenwich	2.1.x
Finchley	2.0.x
Edgware	1.5.x
Dalston	1.5.x

上表能够看出，最新的「Spring Cloud」版本已经出到了 Greenwich... 每一个版本都能查阅到当前版本所包含的子项目，以及子项目的版本号，咱们能够经过此来决定须要选择怎么样的版本。

参考资料

1. 外行人都能看懂的SpringCloud，错过了血亏！ - https://juejin.im/post/5b83466b6fb9a019b421cecc#heading-19
2. 从架构演进的角度聊聊Spring Cloud都作了些什么？ - http://www.ityouknow.com/springcloud/2017/11/02/framework-and-springcloud.html
3. 聊聊Spring Cloud版本的那些事儿 - http://blog.didispace.com/springcloud-version/
4. Spring Cloud 从入门到精通 - http://blog.didispace.com/spring-cloud-learning/
5. Spring Cloud 中文网 - https://springcloud.cc/

按照惯例黏一个尾巴：

欢迎转载，转载请注明出处！
简书ID：@我没有三颗心脏
github：wmyskxz 欢迎关注公众微信号：wmyskxz 分享本身的学习 & 学习资料 & 生活想要交流的朋友也能够加qq群：3382693