Spring Cloud

SZH勿忘初心

已于 2022-02-20 20:34:31 修改

阅读量693

点赞数

分类专栏：笔记文章标签： spring cloud

于 2021-11-30 10:31:20 首次发布

本文链接：https://blog.csdn.net/qq_39182939/article/details/121619904

版权

笔记专栏收录该内容

3 篇文章 0 订阅

订阅专栏

架构发展

1.单体应用架构
项⽬所有的功能模块都放在⼀个⼯程中编码、编译、打包并且部署在⼀个Tomcat容器中的架构模式就是单体应⽤架构，这样的架构既简单实⽤、便于维护，成本⼜低。

优点：

项⽬前期开发节奏快，团队成员少的时候能够快速迭代
架构简单：MVC架构，只需要借助IDE开发、调试即可
易于测试：只需要通过单元测试或者浏览器完成
易于部署：打包成单⼀可执⾏的jar或者打成war包放到容器内启动

缺点：

随着不断的功能迭代，单个项⽬过⼤，代码杂乱，耦合严重，开发团队逐渐壮⼤以后，沟通成本变⾼，如：代码从编译到启动耗时达到 3-5 分钟
新增业务困难：在已经乱如麻的系统中增加新业务，维护旧功能，⼀脚踩进去全是不可预测的问题。新⼈来了以后很难接⼿任务，学习成本⾼，需要⼤概⼀周时间才能上⼿开发
核⼼业务与边缘业务混合在⼀块，出现问题互相影响，如：⼀个临时活动流量猛涨，机器负载升⾼就会影响正常的业务服务

业务量上涨之后，单体应⽤架构进⼀步丰富变化，⽐如应⽤集群部署、使⽤Nginx进⾏负载均衡、增加缓存服务器、增加⽂件服务器、数据库集群并做读写分离等，通过以上措施增强应对⾼并发的能⼒、应对⼀定的复杂业务场景，但依然属于单体应⽤架构。

2.垂直应用架构

做垂直划分的原则：是基于现有的业务特性来做，拆分成不同业务的模块

优点：

系统拆分实现了流量分担，解决了并发问题
可以针对不同模块进⾏优化
⽅便⽔平扩展，负载均衡，容错率提⾼
系统间相互独⽴，互不影响，新的业务迭代时更加⾼效

缺点：

服务之间相互调⽤，如果某个服务的端⼝或者ip地址发⽣改变，调⽤的系统得⼿动改变
搭建集群之后，实现负载均衡⽐较复杂，如：内⽹负载，在迁移机器时会影响调⽤⽅的路由，导致线上故障
服务之间调⽤⽅式不统⼀，基于 httpclient 、 webservice ，接⼝协议不统⼀
服务监控不到位：除了依靠端⼝、进程的监控，调⽤的成功率、失败率、总耗时等等这些监控指标是没有的

3.SOA应用架构

SOA (Service-Oriented Architecture)，即⾯向服务的架构。根据实际业务，把系统拆分成合适的、独⽴部署的模块，模块之间相互独⽴（通过Webservice/Dubbo等技术进⾏通信）。
优点：

分布式、松耦合、扩展灵活、可重⽤。
缺点：
服务抽取粒度较⼤、服务调⽤⽅和提供⽅耦合度较⾼（接⼝耦合度）

4.微服务应用架构

微服务架构可以说是SOA架构的⼀种拓展，这种架构模式下它拆分粒度更⼩、服务更独⽴。把应⽤拆分成为⼀个个微⼩的服务，不同的服务可以使⽤不同的开发语⾔和存储，服务之间往往通过Restful等轻量级通信。微服务架构关键在于微⼩、独⽴、轻量级通信。

微服务架构设计的核⼼思想就是**“微”**，拆分的粒度相对⽐较⼩，这样的话单⼀职责、开发的耦合度就会降低、微小的功能可以独⽴部署扩展、灵活性强，升级改造影响范围小。

微服务架构

微服务架构的优点:

