【易实战】SpringCloud Greenwich架构概览深度详解

最新推荐文章于 2022-08-24 07:51:54 发布

AI架构师易筋

最新推荐文章于 2022-08-24 07:51:54 发布

阅读量2.4k

点赞数 3

分类专栏：易实战Sprint Boot 2.1 服务端文章标签： SpringCloud SpringBoot 微服务分布式集群

本文链接：https://blog.csdn.net/zgpeace/article/details/104121183

版权

易实战Sprint Boot 2.1 同时被 2 个专栏收录

40 篇文章 6 订阅

订阅专栏

服务端

37 篇文章 0 订阅

订阅专栏

说明

在远古时代算盘可以解决算力问题。在20世纪初期电脑单机还是少数精英的特权，在21世纪互联网风起云涌, 高配置单机服务器不仅贵也应对不了海啸般的流量。集群、分布式系统来解围，SpringCloud微服务作为解决方案的佼佼者出现了。(解决方案类似于：三个臭皮匠胜过一个诸葛亮，如果不行就先来一亿个臭皮匠。)

微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

微服务的概念源于2014年3月Martin Fowler所写的章“Microservices”http://martinfowler.com/articles/microservices.html

Spring Cloud 是一系列框架的有序集合，它利用 Spring Boot 的开发便利性简化了分布式系统的开发，比如服务发现、服务网关、服务路由、链路追踪等。Spring Cloud 并不重复造轮子，而是将市面上开发得比较好的模块集成进去，进行封装，从而减少了各模块的开发成本。换句话说：Spring Cloud 提供了构建分布式系统所需的“全家桶”。

接下来先简单说明SpringCloud的相关概念，集群、分布式系统、微服务。

1. 什么是集群

计算机集群简称集群是一种计算机系统，它通过一组松散集成的计算机软件和/或硬件连接起来高度紧密地协作完成计算工作。在某种意义上，他们可以被看作是一台计算机。集群系统中的单个计算机通常称为节点，通常通过局域网连接，但也有其它的可能连接方式。集群计算机通常用来改进单个计算机的计算速度和/或可靠性。一般情况下集群计算机比单个计算机，比如工作站或超级计算机性能价格比要高得多. (维基百科)

集群技术特点：

通过多台计算机完成同一个工作，达到更高的效率。
两机或多机内容、工作过程等完全一样。如果一台死机，另一台可以照常工作。
同一个业务，部署在多个服务器上(不同的服务器运行同样的代码，干同一件事)。

2. 什么是分布式

分布式系统是一组计算机，通过网络相互连接传递消息与通信后并协调它们的行为而形成的系统。组件之间彼此进行交互以实现一个共同的目标。(维基百科)

将每个模块抽取独立出来，访问量大的模块用好的服务器装着，没啥人访问的模块用差的服务器装着。这样的好处是：一、资源合理利用了(没人访问的模块用性能差的服务器，访问量大的模块单独提升性能就好了)。二、耦合度降低了：每个模块独立出来，各干各的事(专业的人做专业的事)，便于扩展

分布式：一个业务分拆多个子业务，部署在不同的服务器上(不同的服务器，运行不同的代码，为了同一个目的)

特点：

将大功能拆分，模块之间独立，在使用的时候再将这些独立的模块组合起来就是一个系统了。

好处：

模块之间独立，各做各的事，便于扩展，复用性高
高吞吐量。某个任务需要一个机器运行10个小时，将该任务用10台机器的分布式跑(将这个任务拆分成10个小任务)，可能2个小时就跑完了

3. CAP理论

从上面所讲的分布式概念我们已经知道，分布式简单理解就是：一个业务分拆多个子业务，部署在不同的服务器上

一般来说，一个子业务我们称为节点。

如果你接触过一些分布式的基础概念，那肯定会听过CAP这个理论。就比如说：你学了MySQL的InnoDB存储引擎相关知识，你肯定听过ACID！
首先，我们来看一下CAP分别代表的是什么意思：

C：数据一致性(consistency)，所有节点拥有数据的最新版本
A：可用性(availability)，数据具备高可用性
P：分区容错性(partition-tolerance)，容忍网络出现分区，分区之间网络不可达。

