本站消息

站长简介/公众号

出租广告位,需要合作请联系站长

我是小豆丁

573

文章

272860

访问

+关注

分类

暂无分类

日期归档

2023-05(1)

2023-06(2)

小白新手SpringCloud开发简单总结（一）-SpringCloud概念

发布于2021-05-29 21:52 阅读(845) 评论(0) 点赞(4) 收藏(4)

1. SpringCloud之 Eureka

（1）两个组件

（2）治理机制

（3）小结

2.SpringCloud之RestTemplate

5.SpringCloud之Hystrix

前言

拓展下自己的知识库。

一几个常见概念

1.集群

为了更高的效率，通过多台计算机完成同一个工作，这些计算机运行的内容完全一致。本来是用一台计算机来处理Client的访问，转换成多台计算机同时在处理这些访问。如果其中一台出现问题，其他的仍然可以起作用。

该集群系统中的每台计算机成为一个节点。通过局域网或者其他可能的方式连接。

总结为：同一个业务部署到多台服务器上，不同的服务器运行的是相同的代码。

是一种物理形态。通过负载均衡设备共同对Client提供服务。

2.分布式

将一个网站系统分为不同独立的模块，每个模块完成独立的功能，按模块访问量高低配置不同性能的服务器，合理利用资源。在使用的时候将这些模块组合成一个系统。

总结为：一个业务拆成多个独立的子业务，部署在不同的服务器，不同的服务器运行不同的代码。

是一种工作方式。解决高并发问题。

3.SOA

一个业务拆分成多个组件，每个组件相互独立，通过组合实现业务流程。

更注重的是前端、后端、数据库等的划分。

4.微服务

更注重的根据业务拆分，每个子业务完成一定的功能。

二 SpringCloud

在分布式和微服务的概念中，会把一个业务拆分成多个子业务，通过将这些子业务组合来完成功能。而拆分之后就会各种各样的问题，所以SpringCloud就是为了解决这些问题。

微服务框架。对优秀组件进行整合。基于Springboot进行构建各种服务（SpringCloud主要侧重的服务治理，里面的各种服务都是有SpringBoot开发）。

构建服务的过程基础功能：

（1）服务发现注册 Eureka
（2）客户端负载均衡 Ribbon
（3）服务器熔断器 Hystrix
（4）声明式服务调用 Feign
（5）API网关服务 Zuul
（6）分布式配置中心 Config

另外还有一些高级功能如消息总线 Bus、消息驱动的微服务 Stream、分布式服务跟踪 Sleuth。

1. SpringCloud之 Eureka

服务的发现和注册，是一个服务治理框架。用于解决每个服务之间的远程调用问题。

传统的服务之间调用都是通过IP地址来调用，而Eureka是通过服务名来实现调用。简单的理解梳理下Eureka的思想：

将每个服务都注册到服务注册中心；
每个服务可以拿到这个服务注册中心的注册清单，在这个服务清单中会有服务名和IP地址之间的关系；
每个服务可以通过服务名来调用，最后通过服务名找到对应的IP地址（IP地址会变，但是服务名不会变）。

（1）两个组件

Eureka主要有两个组件组成：Eureka Server和Eureka Client。

Eureka Server又称为服务注册中心。专门用于注册其他服务，维护服务实例，不需要检索服务。本身也是一个服务。一般情况下在application.properties对该服务配置如下：


#false:不会向注册中心注册自己
register-with-eureka=false
#false:表示该服务为注册中心
fetch-registry=false

Eureka Client又分为服务消费者和服务提供者。一个服务即可以是服务消费者也可以是服务提供者。注意下面的几个问题点：

1）如果是单纯的消费者，可以不对外提供服务，无需注册到Eureka注册中心（即register-with-eureka设置为false），但是可以获取到服务注册中心的注册清单；
2）服务提供者必须注册到注册中心才可以对外提供功能。

（2）治理机制

该治理机制主要服务提供者、服务消费者以及服务注册中心三者相互配合，实现服务治理。

Eureka Client端：

服务提供者的主要作用就是对外提供服务。主要功能如下：