微服务架构和微服务微服务很小，便于特定业务功能的聚焦 A B C D
微服务很小，每个微服务都可以被⼀个⼩团队单独实施（开发、测试、部署上线、运维），团队合作⼀定程度解耦，便于实施敏捷开发
微服务很小，便于重⽤和模块之间的组装微服务很独⽴，那么不同的微服务可以使⽤不同的语⾔开发，松耦合微
服务架构下，我们更容易引入新技术
微服务架构下，我们可以更好的实现DevOps开发运维⼀体化；

微服务架构的缺点:

微服务架构下，分布式复杂难以管理，当服务数量增加，管理将越加复杂；
微服务架构下，分布式链路跟踪难等；

Spring Cloud 是什么

Spring Cloud其实是⼀套规范，是⼀套⽤于构建微服务架构的规范，⽽不是⼀个可以拿来即⽤的框架（所谓规范就是应该有哪些功能组件，然后组件之间怎么配合，共同完成什么事情）。
在这个规范之下第三⽅的Netflix公司开发了⼀些组件、Spring官⽅开发了⼀些框架/组件，包括第三⽅的阿⾥巴巴开发了⼀套框架/组件集合Spring Cloud Alibaba，这些才是Spring Cloud规范的实现。

Spring Cloud 解决什么问题:
Spring Cloud 规范及实现意图要解决的问题其实就是微服务架构实施过程中存在的⼀些问题，⽐如微服务架构中的服务注册发现问题、⽹络问题（⽐如熔断场景）、统⼀认证安全授权问题、负载均衡问题、链路追踪等问题。

Spring Cloud 核心组件:
Spring Cloud ⽣态圈中的组件，按照发展可以分为第⼀代 Spring Cloud组件和第⼆代 Spring Cloud组件。
在这里插入图片描述

第⼀代 Spring Cloud 核心组件

Eureka服务注册中心

Eureka 包含两个组件：Eureka Server 和 Eureka Client，Eureka Client是⼀个Java客户端，⽤于简化与Eureka Server的交互；Eureka Server提供服务发现的能⼒，各个微服务启动时，会通过Eureka Client向Eureka Server 进⾏注册⾃⼰的信息。
在这里插入图片描述

Ribbon负载均衡

负载均衡⼀般分为服务器端负载均衡和客户端负载均衡。
所谓服务器端负载均衡，⽐如Nginx、F5这些，请求到达服务器之后由这些负载均衡器根据⼀定的算法将请求路由到⽬标服务器处理。
所谓客户端负载均衡，⽐如我们要说的Ribbon，服务消费者客户端会有⼀个服务器地址列表，调⽤⽅在请求前通过⼀定的负载均衡算法选择⼀个服务器进⾏访问，负载均衡算法的执⾏是在请求客户端进⾏。
在这里插入图片描述

Hystrix熔断器

服务熔断:
熔断机制是应对雪崩效应的⼀种微服务链路保护机制。
服务降级:
服务降级⼀般是从整体考虑，就是当某个服务熔断之后，服务器将不再被调⽤，此刻客户端可以⾃⼰准备⼀个本地的fallback回调，返回⼀个缺省值。

Feign远程调用组件

Feign是Netflix开发的⼀个轻量级RESTful的HTTP服务客户端（⽤它来发起请求，远程调⽤的），是以Java接⼝注解的⽅式调⽤Http请求。
1.Feign对负载均衡的⽀持
2.Feign对熔断器的⽀持

GateWay⽹关组件
第⼀代 Spring Cloud （主要是 SCN）很多组件已经进⼊停更维护模式。

第⼆代 Spring Cloud 核心组件（SCA）

Alibaba 更进⼀步，搞出了Spring Cloud Alibaba（SCA），SCA 是由⼀些阿⾥巴巴的开源组件和云产品组成的，2018年，Spring Cloud Alibaba 正式⼊住了 SpringCloud 官⽅孵化器。

Nacos（服务注册中心、配置中心）
Sentinel哨兵（服务的熔断降级、限流等）
Dubbo RPC/LB
Seata分布式事务解决⽅案

