【SpringCloud】微服务架构演进与Spring Cloud简介

概述

在学习Spring Cloud 之前, 我们先来了解下什么是微服务, 以及微服务的发展史. 在架构发展的过程中, 项⽬开发遇到了哪些问题, 以及Spring Cloud是⽤来解决什么问题的.

认识微服务

下图表⽰了服务架构从单体应用逐渐转变为微服务应用的过程

单体架构

很多创业公司早期或者传统企业会把业务的所有功能实现都打包在⼀个项⽬, 这就是单体架构.

业务的所有功能实现都打包在⼀个war包或者Jar包中, 这种⽅式就称为单体架构

⽐如博客系统, 前端+后端+数据库实现, 都在⼀个项⽬中, 这种架构就称为单体架构.

以⼤家都很熟悉的电商系统为例, 电商系统包括: ⽤⼾管理, 商品管理, 订单管理, ⽀付管理, 库存管理, 物流管理等等, 项⽬早期我们会把这些模块都写在⼀个web项⽬中, 然后统⼀部署到⼀个Web服务器中

这种架构开发简单, 部署简单, ⼀个项⽬就包含了所有的功能, 省去了多个项⽬之间的交互和调⽤消耗. 直接部署在⼀个服务器即可.

集群和分布式架构

随着网站用户量和需求的增加，流量逐渐增大，后端服务可能面临以下问题：

• 服务器压力增大：后端服务器的负载越来越高，甚至出现无法访问的情况。
• 业务复杂度增加：为了满足用户需求，单体应用变得越来越庞大，业务代码之间的耦合度也越来越高。任何一个问题都需要整个项目重新构建和发布。
• 单点故障风险：一个微小的问题可能导致整个应用挂掉。

为了解决这些问题，我们可以从以下两个方面进行优化：

1. 横向扩展：添加服务器，将单台机器变成多台机器的集群。（集群）
2. 纵向拆分：根据业务将一个应用拆分为多个项目，此架构也称为垂直架构。（分布式）

垂直架构的实现方式：

• 单体项目垂直划分：将一个大型项目拆分为多个独立的单体结构项目。项目与项目之间相对独立，接口多用于数据同步功能。

集群和分布式

• 集群 (Cluster)：将一个系统完整地部署到多台服务器上，每台服务器都能提供系统的所有服务，通过负载均衡调度完成任务。每台服务器称为集群的节点 (Node)。
• 分布式：将一个系统拆分为多个子系统，多个子系统部署在不同的服务器上，这些子系统协同合作完成特定任务。

例如：

一个饭店只有一个厨师，这个厨师负责备菜、洗菜、切菜和炒菜。

随着饭店生意越来越好，这个厨师忙不过来了，饭店又请了一个厨师，新厨师和老厨师做一样的事情：洗菜、切菜和炒菜。这两个厨师的关系就是集群。

为了让厨师专心炒菜，饭店又请了一个配菜师，负责备菜、洗菜和切菜。厨师和配菜师的关系就是分布式。

后来一个配菜师也忙不过来了，又请了一个配菜师，这两个配菜师的关系就是集群。

分布式的节点可能是集群

集群和分布式的区别和联系：

1. 概念上：

   • 集群：多个计算机做同样的事。
   • 分布式：多个计算机做不同的事。

2. 功能上：

   • 集群：每个节点的功能是相同且可以互相替代的。
   • 分布式：多个节点组成系统，每个节点完成的业务不同，一个节点出现问题，该业务就不可访问。

3. 关系上：

   • 分布式和集群在实践中常互相配合使用。例如，分布式的某个节点可能由一个集群来代替。分布式架构通常建立在集群上，所以在实际的分布式架构设计中，不会单独区分分布式和集群，而是统称为分布式架构。

微服务架构

从上图可以看出，按照业务进行拆分后，会有一些重复的功能开发，例如订单系统、电商平台和支付系统都会涉及类似的功能。

在分布式架构下，随着服务部署数量的增加，重复代码也会增多，服务调用关系变得更加复杂。

我们可以将一些通用的、会被多个上层服务调用的共享业务提取成独立的基础服务，组成一个个微小的服务，这就是微服务。

简单来说，微服务就是非常小的服务。小到一个服务只对应一个单一功能，只做一件事。这个服务可以单独部署运行，微服务之间可以采用 REST 和 RPC 协议进行通信。