1）服务注册Register：服务提供者启动的时候，就会通过发送REST请求将自己的一些元数据（如IP地址、端口号、运行状况指示符URL等信息）注册到服务注册中心Eureka Server；
2）服务续约Renew：在完成注册服务之后，服务提供者每隔一定时间（默认为30s）发送心跳来续约，告诉服务注册中心Eureka Server该服务提供者还存活；当Eureka Server在规定时间（默认90s）没有收到续约信息，就会将该服务实例从注册表中剔除；
3）服务下线Cancel：当该服务实例正常关闭时，会触发一个服务下线的REST请求发送给服务注册中心Eureka Server，告知下线。服务注册中心Eureka Server就会从注册表中将该实例删除。该下线请求需要服务提供者主动调用（代码为DiscoveryMananger.getInstance().shutdownComponent()）。

服务消费者的主要作用就是获取注册列表信息，找到对应的服务，使用服务。主要需要功能如下：

1）获取服务Fetch：服务消费者启动的时候，会发送REST请求给到服务注册中心Eureka Server，获取服务注册清单，缓存在本地，该注册清单信息定期（默认30s）会更新。
2）调用服务：服务消费者获取到服务清单，通过服务名获取到该服务的实例和实例的元数据（里面含有IP地址），从而调用到服务提供者

Eureka Server端

服务注册中心的主要作用：服务提供者去注册服务，而服务消费者去寻找服务提供者。

1）服务剔除Eviction：如果服务注册清单中的服务实例超过规定时间（默认为90s）没有接收到续约，则服务注册中心Eureka Server就会将该服务从服务注册列表中剔除；
2）自我保护：通常由于网络不稳在15分钟内心跳失败的比例超过85%，那么Eureka Server就会将当前的实例注册信息保护起来，让这些实例不会过期。

感觉这个过程和Android的系统服务的概念差不多：

1）system进程的各种系统服务如AMS、WMS等，主要是提供服务，对比服务提供者；
2）Client进程通过远程调用来访问这些系统服务，对比服务消费者；
3）ServiceManager用来注册和查询服务，对比服务注册中心

后面在去学习在代码中怎么去设置。

（3）小结

1.Eureka为服务治理框架。负责对服务进行注册和查找。分为Client和Server，但都是一个独立的服务。
2.Client分为服务消费者和服务提供者。
3.Server为服务注册中心，提供服务的注册和查找；同时还会剔除没有续约的服务以及自我保护。
4.在服务提供者启动的时候，会向服务注册中心将自身的元数据注册到服务注册中心；定时进行发送续约以及在该服务下线的时候，及时通知服务注册中心将该服务从服务注册清单中清除。
5.在服务消费者启动的时候，会向服务注册中心请求一个服务注册清单，然后从服务注册清单中根据服务名查找到对应服务的实例和元数据。
6.服务提供者和服务注册中心通过周期性的发送心跳来续约。

2.SpringCloud之RestTemplate

Eureka为服务治理框架，通过服务名就可以获取到对应的服务实例以及服务的IP地址，那么这些服务实例之间的远程调用不需要手动创建HttpClient，而是之间通过Spring封装的RestTemplate。在Eureka中的续约、注册以及查找都是使用的RestTemplate。

RestTemplate就是一个Http请求工具。提供了常见的REST请求方案的模版。简单的看一个方法：

（1）GET请求

GET请求的一些方法如下：

第一个参数：REST请求的url地址；
第二个参数：请求参数；
第三个参数：Http响应转换成的对象类型

（2）POST请求

POST请求的一些方法如下：

方法参数含义同GET请求。

其他方法等用的时候在具体去看，现在先简单的了解下。

3.SpringCloud之Ribbon

为了能够使整个系统的高可用，前面在一几个常见概念中的几个概念介绍中，可以知道我们需要将服务提供者集群，这样就可以在不同的服务器中运行相同的代码来解决分担同一时间对该功能的访问。

如果没有负载均衡，就可能会出现仅有一台服务器来处理这些访问，而其他的服务器并没有起作用，造成了资源没有合理利用。所谓的负载均衡就是让不同的服务器能够合理分摊用户的请求，而如何解决这个服务提供者集群的负载均衡，那就是Ribbon。

（1）Ribbon概念

