SpringCloud学习笔记

最新推荐文章于 2022-08-07 17:13:31 发布

转载最新推荐文章于 2022-08-07 17:13:31 发布 · 260 阅读

文章标签：

#SpringCloud

本文介绍了从集中式架构到微服务架构的演进过程，详细解释了垂直拆分、水平拆分、分布式服务等概念，并重点阐述了微服务架构的特点及其关键技术组件。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

文章目录

系统架构演变
服务调用方式
SpringCloud
- SpringCloud简介
Eureka注册中心
- Eureka认识
- 原理图
负载均衡Ribbon

系统架构演变

集中式架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。

在这里插入图片描述

存在的问题：

代码耦合，开发维护困难
无法针对不同模块进行针对性优化
无法水平扩展
单点容错率低，并发能力差

垂直拆分：功能拆分

当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我们根据业务功能对系统进行拆分：

在这里插入图片描述

优点：

系统拆分实现了流量分担，解决了并发问题
可以针对不同模块进行优化
方便水平扩展，负载均衡，容错率提高

缺点：

系统间相互独立，会有很多重复开发工作，影响开发效率

水平拆分：分层：web service mapper

优点：

方便水平扩展
方便单独优化
解耦合
提高并发

缺点：

增加维护成本，重复开发

分布式服务

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式调用是关键。

在这里插入图片描述

优点：

将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率

缺点：

系统间耦合度变高，调用关系错综复杂，难以维护

流动计算架构（SOA）

SOA ：面向服务的架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键

在这里插入图片描述
以前出现了什么问题？

服务越来越多，需要管理每个服务的地址
调用关系错综复杂，难以理清依赖关系
服务过多，服务状态难以管理，无法根据服务情况动态管理

服务治理要做什么？

服务注册中心，实现服务自动注册和发现，无需人为记录服务地址
服务自动订阅，服务列表自动推送，服务调用透明化，无需关心依赖关系
动态监控服务状态监控报告，人为控制服务状态

缺点：

服务间会有依赖关系，一旦某个环节出错会影响较大
服务关系复杂，运维、测试部署困难，不符合DevOps思想

微服务

前面说的SOA，英文翻译过来是面向服务。微服务，似乎也是服务，都是对系统进行拆分。因此两者非常容易混淆，但其实却有一些差别：

微服务的特点：

单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责
微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。
面向服务：面向服务是说每个服务都要对外暴露Rest风格服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。
自治：自治是说服务间互相独立，互不干扰
- 团队独立：每个服务都是一个独立的开发团队，人数不能过多。
- 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉
- 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动段开发不同接口
- 数据库分离：每个服务都使用自己的数据源
- 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护

微服务结构图：

在这里插入图片描述

微服务架构框架

SpringCloud
dubbo(阿里巴巴)

服务调用方式

RPC和HTTP

无论是微服务还是SOA，都面临着服务间的远程调用。那么服务间的远程调用方式有哪些呢？

常见的远程调用方式有以下2种：

RPC：Remote Produce Call远程过程调用，类似的还有RMI。自定义数据格式，基于原生TCP通信，速度快，效率高。早期的webservice，现在热门的dubbo，都是RPC的典型代表
Http：http其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议，也可以用来进行远程服务调用。缺点是消息封装臃肿，优势是对服务的提供和调用方没有任何技术限定，自由灵活，更符合微服务理念。

现在热门的Rest风格，就可以通过http协议来实现。

如果你们公司全部采用Java技术栈，那么使用Dubbo作为微服务架构是一个不错的选择。

相反，如果公司的技术栈多样化，而且你更青睐Spring家族，那么SpringCloud搭建微服务是不二之选。在我们的项目中，我们会选择SpringCloud套件，因此我们会使用Http方式来实现服务间调用。

Http客户端工具

既然微服务选择了Http，那么我们就需要考虑自己来实现对请求和响应的处理。不过开源世界已经有很多的http客户端工具，能够帮助我们做这些事情，例如：

HttpClient
OKHttp
URLConnection

Spring的RestTemplate