注：REST 和 RPC 具体内容后面会讲，此处可以理解为接口的约定。

从这个角度来看，微服务架构是分布式架构的一种拓展。这种架构模式下，它的拆分粒度更小，服务更独立。可以理解为：微服务是一种经过良好架构设计的分布式架构方案。

分布式架构与微服务架构

• 分布式：服务拆分，拆了就行。
• 微服务：非常微小的服务，更细粒度的垂直拆分，通常指不能再拆的服务。

区别：

• 分布式架构：侧重于压力的分散，强调服务的分散化。
• 微服务架构：侧重于能力的分散，更强调服务的专业化和精细分工。

从实践的角度来看，微服务架构通常是分布式服务架构，但反之则未必成立。所以，选择微服务通常意味着需要解决分布式架构的各种难题。

微服务带来的挑战

随着产品的复杂性和流量的增加，技术架构也在不断发生变化。不论是早期的单体架构，还是现在广泛使用的微服务架构，都是为了更好地服务产品，解决问题。

微服务架构带来了许多好处，但同时也面临一些挑战。从单体服务转向微服务意味着管理更加复杂。接下来我们从优势和挑战两个方面分析微服务架构。

优势

• 易开发和维护：每个微服务负责的业务比较清晰，体量小，开发和维护成本降低。
• 容错性高：一个服务发生故障，可以使故障隔离在单个服务中，不影响整体服务。
• 扩展性好：每个服务都是独立运行的，可以根据项目实际情况进行扩展，按需伸缩。
• 技术选型灵活：每个微服务都是单独的团队来运维，可以根据业务特点和团队特点选择适合的技术栈。

挑战

尽管微服务具有很多优势，但由于服务数量的增加，服务治理也面临巨大的挑战。

• 服务依赖：随着服务数量的增多，服务之间的关系变得更加复杂。一个服务的更改，需要考虑对其他服务的影响。
• 运维成本：一个业务流程会涉及多个微服务共同完成，有更多的服务需要编译、部署、运行，甚至可能是不同的编程语言和运行环境。这对于运维人员而言，挑战是巨大的。
• 开发和测试：一个业务流程可能涉及多个微服务共同完成，服务调用引入网络延迟和不可靠的网络，需要进行容错处理等问题。这对开发和测试而言，难度也会提升。
• 服务监控：在单体架构中，很容易实现服务的监控，因为所有功能都在一个服务中。在微服务架构下，不仅需要对整个链路进行监控，还需要对每一个服务实现监控。
• 负载均衡：微服务架构中的服务实例数量可能非常庞大，需要有效的服务发现和负载均衡机制来管理请求流量并保证高可用性。

例如企业员工管理

员工少的时候，一个员工可能各方面的工作都要会，但员工之间的协同工作较少，员工管理也相对简单。

随着企业的发展，事情越来越多，一个员工的能力有限，就需要招聘更多的人，这时候就涉及到员工的管理。

员工越多，员工的管理就越复杂。

服务也是类似。

选择微服务架构后，上述这些问题都需要解决。我们是自行研发还是选择市场上比较成熟的技术解决方案呢？

全球的互联网公司都在积极尝试自己的微服务落地方案。在 Java 领域，最引人注目的就是 Spring Cloud。

微服务解决方案 - Spring Cloud

什么是 Spring Cloud

我们先看一下官网的介绍：

Spring Cloud 提供了一些可以让开发人员快速构建分布式服务的工具，如配置管理、服务发现、熔断、智能路由等。它们可以在任何分布式环境中很好地工作。

简单来说，Spring Cloud 就是分布式微服务架构的一站式解决方案，是微服务架构落地的多种技术的集合。

例如：

• Distributed/versioned configuration 分布式版本配置
• Service registration and discovery 服务注册和发现
• Routing 路由
• Service-to-service calls 服务调用
• Load balancing 负载均衡
• Circuit Breakers 断路器
• Distributed messaging 分布式消息
• Short lived microservices (tasks) 生存期较短的微服务(任务)
• Consumer-driven and producer-driven contract testing 消费者驱动和生产者驱动的合同测试

Spring Cloud 并不是 Spring 团队研发的框架，它只是将一些优秀的解决微服务架构中常见问题的开源框架基于 Spring Cloud 规范进行了整合，并基于 Spring Boot 的风格，对这些组件进行了封装，屏蔽掉了复杂的配置和实现原理，为开发者提供了开箱即用的微服务开发体验。