Nacos 服务注册和配置中心

Nacos （Dynamic Naming and Configuration Service）是阿⾥巴巴开源的⼀个针对微服务架构中服务发现、配置管理和服务管理平台。

官网：https://nacos.io/zh-cn/

Nacos 单例服务部署:

1.启动命令:sh startup.sh -m standalone
2.访问nacos管理界⾯：http://127.0.0.1:8848/nacos/#/login（默认端⼝8848，账号和密码 nacos/nacos）

Nacos就是注册中心+配置中心的组合（Nacos=Eureka+Config+Bus）

Sentinel 分布式系统的流量防卫兵

1.Sentinel 介绍:
Sentinel是⼀个⾯向云原⽣微服务的流量控制、熔断降级组件。
替代Hystrix，针对问题：服务雪崩、服务降级、服务熔断、服务限流。

Sentinel：
1）独⽴可部署Dashboard/控制台组件
2）减少代码开发，通过UI界⾯配置即可完成细粒度控制（⾃动投递微服务）
在这里插入图片描述
Sentinel 分为两个部分:

核心库：（Java 客户端）不依赖任何框架/库，能够运⾏于所有 Java 运⾏时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的⽀持。
控制台：（Dashboard）基于 Spring Boot 开发，打包后可以直接运⾏，不需要额外的 Tomcat 等应⽤容器。

Sentinel 部署
下载地址：https://github.com/alibaba/Sentinel/releases
使⽤v1.7.1启动：java -jar sentinel-dashboard-1.7.1.jar &
⽤户名/密码：sentinel/sentinel

服务改造

1.pom.xml引⼊依赖

<!--sentinel 核⼼环境 依赖-->
<dependency> 
	<groupId>com.alibaba.cloud</groupId> 
	<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

2.application.yml修改（配置sentinel dashboard，暴露断点依然要有，删除原有hystrix配置，删除原有OpenFeign的降级配置）

server:
  port: 8099
spring:
  application:
    name: lagou-service-autodeliver
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848,127.0.0.1:8849,127.0.0.1:8850

    sentinel:
      transport:
        dashboard: 127.0.0.1:8080 # sentinel dashboard/console 地址
        port: 8719   #  sentinel会在该端口启动http server，那么这样的话，控制台定义的一些限流等规则才能发送传递过来，
                      #如果8719端口被占用，那么会依次+1
      # Sentinel Nacos数据源配置，Nacos中的规则会自动同步到sentinel流控规则中
      datasource:
        # 自定义的流控规则数据源名称
        flow:
          nacos:
            server-addr: ${spring.cloud.nacos.discovery.server-addr}
            data-id: ${spring.application.name}-flow-rules
            groupId: DEFAULT_GROUP
            data-type: json
            rule-type: flow  # 类型来自RuleType类
        # 自定义的降级规则数据源名称
        degrade:
          nacos:
            server-addr: ${spring.cloud.nacos.discovery.server-addr}
            data-id: ${spring.application.name}-degrade-rules
            groupId: DEFAULT_GROUP
            data-type: json
            rule-type: degrade  # 类型来自RuleType类
  main:
    allow-bean-definition-overriding: true
management:
  endpoints:
    web:
      exposure:
        include: "*"
  # 暴露健康接口的细节
  endpoint:
    health:
      show-details: always
dubbo:
  registry:
    # 挂载到 Spring Cloud 注册中心
    address: spring-cloud://localhost
  cloud:
    # 订阅服务提供方的应用列表，订阅多个服务提供者使用 "," 连接
    subscribed-services: lagou-service-resume

QPS：（每秒钟请求数量）

Sentinel 自定义兜底逻辑

@SentinelResource注解类似于Hystrix中的@HystrixCommand注解。

@RestController
@RequestMapping("/autodeliver")
public class AutodeliverController {


    @Reference
    private ResumeService resumeService;