下面有三个节点(它们是集群的)，此时三个节点都能够相互通信：
在这里插入图片描述
由于我们的系统是分布式的，节点之间的通信是通过网络来进行的。只要是分布式系统，那很有可能会出现一种情况：因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。

数据就散布在了这些不连通的区域中，这就叫分区
在这里插入图片描述
现在出现了网络分区后，此时有一个请求过来了，想要注册一个账户。

此时我们节点一和节点三是不可通信的，这就有了抉择：

如果允许当前用户注册一个账户，此时注册的记录数据只会在节点一和节点二或者节点二和节点三同步，因为节点一和节点三的记录不能同步的。

这种情况其实就是选择了可用性(availability)，抛弃了数据一致性(consistency)

如果不允许当前用户注册一个账户(就是要等到节点一和节点三恢复通信)。节点一和节点三一旦恢复通信，我们就可以保证节点拥有的数据是最新版本。

这种情况其实就是抛弃了可用性(availability)，选择了数据一致性(consistency)

4. CAP理论中间状态只能三者选其二

一般我们说的分布式系统，P：分区容错性(partition-tolerance)这个是必需的，这是客观存在的。

CAP是无法完全兼顾的，从上面的例子也可以看出，我们可以选AP，也可以选CP。但是，要注意的是：不是说选了AP，C就完全抛弃了。不是说选了CP，A就完全抛弃了！

在CAP理论中，C所表示的一致性是强一致性(每个节点的数据都是最新版本)，其实一致性还有其他级别的：

弱一致性：弱一致性是相对于强一致性而言，它不保证总能得到最新的值；
最终一致性(eventual consistency)：放宽对时间的要求，在被调完成操作响应后的某个时间点，被调多个节点的数据最终达成一致

可用性的值域可以定义成0到100%的连续区间。

可用性分类	可用水平(%)	年容忍停机时间
容错可用性	99.9999(6个9)	< 1 min
极高可用性	99.999(5个9)	< 5 min
具有故障自动恢复能力的可用性	99.99(4个9)	< 53 min
高可用性	99.9(3个9)	< 8.8 h
商品可用性	99(2个9)	< 43.8 h

所以，CAP理论定义的其实是在容忍网络分区的条件下，“强一致性”和“极致可用性”无法同时达到。

5. 为什么需要SpringCloud

前面也讲了，从分布式/微服务的角度而言：就是把我们一大的项目，分解成多个小的模块。这些小的模块组合起来，完成功能。

举个可能不太恰当的例子(现实可能不会这么拆分，但意思到位就好了)：
在这里插入图片描述
拆分出多个模块以后，就会出现各种各样的问题，而SpringCloud提供了一整套的解决方案！

注：这些模块是独立成一个子系统的(不同主机)。

SpringCloud的基础功能：

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

SpringCloud的高级功能：

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

Spring Cloud 优缺点
其主要优点有：

集大成者，Spring Cloud 包含了微服务架构的方方面面。
约定优于配置，基于注解，没有配置文件。
轻量级组件，Spring Cloud 整合的组件大多比较轻量级，且都是各自领域的佼佼者。
开发简便，Spring Cloud 对各个组件进行了大量的封装，从而简化了开发。
开发灵活，Spring Cloud 的组件都是解耦的，开发人员可以灵活按需选择组件。

接下来，我们看下它的缺点：

项目结构复杂，每一个组件或者每一个服务都需要创建一个项目。
部署门槛高，项目部署需要配合 Docker 等容器技术进行集群部署，而要想深入了解 Docker，学习成本高。

Spring Cloud 的优势是显而易见的。因此对于想研究微服务架构的同学来说，学习 Spring Cloud 是一个不错的选择。

Spring Cloud 和 Dubbo 对比
Dubbo 只是实现了服务治理，而 Spring Cloud 实现了微服务架构的方方面面，服务治理只是其中的一个方面。下面通过一张图对其进行比较：