这些开源技术的框架由各个公司来维护。Spring Cloud 就是这些微服务的大管家。

Spring Cloud 版本

Spring Cloud 是一个由许多子项目组成的庞大项目，这些子项目由各个公司来维护，因此发布阶段也不同。

为了管理主项目和子项目的依赖关系，以及避免与子项目版本的冲突，主项目版本命名并没有采用与子项目数字版本化的形式，而是采用了英文名称。

这些英文版本名称也比较有趣，Spring Cloud 采用了英国伦敦地铁站的名称来命名，并由地铁站名称字母 A-Z 依次类推的形式来发布迭代版本。

• Angel
• Brixton
• Camden
• Dalston
• Edgware
• Finchley
• Greenwich
• Hoxton

但英文版本号太复杂了，从 Hoxton 版本之后，Spring Cloud 的版本就变成了 2020.0.0 这样的日期版本号了

• 2020.0.x aka Ilford
• 2021.0.x aka Jubilee
• 2022.0.x aka Kilburn
• 2023.0.x aka Leyton

Spring Cloud 和 Spring Boot 的关系

Spring Cloud 中的所有子项目都依赖 Spring Boot，因此 Spring Boot 和 Spring Cloud 的版本之间也存在一定的对应关系。

例如，Spring Boot 3.2.X 对应的 Spring Cloud 版本是 2023.0.X。

如果我们有一个 Spring Boot 项目，并希望在该项目中添加 Spring Cloud 的一些组件，需要根据当前项目的 Spring Boot 版本，选择相应的 Spring Cloud 版本（新项目不存在这个问题）。

Spring Cloud 实现方案

在 Spring Cloud 的规范下，有很多实现，其中最为出名的是：

• Spring Cloud Netflix
• Spring Cloud Alibaba

Spring Cloud Netflix

Spring Cloud Netflix 是 Netflix OSS (Netflix Open Source Software) 在 Spring Cloud 规范下的实现。

包含的组件及其主要功能大致如下：

• Eureka: 服务注册和发现
• Zuul: 服务网关
• Ribbon: 负载均衡
• Feign: 服务调用组件
• Hystrix: 断路器，提供服务熔断和限流
• Hystrix Dashboard: 监控面板
• …

在很长一段时间里，Spring Cloud 一度被泛指为 Spring Cloud Netflix。Spring Cloud 一直以来把 Netflix OSS 套件作为其官方默认的一站式解决方案。然而，Netflix 公司在 2018 年前后宣布其核心组件 Hystrix、Ribbon、Zuul 等均进入维护状态，Spring Cloud 也被迫宣布删除这些维护模块。

Spring Cloud Netflix 并没有从 Spring Cloud 的依赖中完全删除，只是从 2020.0 版本起，它只管理 Eureka。

Spring Cloud Netflix 在很多公司都有大规模使用，一旦停止更新，短期看影响不大，但长期显然是不合适的。Spring Cloud 官方也提供了一些替换建议。

Spring Cloud Alibaba

Spring Cloud Alibaba 是阿里巴巴集团下的开源组件和云产品在 Spring Cloud 规范下的实现。

虽然 Spring Cloud Alibaba 目前并不是 Spring Cloud 官方推荐的默认方案，但是 Spring Cloud Alibaba 是阿里中间件团队主导的一个新生项目，正处于高速迭代中。甚至在 Alibaba 的开源组件还没有织入 Spring Cloud 生态之前，就已经在各大公司广泛使用了。

官方网站: Spring Cloud Alibaba 是什么 | Spring Cloud Alibaba

如果说 Spring Cloud Netflix 是 Spring Cloud 的第一代实现，那么 Spring Cloud Alibaba 也可以看做是 Spring Cloud 的第二代实现，主要由 Nacos、Sentinel、Seata 等组件组成。

Spring Cloud Alibaba 吸收了 Spring Cloud Netflix 微服务框架的核心架构思想，并进行了高性能改进。自 Spring Cloud Netflix 进入停更维护后，Spring Cloud Alibaba 逐渐代替它成为主流的微服务框架。

Spring Cloud 实现对比

其中 Spring Cloud Netflix 的 Feign、Archaius、Zuul、Ribbon 已经进入维护状态

下面只讲解图表中加粗的组件