Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署。
必要说明
注意事项
SpringCloud2和SpringCloud3(现命名版本号为2023.x.x)并不兼容,这意味着如果您的项目最开始是基于V2版本构建的,如果要升级到V3版本,除了更改SpringCloud版本号,还要更改很多其它集成插件的版本。
SpringCloud3要求JDK最低版本为OpenJDK 17。
本专题环境
- Springboot starter 3.2.4
- SpringCloud 2023.0.1
- Alibaba SpringCloud 2023.0.1
- OpenJDK 17.0.11
- Intellij Idea 2024.1.1
- Mysql 8.0.52
上述spring、springboot、springboot starter、springcloud、jdk存在版本兼容关系,详细可查官网,同样的alibaba springcloud也与jdk等有对应关系。
帮助文档
- https://spring.io/projects/spring-cloud
- https://github.com/alibaba/spring-cloud-alibaba
- https://github.com/spring-cloud/spring-cloud-release/releases/tag/v2023.0.1
生态体系
整体架构
- Spring体系中存在下面这样的演进依赖关系:Spring -> Spring Boot > Spring Cloud ;
- Spring Boot可以离开Spring Cloud独立使用开发项目,但是Spring Cloud离不开Spring Boot;
- Spring Boot专注于快速、方便集成的单个个体微服务,Spring Cloud是关注全局的服务治理框架;
核心项目
-
Spring Cloud Config :集中配置管理工具,分布式系统中统一的外部配置管理,默认使用Git来存储配置,可以支持客户端配置的刷新及加密、解密操作。
-
springcloud netflix:Netflix OSS 开源组件集成,包括Eureka、Hystrix、Ribbon、Feign、Zuul等核心组件。主要用于微服务架构中的服务治理
- Eureka:服务治理组件,包括服务端的注册中心和客户端的服务发现机制;
- Ribbon:负载均衡的服务调用组件,具有多种负载均衡调用策略;
- Hystrix:服务容错组件,实现了断路器模式,为依赖服务的出错和延迟提供了容错能力;
- Feign:基于Ribbon和Hystrix的声明式服务调用组件;
- Zuul:API网关组件,对请求提供路由及过滤功能。
-
Spring Cloud Bus:用于传播集群状态变化的消息总线,使用轻量级消息代理链接分布式系统中的节点,可以用来动态刷新集群中的服务配置。
-
Spring Cloud Consul :基于Hashicorp Consul 的服务发现和配置管理。
-
Spring Cloud Security :安全工具包,对Zuul代理中的负载均衡OAuth2客户端及登录认证进行支持
-
Spring Cloud Sleuth :Spring Cloud应用程序的分布式请求链路跟踪,支持使用Zipkin、HTrace和基于日志(例如ELK)的跟踪。
-
Spring Cloud Stream :一个轻量级的事件驱动型微服务框架,用于快速构建可连接到外部系统的应用程序。使用 Apache Kafka 或 RabbitMQ 在 Spring Boot 应用程序之间发送和接收消息的简单声明性模型。
-
Spring Cloud Task :一个短期的微服务框架,用于快速构建执行有限量数据处理的应用程序。用于向 Spring Boot 应用程序添加功能性和非功能性功能的简单声明。
-
Spring Cloud Zookeeper :使用 Apache Zookeeper 进行服务发现和配置管理。
-
Spring Cloud Gateway :Spring Cloud Gateway 是一款基于 Spring Framework 和 Spring Boot 的智能可编程路由器。API网关组件,对请求提供路由及过滤功能。
-
Spring Cloud OpenFeign :基于Ribbon和Hystrix的声明式服务调用组件,可以动态创建基于Spring MVC注解的接口实现用于服务调用;
了解微服务
简单地说,微服务是系统架构上的一种设计风格,它的主旨是将一个原本独立的系统拆分成多个小型服务,这些小型服务都在各自独立的进程中运行,服务之间通过基于HTTP的RESTful API进行通信协作。被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建,并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础,所以这些微服务可以使用不同的语言来编写。
同时也带来了三个问题
- 运维新挑战,应用数量增多,运维过程需要大量的自动化,同时也需要开发能力来开发编排类的服务
- 接口一致性,接口和调用变了,但原业务逻辑没变
- 分布式的复杂性,由单进程变成了多进程,需要通信,而通信就会引出延迟、异步等问题
一般要实施时需要以下几种方式的配合
- 服务组件化
- 按业务组织团队,而不是职能
- 做产品的态度,而不是做项目的态度
- 更粗粒度的通信方式,比如RPC或MQ
- 去中心化治理,每个应用按需选择,而不是一刀切,这样有可能会浪费资源
- 去中心化数据管理,分区,分表等,使数据管理更细化
- 基础设施自动化,主要是测试和部署
- 容错和故障寻源的能力,要求强大的恢复和监控能力
- 演进式设计,但不允许带故障发布
基于以上理解,我们可以从微服务角度重新审视下SpringCloud相关的项目分类:
类目 | 作用 | 可选组件 |
---|---|---|
注册中心 | 注册中心主要用于服务治理,提供了服务的注册与发现功能,微服务架构中的服务可以注册到注册中心,也可以通过注册中心获取到其他服务的信息。 | Eureka、Consul、Nacos |
配置中心 | 配置中心主要用于提供统一的外部配置管理,微服务架构中的服务可以从配置中心获取配置信息,同时支持动态刷新配置。 | SpringCloud Config、Consul、Nacos |
服务网关 | API网关主要用于为微服务架构中的服务提供统一的外部访问入口,实现请求的路由与过滤功能。 | Zuul、Gateway |
服务负载均衡 | 微服务架构中有的服务会部署多个,Ribbon提供了服务间调用的客户端负载均衡功能,OpenFeign基于Ribbon提供了声明式的服务间调用,可简化开发流程,同样的他们需要注册中心的配合。 在功能上和Ribbon差不太多,只是不需要RestTemplate声明了。 | Ribbon、OpenFeign |
链路跟踪 | Spring Cloud应用程序的分布式请求链路跟踪,支持使用Zipkin、HTrace和基于日志(例如ELK)的跟踪。 | SpringCloud Sleuth |
熔断与限流 | 熔断与限流是对微服务架构中服务的一种保护措施,当系统中有故障发生时,可以防止故障的蔓延。 | Hystrix、Sentinel |
安全保护 | Spring Cloud Security 为构建安全的SpringBoot应用提供了一系列解决方案,结合Oauth2可以实现单点登录、服务安全保护等功能,可以很好地保护微服务架构中的服务。 | Spring Cloud Security |
监控中心 | 微服务架构中,当一次业务操作需要操作多个数据源或需要进行远程调用时就会产生分布式事务问题,Seata可以很好地解决该问题。 | Spring Boot Admin |
分布式事务 | 微服务架构中,当一次业务操作需要操作多个数据源或需要进行远程调用时就会产生分布式事务问题,Seata可以很好地解决该问题。 | Seata |
了解springCloud版本
Spring Cloud是一个由许多子项目组成的综合项目,各子项目有不同的发布节奏。 为了管理Spring Cloud与各子项目的版本依赖关系,发布了一个清单,其中包括了某个Spring Cloud版本对应的子项目版本。
Spring Cloud版本最开始采用了伦敦地铁站的名字而非版本号来命名,例如Angel是第一个版本,Brixton是第二个版本。 当Spring Cloud的发布内容积累到临界点或者一个重大BUG被解决后,会发布一个"service releases"版本,简称SRX版本。
从Hoxton版本后,Spring Cloud的版本号从地铁名称改成了时间的命名方式,目前Spring Cloud的最新版本是2023.0.1。
开发相关
JDK版本的选择
Spring Boot 3.0 本次带来最大的改动就是 GraalVM 原生镜像的支持,也是官方文档中强调的他们花费时间精力比较多的部分。 GraalVM 技术作为 JRE 的替代方案,其通过预先编译(Ahead Of Time,AOT)等技术对 Java 应用进行预先编译,让 Spring 在运行应用时掌握更多应用有关的信息,让整个应用启动速度更快。
另外,通过编译工具在编译过程中通过消除一些不必要的内容可以让最终的应用更小,占用内存更低。对于一些对启动速度要求非常高的场景,比如 Serverless、FaaS 场景非常友好! 本次 Spring Boot 3.0 直接将其正式从 Spring Native 迁入到 Spring Boot 中来,也预示着该项技术开始逐渐走向成熟,Spring 生态开始迈入 GraalVM 阶段! 跟 JVM 编译部署方式相比,GraalVM 具有以下特点:
- 在应用构建阶段,从主入口点就开始进行应用程序的静态分析。
- 创建本机镜像时,通过代码分析,会将无法访问的代码删除,并且不会成为可执行文件的一部分,从而可在一定程度上压缩程序包大小。
- GraalVM 无法直接感知代码的动态元素,因此对于存在反射、序列化和动态代理的应用程序,需要提前提供相关 hint 配置文件,帮助解析应用程序,相关操作过程可参考官方文档。
- 应用程序类路径在构建时是固定的,不能更改。
- 没有惰性类加载,可执行文件中的所有内容都将在启动时加载到内存中。
- 支持的 Java 应用程序在某些方面存在一些限制,因此目前并不能保证之前的 Java 应用都可直接使用 GraalVM 技术进行应用构建,有一定概率会存在不兼容的异常情况。
常用开发命令
没太好分类,主要是开发调度过程中有可能会使用的命令。
- HomeBrew
#软件服务
brew services start/stop/list
# 用brew安装的软件位置:/usr/local/Cellar/
# 用brew安装的软件配置文件位置:/usr/local/etc/
- Linux
lsof -i :15001
ps -ef | grep java
kill -9 pid