核心要素	Dubbo	Spring Cloud
服务注册中心	Zookepper, Redis	Spring Cloud Netflix Eureka
服务调用方式	RPC	REST API
服务网关	无	Spring Cloud Netflix Zuul
熔断隔离	不完善	Spring Cloud Netflix Hystrix
分布式配置	无	Spring Cloud Config
分布式追踪系统	无	Spring Cloud Sleuth
消息总线	无	Spring Cloud Bus
数据流	无	Spring Cloud Stream 基于Redis, Rabbit, Kafka实现的消息微服务
批量任务	无	Spring Cloud Task

可以看出，Spring Cloud 比较全面，而 Dubbo 由于只实现了服务治理，需要集成其他模块，需要单独引入，增加了学习成本和集成成本。

SpringCloud的版本关系

SpringCloud是一个由许多子项目组成的综合项目，各子项目有不同的发布节奏。为了管理SpringCloud与各子项目的版本依赖关系，发布了一个清单，其中包括了某个SpringCloud版本对应的子项目版本。

为了避免SpringCloud版本号与子项目版本号混淆，SpringCloud版本采用了名称而非版本号的命名，这些版本的名字采用了伦敦地铁站的名字，根据字母表的顺序来对应版本时间顺序，例如Angel是第一个版本, Brixton是第二个版本。

当SpringCloud的发布内容积累到临界点或者一个重大BUG被解决后，会发布一个"service releases"版本，简称SRX版本，比如Greenwich.SR2就是SpringCloud发布的Greenwich版本的第2个SRX版本。

SpringCloud和SpringBoot版本对应关系

SpringCloud Version	SpringBoot Version
Hoxton	2.2.x
Greenwich	2.1.x
Finchley	2.0.x
Edgware	1.5.x
Dalston	1.5.x

SpringCloud和各子项目版本对应关系

Component	Edgware.SR6	Greenwich.SR2
spring-cloud-netflix	1.4.7.RELEASE	2.1.2.RELEASE
spring-cloud-consul	1.3.6.RELEASE	2.1.2.RELEASE
spring-cloud-gateway	1.0.3.RELEASE	2.1.2.RELEASE
spring-cloud-openfeign	Null	2.1.2.RELEASE
spring-cloud-config	1.4.7.RELEASE	2.1.3.RELEASE
spring-cloud-security	1.2.4.RELEASE	2.1.2.RELEASE
spring-cloud-bus	1.3.4.RELEASE	2.1.2.RELEASE
spring-cloud-commons	1.3.6.RELEASE	2.1.2.RELEASE
spring-cloud-sleuth	1.3.6.RELEASE	2.1.1.RELEASE
spring-cloud-stream	Ditmars.SR5	Fishtown.SR3
spring-cloud-zookeeper	1.2.3.RELEASE	2.1.2.RELEASE
spring-cloud-task	1.2.4.RELEASE	2.1.2.RELEASE

注意：Greenwich版本是基于SpringBoot 2.1.x版本构建的，不适用于1.5.x版本。随着2019年8月SpringBoot 1.5.x版本停止维护，Edgware版本也将停止维护。

6. 引出Eureka

那会出现什么问题呢？？首当其冲的就是子系统之间的通讯问题。子系统与子系统之间不是在同一个环境下，那就需要远程调用。远程调用可能就会想到httpClient，WebService等等这些技术来实现。

既然是远程调用，就必须知道ip地址，我们可能有以下的场景。

功能实现一：A服务需要调用B服务
** 在A服务的代码里面调用B服务，显式通过IP地址调用：http://123.123.123.123:8888/zgpeace
功能实现二：A服务调用B服务，B服务调用C服务，C服务调用D服务
** 在A服务的代码里面调用B服务，显式通过IP地址调用：http://123.123.123.123:8888/zgpeace，(同样地)B->C，C->D
功能实现三：D服务调用B服务，B服务调用C服务
** 在D服务的代码里面调用B服务，显式通过IP地址调用：http://123.123.123.123:8888/zgpeace，(同样地)B->C
…等等等等

万一，我们B服务的IP地址变了，想想会出现什么问题：A服务,D服务(等等)需要手动更新B服务的地址