Spring提供了一个RestTemplate模板工具类，对基于Http的客户端进行了封装，并且实现了对象与json的序列化和反序列化，非常方便。RestTemplate并没有限定Http的客户端类型，而是进行了抽象，目前常用的3种都有支持：

HttpClient
OkHttp
JDK原生的URLConnection（默认的）

首先在项目中注册一个RestTemplate对象，可以在启动类位置注册：

@SpringBootApplication
public class HttpDemoApplication {

	public static void main(String[] args) {
		SpringApplication.run(HttpDemoApplication.class, args);
	}

	@Bean
	public RestTemplate restTemplate() {
   
		return new RestTemplate();
	}
}

在测试类中直接@Autowired注入：

@RunWith(SpringRunner.class)
@SpringBootTest(classes = HttpDemoApplication.class)
public class HttpDemoApplicationTests {

	@Autowired
	private RestTemplate restTemplate;

	@Test
	public void httpGet() {
        // 调用springboot案例中的rest接口
		User user = this.restTemplate.getForObject("http://localhost/user/1", User.class);
		System.out.println(user);
	}
}

通过RestTemplate的getForObject()方法，传递url地址及实体类的字节码，RestTemplate会自动发起请求，接收响应，并且帮我们对响应结果进行反序列化。

SpringCloud

微服务是一种架构方式，最终肯定需要技术架构去实施。
SpringClound特点

后台硬：作为Spring家族的一员，有整个Spring全家桶靠山，背景十分强大。
技术强：Spring作为Java领域的前辈，功力深厚，有强力的技术团队支撑
使用方便：SpringBoot给我们开发带来的便利，而SpringCloud完全支持SpringBoot的开发，用很少的配置就能完成微服务框架的搭建

SpringCloud简介

SpringCloud是Spring旗下的项目之一，官网地址：http://projects.spring.io/spring-cloud/

Spring最擅长的就是集成，把世界上最好的框架拿过来，集成到自己的项目中。

SpringCloud也是一样，它将现在非常流行的一些技术整合到一起，实现了诸如：配置管理，服务发现，智能路由，负载均衡，熔断器，控制总线，集群状态等等功能。其主要涉及的组件包括：

Eureka：服务治理组件，包含服务注册中心，服务注册与发现机制的实现。（服务治理，服务注册/发现）
Zuul：网关组件，提供智能路由，访问过滤功能
Ribbon：客户端负载均衡的服务调用组件（客户端负载）
Feign：服务调用，给予Ribbon和Hystrix的声明式服务调用组件（声明式服务调用）
Hystrix：容错管理组件，实现断路器模式，帮助服务依赖中出现的延迟和为故障提供强大的容错能力。(熔断、断路器，容错)

架构图：

在这里插入图片描述

服务提供方和服务消费方都讲自己的功能或需求告知注册中心，进行匹配

Eureka注册中心

Eureka认识

首先我们来解决第一问题，服务的管理。

问题分析

服务提供者对外提供服务，需要对外暴露自己的地址。而consumer（调用者）需要记录服务提供者的地址。将来地址出现变更，还需要及时更新。这在服务较少的时候并不觉得有什么，但是在现在日益复杂的互联网环境，一个项目肯定会拆分出十几，甚至数十个微服务。此时如果还人为管理地址，不仅开发困难，将来测试、发布上线都会非常麻烦，这与DevOps的思想是背道而驰的。

网约车

这就好比是网约车出现以前，人们出门叫车只能叫出租车。一些私家车想做出租却没有资格，被称为黑车。而很多人想要约车，但是无奈出租车太少，不方便。私家车很多却不敢拦，而且满大街的车，谁知道哪个才是愿意载人的。一个想要，一个愿意给，就是缺少引子，缺乏管理啊。

此时滴滴这样的网约车平台出现了，所有想载客的私家车全部到滴滴注册，记录你的车型（服务类型），身份信息（联系方式）。这样提供服务的私家车，在滴滴那里都能找到，一目了然。

此时要叫车的人，只需要打开APP，输入你的目的地，选择车型（服务类型），滴滴自动安排一个符合需求的车到你面前，为你服务