Ribbon就是为了解决Eureka的Client的负载均衡的问题。Ribbon工作原理：Client的服务消费者从Eureka Server服务注册中心获取服务注册清单，通过负载均衡算法在多个服务提供者之间选一个在进行发送请求。

（2）Ribbon的负载均衡算法

Ribbon默认的策略为轮询，即RoundBobinRule。该策略就是经过一轮没有找到可用的provider，其最多轮询10轮。若最终没有找到，则返回null。

当然也可以设置其他的负载均衡算法，在配置文件中修改NFLoadBalancerRuleClassName的值即可，其他算法如下：

1）RadomRule：随机策略。从所有可用的provider中随机选择一个；
2）RetryRule：重试策略。先按照RoundBobinRule策略获取provider，若获取失败，则指定的时间内重试。默认为500ms。
3）BestAvailableRule：最低并发策略。逐个考察provider，若其断路器打开，则忽略。在选择其中并发连接最低的provider。
4）AvailabilityFilteringRule：可用过滤策略。过滤一直连接失败并标记为circuit tripped的provider以及过滤那些高并发连接的provider；
5）ResponseTimeWeightedRule：响应时间加权策略。根据响应时间分配加权权重。响应时间越长，权重越低，被选择到的概率越低；
6）ZoneAvoidanceRule：区域权衡策略。综合判断provider所在区域的性能和可用性轮询选择。

也支持自定义负载均衡算法，需要实现IRule接口。

（3）与Nginx区别

Nginx是集中式的负载均衡器。就是将所有的请求集中起来在进行负载均衡。也就是所有的请求先进入负载均衡器，然后在分配给对应的服务；而Ribbon是先在负载均衡在发送请求给到对应的服务提供者。区别如图：

从图中可以看出：Nginx会接收所有的请求，通过负载均衡调度，找到可用的服务器；而Ribbon会在发出请求之前就知道该请求具体发向哪台服务器，然后直接将该请求发向对应的服务器。

4.SpringCloud之Feign

通过Eureka可以让服务消费者根据服务名找到对应的服务器实现远程调用，在Eureka中通过RestTemplate封装Http实现远程调用服务。通过Ribbon可以实现Client的负载均衡。而Feign进行了声明式、模板化，将上面的两个流程进行简化：

1）只需要创建一个接口并注解的方式来配置它，就可以完成服务提供者的接口绑定；
2）集成Ribbon，利用Ribbon维护服务列表，通过轮询方式实现Client的负载均衡，不需要额外声明Ribbon

该Feign还整合了后面要介绍的Hystrix。

5.SpringCloud之Hystrix

前面通过Ribbon解决集群中的负载均衡问题，但是在网络原因或者系统本身问题，导致服务出现异常，不能及时返回信息。如果这个时候有大量的访问进入，会使服务器处于负载保护状态，造成系统瘫痪。服务与服务之间又有相互依赖关系，从而引起整个微服务系统的雪崩效应。那么就出现了“救星”Hystrix。

Hystrix称为断路器。能够保护系统，控制故障范围。具有下面的特点：

1）请求熔断：一旦出现服务不可用，断路器会直接断开请求链，避免发送大量无效请求影响系统的吞吐量，具有自我检测并恢复的能力；
2）依赖隔离：通过线程池实现资源隔离。为每个依赖服务创建一个独立的线程池，如果某个依赖服务出现延迟过高，只会对该依赖服务的调用产生影响，不会影响到其他依赖服务；
3）服务降级：给定某个操作实现一个fallback方法，当请求服务出现异常的时候，可以通过该fallback返回默认值或者缓存，并且通知后面的请求该服务不可用。
4）请求缓存：会缓存之前的请求，再来相同的请求的时候，而是把缓存内容返回给当前请求。
5）请求合并：多次相同的请求可以合并成一个请求，最后同时处理一次数据库

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

1）每当20个请求中，有50%失败，断路器会自动打开，若在调用该服务，会直接返回失败；
2）5s之后，会重新检测该触发条件，判断断路器是否关闭还是继续打开。

6.SpringCloud之Zuul

在微服务框架中，后端服务通常不会直接暴露给web前端、移动端等，而是通过一个API网关根据请求的url，进行签名校验、登录校验等冗余问题，然后路由到对应的服务。而Zuul具有API网关、路由负载均衡等作用。