在服务多的情况下，手动来维护这些静态配置就是噩梦！

为了解决微服务架构中的服务实例维护问题(ip地址)，产生了大量的服务治理框架和产品。这些框架和产品的实现都围绕着服务注册与服务发现机制来完成对微服务应用实例的自动化管理。

在SpringCloud中我们的服务治理框架一般使用的就是Eureka。

我们的问题：

现在有A、B、C、D四个服务，它们之间会互相调用(而且IP地址很可能会发生变化)，一旦某个服务的IP地址变了，那服务中的代码要跟着变，手动维护这些静态配置(IP)非常麻烦！

Eureka是这样解决上面所说的情况的：

创建一个E服务，将A、B、C、D四个服务的信息都注册到E服务上，E服务维护这些已经注册进来的信息

A、B、C、D四个服务都可以拿到Eureka(服务E)那份注册清单。A、B、C、D四个服务互相调用不再通过具体的IP地址，而是通过服务名来调用！
拿到注册清单—>注册清单上有服务名—>自然就能够拿到服务具体的位置了(IP)。
其实简单来说就是：代码中通过服务名找到对应的IP地址(IP地址会变，但服务名一般不会变)

7. Eureka细节

Eureka专门用于给其他服务注册的称为Eureka Server(服务注册中心)，其余注册到Eureka Server的服务称为Eureka Client
在这里插入图片描述
在Eureka Server一般我们会这样配置：


    register-with-eureka: false     #false表示不向注册中心注册自己。
    fetch-registry: false     #false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务

Eureka Client分为服务提供者和服务消费者。

但很可能，某服务既是服务提供者又是服务消费者。

如果在网上看到SpringCloud的某个服务配置没有"注册"到Eureka-Server也不用过于惊讶(但是它是可以获取Eureka服务清单的)

很可能只是作者把该服务认作为单纯的服务消费者，单纯的服务消费者无需对外提供服务，也就无须注册到Eureka中了

eureka:
  client:
    register-with-eureka: false  # 当前微服务不注册到eureka中(消费端)
    service-url: 
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/

下面是Eureka的治理机制：

服务提供者

服务注册：启动的时候会通过发送REST请求的方式将自己注册到Eureka Server上，同时带上了自身服务的一些元数据信息。
服务续约：在注册完服务之后，服务提供者会维护一个心跳用来持续告诉Eureka Server: "我还活着 ” 、
服务下线：当服务实例进行正常的关闭操作时，它会触发一个服务下线的REST请求给Eureka Server, 告诉服务注册中心：“我要下线了 ”。

服务消费者

获取服务：当我们启动服务消费者的时候，它会发送一个REST请求给服务注册中心，来获取上面注册的服务清单
服务调用：服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。在进行服务调用的时候，优先访问同处一个Zone中的服务提供方。

Eureka Server(服务注册中心)：

失效剔除：默认每隔一段时间（默认为60秒）将当前清单中超时（默认为90秒）没有续约的服务剔除出去。
自我保护：EurekaServer 在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%(通常由于网络不稳定导致)。 Eureka Server会将当前的实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。

最后，我们就有了这张图：
在这里插入图片描述

8. 引出RestTemplate和Ribbon

通过Eureka服务治理框架，我们可以通过服务名来获取具体的服务实例的位置了(IP)。一般在使用SpringCloud的时候不需要自己手动创建HttpClient来进行远程调用。
可以使用Spring封装好的RestTemplate工具类，使用起来很简单：


	// 传统的方式，直接显示写死IP是不好的！
    //private static final String REST_URL_PREFIX = "http://localhost:8001";
	
	// 服务实例名
    private static final String REST_URL_PREFIX = "http://MICROSERVICECLOUD-DEPT";

    /**
     * 使用 使用restTemplate访问restful接口非常的简单粗暴无脑。 (url, requestMap,
     * ResponseBean.class)这三个参数分别代表 REST请求地址、请求参数、HTTP响应转换被转换成的对象类型。
     */
    @Autowired
    private RestTemplate restTemplate;

    @RequestMapping(value = "/consumer/dept/add")
    public boolean add(Dept dept) {
        return restTemplate.postForObject(REST_URL_PREFIX + "/dept/add", dept, Boolean.class);
    }

