Spring Cloud是分布式微服务架构的一站式解决方案,它提供了一套简单易用的编程模型,使我们能在Spring Boot的基础上轻松地实现微服务系统的构建。
Spring Cloud被称为构建分布式微服务系统的“全家桶”,它并不是某一门技术,而是一系列微服务解决方案或框架的有序集合。它提供了服务治理、服务网关、智能路由、负载均衡、断路器、监控跟踪、分布式消息队列、配置管理等领域的解决方案。
Spring Cloud是一套微服务规范,共有两代实现:
-
Spring Cloud Netflix 是第一代,主要由Eureka、Ribbon、Feign、Hystrix等组件组成。
-
Spring Cloud Alibaba 是第二代,主要由Nacos、Sentinel、Seata等组件组成。
1、微服务:微小的服务
(1)”服务“:项目中的功能模块,可以帮助用户解决某一个或一组问题,开发过程中表现为IDE中的一个工程或Moudle。
(2)”微小“强调的是单个服务的大小,体现在以下两个方面:
①、微服务体积小、复杂度低:一个微服务通常只提供单个业务功能的服务,因此微服务通常代码少,体积小,复杂度低。
②、微服务团队成员少。
微服务架构
微服务架构提倡将一个单一的应用程序拆分成多个小型服务,这些小型服务都在各自独立的进程中运行,服务之间使用轻量级通信机制(通常是HTTP RESTFUL API)进行通讯。
微服务架构 vs 单体架构
不同点 | 微服务架构 | 单体架构 |
---|---|---|
团队规模 | 微服务架构可以将传统模式下的单个应用拆分为多个独立的服务,每个微服务都可以单独开发、部署和维护。每个服务从设计、开发到维护所需的团队规模小,团队管理成本小。 | 单体架构的应用程序通常需要一个大型团队,围绕一个庞大的应用程序工作,团队管理的成本大。 |
数据存储方式 | 不同的微服务可以使用不同的数据存储方式,例如有的用 Redis,有的使用 MySQL。 | 单一架构的所有模块共享同一个公共数据库,存储方式相对单一。 |
部署方式 | 微服务架构中每个服务都可以独立部署,也可以独立于其他服务进行扩展。如果部署得当,基于微服务的架构可以帮助企业提高应用程序的部署效率。 | 采用单体架构的应用程序的每一次功能更改或 bug 修复都必须对整个应用程序重新进行部署。 |
开发模式 | 在采用微服务架构的应用程序中,不同模块可以使用不同的技术或语言进行开发,开发模式更加灵活。 | 在采用单体架构的应用程序中,所有模块使用的技术和语言必须相同,开发模式受限。 |
故障隔离 | 在微服务架构中,故障被隔离在单个服务中,避免系统的整体崩溃。 | 在单体架构中,当一个组件出现故障时,故障很可能会在进程中蔓延,导致系统全局不可用。 |
项目结构 | 微服务架构将单个应用程序拆分为多个独立的小型服务,每个服务都可以独立的开发、部署和维护,每个服务都能完成一项特定的业务需求。 | 单体架构的应用程序,所有的业务逻辑都集中在同一个工程中。 |
微服务的特点
-
服务按照业务来划分,每个服务通常只专注于某一个特定的业务、所需代码量小,复杂度低、易于维护。
-
每个微服都可以独立开发、部署和运行,且代码量较少,因此启动和运行速度较快。
-
每个服务从设计、开发、测试到维护所需的团队规模小,一般 8 到 10 人,团队管理成本小。
-
采用单体架构的应用程序只要有任何修改,就需要重新部署整个应用才能生效,而微服务则完美地解决了这一问题。在微服架构中,某个微服务修改后,只需要重新部署这个服务即可,而不需要重新部署整个应用程序。
-
在微服务架构中,开发人员可以结合项目业务及团队的特点,合理地选择语言和工具进行开发和部署,不同的微服务可以使用不同的语言和工具。
-
微服务具备良好的可扩展性。随着业务的不断增加,微服务的体积和代码量都会急剧膨胀,此时我们可以根据业务将微服务再次进行拆分;除此之外,当用户量和并发量的增加时,我们还可以将微服务集群化部署,从而增加系统的负载能力。
-
微服务能够与容器(Docker)配合使用,实现快速迭代、快速构建、快速部署。
-
微服务具有良好的故障隔离能力,当应用程序中的某个微服发生故障时,该故障会被隔离在当前服务中,而不会波及到其他微服务造成整个系统的瘫痪。
-
微服务系统具有链路追踪的能力。
微服务框架
java 微服务架构:
-
Spring Cloud:它能够基于 REST 服务来构建服务,帮助架构师构建出一套完整的微服务技术生态链。
-
Dropwizard:用于开发高性能和 Restful 的 Web 服务,对配置、应用程序指标、日志记录和操作工具都提供了开箱即用的支持。
-
Restlet: 该框架遵循 RST 架构风格,可以帮助 Java 开发人员构建微服务。
-
Spark:最好的 Java 微服务框架之一,该框架支持通过 Java 8 和 Kotlin 创建微服务架构的应用程序。
-
Dubbo:由阿里巴巴开源的分布式服务治理框架。
2、Spring Cloud
-
服务治理:阿里巴巴开源的Dubbo和当当网在其基础上扩展出来的DubboX、Netflix的Eureka以及Apache的Consul等。
-
分布式配置管理:百度的Disconf、Netflix的Archaius、360的Qconf、携程的Apollo以及Spring Cloud的Config等。
-
批量任务:当当网的Elastic-Job、LinkedIn的Azkaban以及Spring Cloud的Task等。
-
服务跟踪:京东的Hydra、Spring Cloud的Sleuth以及Twitter的Zipkin等。
以上微服务框架或解决方案都具有的2个特点:
(1)对于同一个微服务问题,各互联网公司给出的解决方案各不相同;
(2)一个微服务框架或解决方案都只能解决微服务中的某一个或某几个问题;
Spring Cloud 的常用组件如下表所示。
Spring Cloud 组件 | 描述 |
---|---|
Spring Cloud Netflix Eureka | Spring Cloud Netflix 中的服务治理组件,包含服务注册中心、服务注册与发现机制的实现。 |
Spring Cloud Netflix Ribbon | Spring Cloud Netflix 中的服务调用和客户端负载均衡组件。 |
Spring Cloud Netflix Hystrix | 人称“豪猪哥”,Spring Cloud Netflix 的容错管理组件,为服务中出现的延迟和故障提供强大的容错能力。 |
Spring Cloud Netflix Feign | 基于 Ribbon 和 Hystrix 的声明式服务调用组件。 |
Spring Cloud Netflix Zuul | Spring Cloud Netflix 中的网关组件,提供了智能路由、访问过滤等功能。 |
Spring Cloud Gateway | 一个基于 Spring 5.0,Spring Boot 2.0 和 Project Reactor 等技术开发的网关框架,它使用 Filter 链的方式提供了网关的基本功能,例如安全、监控/指标和限流等。 |
Spring Cloud Config | Spring Cloud 的配置管理工具,支持使用 Git 存储配置内容,实现应用配置的外部化存储,并支持在客户端对配置进行刷新、加密、解密等操作。 |
Spring Cloud Bus | Spring Cloud 的事件和消息总线,主要用于在集群中传播事件或状态变化,以触发后续的处理,例如动态刷新配置。 |
Spring Cloud Stream | Spring Cloud 的消息中间件组件,它集成了 Apache Kafka 和 RabbitMQ 等消息中间件,并通过定义绑定器作为中间层,完美地实现了应用程序与消息中间件之间的隔离。通过向应用程序暴露统一的 Channel 通道,使得应用程序不需要再考虑各种不同的消息中间件实现,就能轻松地发送和接收消息。 |
Spring Cloud Sleuth | Spring Cloud 分布式链路跟踪组件,能够完美的整合 Twitter 的 Zipkin。 |
Spring Boot和Spring Cloud的区别和联系
1、Spring Boot和Spring Cloud分工不同
Spring Boot是一个基于Spring的快速开发框架,它能够帮助开发者迅速搭建Web工程。在微服务开发中,Spring Boot专注于快速、方便地开发单个微服务。
Spring Cloud是微服务架构下的一站式解决方案,Spring Cloud专注于全局微服务的协调和治理工作。也就是说,Spring Cloud相当于微服务的大管家,负责将Spring Boot开发的一个个微服务管理起来,并为它们提供配置管理、服务发现、断路器、路由、微代理、时间总线、决策竞选以及分布式会话等服务。
2、Spring Cloud 是基于Spring Boot实现的
Spring Cloud 也为提供了一系列的Starter,这些Starter是Spring Cloud 使用Spring Boot思想对各个微服务框架进行再封装的产物,它们屏蔽了这些微服务框架中复杂的配置和实现原理。
3、Spring Boot 和 Spring Cloud依赖项数量不同
Spring Boot 属于一种轻量级的框架,构建Spring Boot 工程所需的依赖较少。
Spring Cloud 是一系列微服务框架技术的集合体,它的每个组件都需要一个独立的依赖项(Starter POM),因此想要构建一套完整的Spring Cloud 工程往往需要大量的依赖项。
4、Spring Cloud 不能脱离Spring Boot 单独运行
Spring Boot 不需要Spring Cloud,就可以直接创建可独立运行的工程或模块;
Spring Cloud 是基于Spring Boot 实现的,它不能独立创建工程或模块,更不能脱离Spring Boot独立运行。
虽然Spring Boot能够用于开发单个微服务,但它并不具备管理和协调微服务的能力,因此它只能算是一个微服务快速开发框架,而非微服务框架。
Spring Cloud版本
Spring Cloud包含了许多子项目(组件),这些子项目都是独立进行内容更新和迭代的,各自维护着自己的发布版本号。
{version.name} .{version.number}
{version.name}:版本名,采用英国伦敦地铁站站名来命名,并按照字母表的顺序(A到Z)来对应Spring Cloud的版本发布顺序,依次为Angel、Brixton、Camden、Dalston、Edgware、Finchley、Greenwich、Hoxton等。
{version.number}:版本号,每一个版本的Spring Cloud 在更新内容积累到一定的量级或有重大BUG修复时,就会发布一个“service releases”版本。
3、Spring Cloud Eureka
Eureka,意思是“发现了”,是Netflix公司开发的一款开源的服务注册与发现组件。
Spring Cloud 将Eureka 与Netflix 中的其他开源服务组件(Ribbon、Feign、Hystrix)一起整合进Spring Cloud Netflix中,全称为 Spring Cloud Netflix Eureka。
Eureka 两大组件
(1)Eureka Server:Eureka服务注册中心,提供服务注册功能。当微服务启动时,会将自己的服务注册到Eureka Server。Eureka Server维护了一个可用服务列表,存储了所有注册到Eureka Server的可用服务的信息,这些可用服务可以在Eureka Server的管理界面中直观看到。
(2)Eureka Client:Eureka客户端,指的是微服务系统中的各个微服务,主要用于和Eureka Server进行交互。在微服务应用启动后,Eureka Client 会向Eureka Server 发送心跳(默认周期30秒),若Eureka Server 在多个心跳周期内没有接收到某个Eureka Client 的心跳,Eureka Server将它从可用服务中移除(默认90秒)。
“心跳”:指的是一段定时发送的自定义信息,让对方知道自己“存活”,以确保连接的有效性。大部分CS架构的应用程序都采用了心跳机制,服务端和客户端都可以发送心跳。通常是客户端向服务器发送心跳包,服务端用于判断客户端是否在线。
Eureka服务注册与实现
-
服务注册中心(Register Service):Eureka Server,用于提供服务注册和发现功能。
-
服务提供者(Provider Service):Eureka Client,用于提供服务,将自己提供的服务注册到服务注册中心,以供消费者发现。
-
服务消费者(Consumer Service):Eureka Client,用于消费服务,可以从服务注册中心获取服务列表,调用所需的服务。
Eureka实现服务注册和发现的流程:
(1)搭建一个Eureka Server 作为服务注册中心;
(2)服务提供者Eureka Client 启动时,会把当前服务器的信息以服务名(spring.application.name)的方式注册到服务注册中心;
(3)服务消费者Eureka Client 启动时,也会向服务注册中心注册;
(4)服务消费者还会获取一份可用服务列表,该列表中包含了所有注册到服务注册中心的服务信息(包含服务提供者和自身的信息);
(5)在获得了可用服务列表后,服务消费者通过HTTP或消息中间件远程调用服务提供者提供的服务。
Eureka Server集群
在微服务架构中,一个系统往往由十几甚至几十个服务组成,若将这些服务全部注册到同一个Eureka Server中,就极有可能导致Eureka Server因不堪重负而崩溃,最终导致整个系统瘫痪。解决这个问题最直接的办法就是部署Eureka Server 集群。
搭建服务注册中心时的application.yml文件中的配置
eureka: client: register-with-eureka: false #false 表示不向注册中心注册自己。 fetch-registry: false #false表示自己端就是注册中心,职责就是维护服务实例,并不需要去检索服务
自己本身是服务注册中心,不能把自己注册到自己身上,但是服务注册中心可以将自己注册到