	/** 
	* @SentinelResource value：定义资源名 
	* blockHandlerClass：指定Sentinel规则异常兜底逻辑所在class类 
	* blockHandler：指定Sentinel规则异常兜底逻辑具体哪个⽅法 
	* fallbackClass：指定Java运⾏时异常兜底逻辑所在class类⾃定义兜底逻辑类注意：兜底类中的⽅法为static静态⽅法 
	* fallback：指定Java运⾏时异常兜底逻辑具体哪个⽅法 
	* */
    @GetMapping("/checkState/{userId}")
    @SentinelResource(value = "findResumeOpenState",blockHandlerClass = SentinelHandlersClass.class,
            blockHandler = "handleException",fallbackClass = SentinelHandlersClass.class,fallback = "handleError")
    public Integer findResumeOpenState(@PathVariable Long userId) {
        return resumeService.findDefaultResumeByUserId(userId);
    }

}

import com.alibaba.csp.sentinel.slots.block.BlockException;

public class SentinelHandlersClass {

    // 整体要求和当时Hystrix一样，这里还需要在形参最后添加BlockException参数，用于接收异常
    // 注意：方法是静态的
    public static Integer handleException(Long userId, BlockException blockException) {
        return -100;
    }

    public static Integer handleError(Long userId) {
        return -500;
    }

}

Nacos + Sentinel + Dubbo

1.服务提供者
(1).pom⽂件添加spring cloud + dubbo整合的依赖，同时添加dubbo服务接⼝⼯程依赖：

<!--spring cloud alibaba dubbo 依赖--> 
<dependency> 
	<groupId>com.alibaba.cloud</groupId> 
	<artifactId>spring-cloud-starterdubbo</artifactId> 
</dependency> 
<dependency> 
	<groupId>com.alibaba.csp</groupId> 
	<artifactId>sentinel-apache-dubbo-adapter</artifactId> 
</dependency> 
<!--dubbo 服务接⼝依赖--> 
<dependency> 
	<groupId>com.lagou.edu</groupId> 
	<artifactId>lagou-service-dubbo-api</artifactId> 
	<version>1.0-SNAPSHOT</version> 
</dependency>

(2)在service的实现类上添加dubbo的@Service注解

(3).application.yml或者bootstrap.yml配置⽂件中添加dubbo配置：

dubbo: 
	scan: # dubbo 服务扫描基准包 
		base-packages: com.lagou.edu.service.impl 
	protocol: # dubbo 协议 
		name: dubbo # dubbo 协议端⼝（ -1 表示⾃增端⼝，从 20880 开始） 
		port: -1 
	registry: # 挂载到 Spring Cloud 的注册中⼼ 
		address: spring-cloud://localhost

(4).运⾏发布之后，会发现Nacos控制台已经有了服务注册信息,从元数据中可以看出,是dubbo注册上来的.
在这里插入图片描述

2.服务消费者

(1).pom.xml添加内容和服务提供者⼀样
(2).application.yml配置⽂件中添加dubbo相关内容：

dubbo: 
	registry: # 挂载到 Spring Cloud 注册中⼼ 
		address: spring-cloud://localhost 
	cloud: # 订阅服务提供⽅的应⽤列表，订阅多个服务提供者使⽤ "," 连接 
		subscribed-services: lagou-service-resume

(3).
在这里插入图片描述

SZH勿忘初心

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Spring Cloud

架构发展1.单体应用架构项⽬所有的功能模块都放在⼀个⼯程中编码、编译、打包并且部署在⼀个Tomcat容器中的架构模式就是单体应⽤架构，这样的架构既简单实⽤、便于维护，成本⼜低。优点：项⽬前期开发节奏快，团队成员少的时候能够快速迭代架构简单：MVC架构，只需要借助IDE开发、调试即可易于测试：只需要通过单元测试或者浏览器完成易于部署：打包成单⼀可执⾏的jar或者打成war包放到容器内启动缺点：随着不断的功能迭代，单个项⽬过⼤，代码杂乱，耦合严重，开发团队逐渐壮⼤以后，沟通成本变.
复制链接

扫一扫

专栏目录