为了实现服务的高可用，我们可以将服务提供者集群。比如说，现在一个秒杀系统设计出来了，准备上线了。在11月11号时为了能够支持高并发，我们开多台机器来支持并发量。
在这里插入图片描述
现在想要这三个秒杀系统合理摊分用户的请求(专业来说就是负载均衡)，可能你会想到nginx。
其实SpringCloud也支持的负载均衡功能，只不过它是客户端的负载均衡，这个功能实现就是Ribbon！

负载均衡又区分了两种类型：

客户端负载均衡(Ribbon)

服务实例的清单在客户端，客户端进行负载均衡算法分配。
(从上面的知识我们已经知道了：客户端可以从Eureka Server中得到一份服务清单，在发送请求时通过负载均衡算法，在多个服务器之间选择一个进行访问)

服务端负载均衡(Nginx)

服务实例的清单在服务端，服务器进行负载均衡算法分配

所以，我们的图可以画成这样：
在这里插入图片描述

9. Ribbon细节

Ribbon是支持负载均衡，默认的负载均衡策略是轮询，我们也是可以根据自己实际的需求自定义负载均衡策略的。

@Configuration
public class MySelfRule
{
	@Bean
	public IRule myRule()
	{
		//return new RandomRule();// Ribbon默认是轮询，我自定义为随机
		//return new RoundRobinRule();// Ribbon默认是轮询，我自定义为随机
		
		return new RandomRule_ZY();// 我自定义为每台机器5次
	}
}

实现起来也很简单：继承AbstractLoadBalancerRule类，重写public Server choose(ILoadBalancer lb, Object key)即可。
SpringCloud 在CAP理论是选择了AP的，在Ribbon中还可以配置重试机制的(有兴趣的同学可以去搜搜)~

10. 引出Hystrix

到目前为止，我们的服务看起来好像挺好的了：能够根据服务名来远程调用其他的服务，可以实现客户端的负载均衡。
在这里插入图片描述
但是，如果我们在调用多个远程服务时，某个服务出现延迟，会怎么样？？

在高并发的情况下，由于单个服务的延迟，可能导致所有的请求都处于延迟状态，甚至在几秒钟就使服务处于负载饱和的状态，资源耗尽，直到不可用，最终导致这个分布式系统都不可用，这就是“雪崩”。
在这里插入图片描述
针对上述问题， Spring Cloud Hystrix实现了断路器、线程隔离等一系列服务保护功能。

Fallback(失败快速返回)：当某个服务单元发生故障（类似用电器发生短路）之后，通过断路器的故障监控（类似熔断保险丝）， 向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。
资源/依赖隔离(线程池隔离)：它会为每一个依赖服务创建一个独立的线程池，这样就算某个依赖服务出现延迟过高的情况，也只是对该依赖服务的调用产生影响，而不会拖慢其他的依赖服务。

Hystrix提供几个熔断关键参数：滑动窗口大小（20）、熔断器开关间隔（5s）、错误率（50%）

每当20个请求中，有50%失败时，熔断器就会打开，此时再调用此服务，将会直接返回失败，不再调远程服务。
直到5s钟之后，重新检测该触发条件，判断是否把熔断器关闭，或者继续打开。

Hystrix还有请求合并、请求缓存这样强大的功能.

11. Hystrix仪表盘

Hystrix仪表盘：它主要用来实时监控Hystrix的各项指标信息。通过Hystrix Dashboard反馈的实时信息，可以帮助我们快速发现系统中存在的问题，从而及时地采取应对措施。

启动时的页面：
在这里插入图片描述
监控单服务的页面：

我们现在的服务是这样的：

除了可以开启单个实例的监控页面之外，还有一个监控端点 /turbine.stream是对集群使用的。从端点的命名中，可以引入Turbine, 通过它来汇集监控信息，并将聚合后的信息提供给 HystrixDashboard 来集中展示和监控。
在这里插入图片描述