通过与Eureka进行整合，将自身注册为Eureka下的应用，同时从Eureka中获取到所有服务的实例。外层调用必须通过API网关，而服务实例的维护还是有Eureka完成。实现对微服务接口进行前置过滤，实现拦截和检验。

Zuul本身拥有线程隔离和断路器的自我保护功能，以及对Client负载均衡功能。支持Hystrix和Ribbon。

（1）与Feign区别

前面的Feign也有Hystrix实现断路器和Ribbon实现Client的负载均衡，和Zuul有什么区别呢？

Zuul是对外暴露的唯一接口，相当于路由的是controller的请求；而Ribbon和Feign路由的是选择哪个服务提供者去请求；
Zuul是做外层的请求的负载均衡；而Ribbon和Feign是对微服务系统的服务提供者的负载均衡。

所以Zuul更偏向于web应用层调用方的路由以及负载均衡；而Ribbon和Feign是针对于业务层的微服务系统。

7.SpringCloud之Config

随着业务增多，就会有存在很多微服务，那么每个服务都会有一个配置文件。如果每个服务分别维护一个配置文件，会造成如果一个修改的话，要对所有的服务的配置文件都进行修改。那么就有了Config，通过把配置文件放在统一的位置进行管理。

Config主要包括两方面的配置：Server主要配置文件的存储、以接口的形式将配置文件的内容提供出去；而Client通过接口获取数据，初始化应用。

三总结

主要还是学习了SpringCloud的一些基本概念，里面有些概念还有点模糊，后面逐渐再去学习深化，第一天还是先简单的理解一些基本概念：

1.集群就是将一个业务系统部署到不同的服务器中，这些服务器运行是相同代码。
2.分布式就是将一个业务拆分成多个子业务，每个子业务相互独立，然后部署到不同的服务器，这些服务器运行的代码不同。
3.SOA侧重是将系统划分前段、后端、数据库等，是系统垂直上的划分；
4.微服务侧重的是对系统业务的拆分，是系统横向上的划分
5.SpringCloud是一个微服务框架，基于Springboot对一些优秀的组件进行整合。
6.SpringCloud在构建服务的时候包括几个基本功能：
（1）Eureka：服务的发现与注册。是一个服务治理框架，解决的是服务之间的远程调用问题；
Eureka分为Client和Server；
Client分为服务消费者和服务提供者；
Server称为服务注册中心，主要是让服务提供者注册服务、消费者查询服务以及对服务的剔除与自我保护；
服务提供者向服务注册中心注册、续租以及下线服务；
服务消费者主要是从服务注册中心获取服务注册列表，根据服务名找到对应的服务实例和服务元数据，从而使用该服务；
服务提供者与Server之间通过发送心跳来续约。
（2）RestTemplate：实现服务之间的远程调用。提供了常见的REST请求方案的模版
（3）Ribbon：Client的负载均衡
服务消费者从Eureka的服务注册中心获取到服务清单列表，然后通过负载均衡算法找到适合的服务提供者发送请求；
默认的为轮询策略；
与Nginx的区别在于：Nginx是将请求进行负载均衡之后，找到对应的服务器；而Ribbon是在发出请求之前负载均衡，找到具体的服务器，然后发送将请求发给对应的服务器；
（4）Feign：对Eureka、Ribbon以及Hystrix的声明化、模版化。
只需要创建一个接口并且通过注解方式配置它，就可以完成服务提供者接口的绑定；
已集成Ribbon，无需额外声明
（5）Hystrix：断路器。保护系统，控制故障范围。
一旦出现服务不可用，即可开启断路器，直接断开请求；以后再来该请求的时候，直接返回失败
也可以在返回一些缓存信息
会自动检测是否关闭断路器和继续打开断路器功能
（6）Zuul：API网关、路由负载均衡等作用
微服务框架中，后端服务不会直接暴露给Client，而是通过API网关根据请求的url，进行签名检验、登录校验等冗余问题之后，在路由到对应服务中；
Zuul本身具有路由和断路器、负载均衡功能，但是是针对web应用调用方的相应功能；相比较Ribbon和Hystrix是针对微服务的负载均衡以及断路器