Eureka做什么？

Eureka就好比是滴滴，负责管理、记录服务提供者的信息。服务调用者无需自己寻找服务，而是把自己的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你。

同时，服务提供方与Eureka之间通过“心跳”机制进行监控，当某个服务提供方出现问题，Eureka自然会把它从服务列表中剔除。

这就实现了服务的自动注册、发现、状态监控。

原理图

基本架构：

Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址
提供者：启动后向Eureka注册自己信息（地址，提供什么服务）
消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新
心跳(续约)：提供者定期通过http方式向Eureka刷新自己的状态

负载均衡Ribbon

服务提供者通过Eureka的DiscoveryClient来获取服务实例信息，然后获取ip和端口来访问。

但是实际环境中，我们往往会开启很多个服务提供者的集群。此时我们获取的服务列表中就会有多个，到底该访问哪一个呢？

一般这种情况下我们就需要编写负载均衡算法，在多个实例列表中进行选择。

不过Eureka中已经帮我们集成了负载均衡组件：Ribbon，简单修改代码即可使用。

什么是Ribbon：

1.高可用 dustdawn-eureka
10086 10087
 
2.心跳过期 dustdawn-service-provider
eureka：
    instance:
        lease-renewal-interval-in-seconds: 5 # 心跳时间
        lease-expiration-duration-in-seconds: 15 # 过期时间
 
3.拉取服务的间隔时间 dustdawn-service-consumer
eureka:
  client:
    registry-fetch-interval-seconds: 5
 
4.关闭自我保护，定期清除无效连接
eureka:
  server:
    eviction-interval-timer-in-ms: 5000 
    enable-self-preservation: false
 
ribbon: 负载均衡组件
    1.eureka集成了
    2.@LoadBalanced：开启负载均衡
    3.this.restTemplate.getForObject("http://service-provider/user/" + id, User.class);
     
hystrix：容错组件
    降级：检查每次请求，是否请求超时，或者连接池已满
        1.引入hystrix启动器
        2.熔断时间，默认1s， 6s
        3.在引导类上添加了一个注解：@EnableCircuitBreaker  @SpringCloudApplication
        4.定义熔断方法：局部（要和被熔断的方法返回值和参数列表一致）  全局（返回值类型要被熔断的方法一致，参数列表必须为空）
        5.@HystrixCommand(fallbackMethod="局部熔断方法名")：声明被熔断的方法
        6.@DefaultProperties(defaultFallback="全局熔断方法名")
    熔断：不再发送请求
        1.close：闭合状态，所有请求正常方法
        2.open：打开状态，所有请求都无法访问。如果在一定时间内容，失败的比例不小于50%或者次数不少于20次
        3.half open：半开状态，打开状态默认5s休眠期，在休眠期所有请求无法正常访问。过了休眠期会进入半开状态，放部分请求通过
         
feign
    1.引入openFeign启动器
    2.feign.hystrix.enable=true,开启feign的熔断功能
    3.在引导类上 @EnableFeignClients
    4.创建一个接口，在接口添加@FeignClient(value="服务id", fallback=实现类.class)
    5.在接口中定义一些方法，这些方法的书写方式跟之前controller类似
    6.创建了一个熔断类，实现feign接口，实现对应的方法，这些实现方法就是熔断方法
     
zuul
    1.引入zuul的启动器
    2.配置：
        zuul.routes.<路由名称>.path=/service-provider/**
        zuul.routes.<路由名称>.url=http://localhost:8082
         
        zuul.routes.<路由名称>.path=/service-provider/**
        zuul.routes.<路由名称>.serviceId=service-provider
         
        zuul.routes.服务名=/service-provider/**   *******************
         
        不用配置，默认就是服务id开头路径
         
    3.@EnableZuulProxy
     
    过滤器：
        创建一个类继承ZuulFilter基类
        重写四个方法
            filterType：pre route post error
            filterOrder：返回值越小优先级越高
            shouldFilter：是否执行run方法。true执行
            run：具体的拦截逻辑