12. 引出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;
            }
        };
    }
}

调用：
在这里插入图片描述

13. 引出Zuul

基于上面的学习，我们现在的架构很可能会设计成这样：
在这里插入图片描述
这样的架构会有两个比较麻烦的问题：

路由规则与服务实例的维护问题：外层的负载均衡(nginx)需要维护所有的服务实例清单(图上的OpenService)
签名校验、登录校验冗余问题：为了保证对外服务的安全性，我们在服务端实现的微服务接口，往往都会有一定的权限校验机制，但我们的服务是独立的，我们不得不在这些应用中都实现这样一套校验逻辑，这就会造成校验逻辑的冗余。

还是画个图来理解一下吧：
在这里插入图片描述
每个服务都有自己的IP地址，Nginx想要正确请求转发到服务上，就必须维护着每个服务实例的地址！

更是灾难的是：这些服务实例的IP地址还有可能会变，服务之间的划分也很可能会变。

http://123.123.123.123
http://123.123.123.124
http://123.123.123.125
http://123.123.123.126
http://123.123.123.127

购物车和订单模块都需要用户登录了才可以正常访问，基于现在的架构，只能在购物车和订单模块都编写校验逻辑，这无疑是冗余的代码。
为了解决上面这些常见的架构问题，API网关的概念应运而生。在SpringCloud中了提供了基于Netfl ix Zuul实现的API网关组件Spring Cloud Zuul。

Spring Cloud Zuul是这样解决上述两个问题的：

SpringCloud Zuul通过与SpringCloud Eureka进行整合，将自身注册为Eureka服务治理下的应用，同时从Eureka中获得了所有其他微服务的实例信息。外层调用都必须通过API网关，使得将维护服务实例的工作交给了服务治理框架自动完成。
在API网关服务上进行统一调用来对微服务接口做前置过滤，以实现对微服务接口的拦截和校验。

Zuul天生就拥有线程隔离和断路器的自我保护功能，以及对服务调用的客户端负载均衡功能。也就是说：Zuul也是支持Hystrix和Ribbon。

关于Zuul还有很多知识点：

路由匹配(动态路由)
过滤器实现(动态过滤器)
默认会过滤掉Cookie与敏感的HTTP头信息(额外配置)

14. 可能对Zuul的疑问

Zuul支持Ribbon和Hystrix，也能够实现客户端的负载均衡。我们的Feign不也是实现客户端的负载均衡和Hystrix的吗？既然Zuul已经能够实现了，那我们的Feign还有必要吗？
在这里插入图片描述
或者可以这样理解：

zuul是对外暴露的唯一接口相当于路由的是controller的请求，而Ribbonhe和Fegin路由了service的请求
zuul做最外层请求的负载均衡，而Ribbon和Fegin做的是系统内部各个微服务的service的调用的负载均衡

有了Zuul，还需要Nginx吗？他俩可以一起使用吗？

我的理解：Zuul和Nginx是可以一起使用的(毕竟我们的Zuul也是可以搭成集群来实现高可用的)，要不要一起使用得看架构的复杂度了(业务)~~~

15. 引出SpringCloud Config

随着业务的扩展，我们的服务会越来越多，越来越多。每个服务都有自己的配置文件。
既然是配置文件，给我们配置的东西，那难免会有些改动的。
比如我们的Demo中，每个服务都写上相同的配置文件。万一我们有一天，配置文件中的密码需要更换了，那就得三个都要重新更改。
在这里插入图片描述

在分布式系统中，某一个基础服务信息变更，都很可能会引起一系列的更新和重启

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

简单来说，使用Spring Cloud Config就是将配置文件放到统一的位置管理(比如GitHub)，客户端通过接口去获取这些配置文件。
在GitHub上修改了某个配置文件，应用加载的就是修改后的配置文件。

SpringCloud Config其他的知识：
在SpringCloud Config的服务端，对于配置仓库的默认实现采用了Git。
配置文件内的信息加密和解密
修改了配置文件，希望不用重启来动态刷新配置，配合Spring Cloud Bus 使用~

使用SpringCloud Config可能的疑问：application.yml和 bootstrap.yml区别

16. 消息总线： Spring Cloud Bus

Spring Cloud Bus 将分布式的节点用轻量的消息代理连接起来。它可以用于广播配置文件的更改或者服务之间的通讯，也可以用于监控。本文要讲述的是用Spring Cloud Bus实现通知微服务架构的配置文件的更改。
在这里插入图片描述

17. 消息驱动的微服务： Spring Cloud Stream

Spring Cloud Stream是创建消息驱动微服务应用的框架。Spring Cloud Stream是基于Spring Boot创建，用来建立单独的／工业级spring应用，使用spring integration提供与消息代理之间的连接。数据流操作开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。

一个业务会牵扯到多个任务，任务之间是通过事件触发的，这就是Spring Cloud stream要干的事了

18. 分布式服务跟踪： Spring Cloud Sleuth

Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 zipkin，你只需要在pom文件中引入相应的依赖即可。

Add sleuth to the classpath of a Spring Boot application (see below for Maven and Gradle examples), and you will see the correlation data being collected in logs, as long as you are logging requests.
------ 摘自官网

服务追踪分析
微服务架构上通过业务来划分服务的，通过REST调用，对外暴露的一个接口，可能需要很多个服务协同才能完成这个接口功能，如果链路上任何一个服务出现问题或者网络超时，都会形成导致接口调用失败。随着业务的不断扩张，服务之间互相调用会越来越复杂。
在这里插入图片描述
随着服务的越来越多，对调用链的分析会越来越复杂。它们之间的调用关系也许如下：

术语

Span：基本工作单元，例如，在一个新建的span中发送一个RPC等同于发送一个回应请求给RPC，span通过一个64位ID唯一标识，trace以另一个64位ID表示，span还有其他数据信息，比如摘要、时间戳事件、关键值注释(tags)、span的ID、以及进度ID(通常是IP地址)
** span在不断的启动和停止，同时记录了时间信息，当你创建了一个span，你必须在未来的某个时刻停止它。
Trace：一系列spans组成的一个树状结构，例如，如果你正在跑一个分布式大数据工程，你可能需要创建一个trace。
Annotation：用来及时记录一个事件的存在，一些核心annotations用来定义一个请求的开始和结束
** cs - Client Sent -客户端发起一个请求，这个annotion描述了这个span的开始
** sr - Server Received -服务端获得请求并准备开始处理它，如果将其sr减去cs时间戳便可得到网络延迟
** ss - Server Sent -注解表明请求处理的完成(当请求返回客户端)，如果ss减去sr时间戳便可得到服务端需要的处理请求时间
** cr - Client Received -表明span的结束，客户端成功接收到服务端的回复，如果cr减去cs时间戳便可得到客户端从服务端获取回复的所有所需时间

将Span和Trace在一个系统中使用Zipkin注解的过程图形化：
在这里插入图片描述

总结

本文主要写了SpringCloud的基础知识，希望大家看完能有所帮助~

参考

https://juejin.im/post/5b83466b6fb9a019b421cecc

https://spring.io/projects/spring-cloud#overview

https://github.com/macrozheng/springcloud-learning

https://blog.csdn.net/forezp/article/details/70148833

https://blog.csdn.net/valada/article/details/80892573

http://www.ityouknow.com/springcloud/2017/05/01/simple-springcloud.html

AI架构师易筋

关注

3
点赞
踩
8

收藏

觉得还不错? 一键收藏
0
评论
【易实战】SpringCloud Greenwich架构概览深度详解

说明在远古时代算盘可以解决算力问题，在20世纪初期电脑单机还是少数精英的特权，在21世纪互联网风起云涌超级单机服务器不仅贵也应对不了海啸般的流量，集群、分布式系统来解围，SpringCloud微服务作为解决方案的佼佼者出现了。Spring Cloud 是一系列框架的有序集合，它利用 Spring Boot 的开发便利性简化了分布式系统的开发，比如服务发现、服务网关、服务路由、链路追踪等。Spr...
复制链接

扫一扫