单体架构

把业务的所有功能实现都打包在一个war包或者jar包，这种方式就成为单体架构。

比如Spring课程中的博客系统,前端+后端+数据库实现，都在一个项目中，这种架构就称为单体架构.

举个例子：

比如在电商系统中，我们会设计用户管理，商品管理，订单管理，支付管理，库存管理等等这些功能，在早期我们是会把这些模块都写在一个web项目中，然后统一部署到一个Web服务器中。

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

集群和分布式架构

但是呢，随着时间的发展，单体机构的弊端就逐渐显现了，就比如随着网站的用户量越来越大，需求也会越来越多，流量也会越来越大，服务可能就会面临一下问题：

后端服务器的压力就会越来越大，负载越来越高，甚至出现无法访问的情况。
业务场景逐渐复杂，为了满足用户的需求，单体应用也会越来越大，各个业务代码之间的耦合度也会越来越高，任何一个问题，可能会导致整个项目重新构建，发布。
一个微小的问题，可能会导致整个应用挂掉。

解决方案：

横向：添加服务器，把单台机器变成多台机器的集群。
纵向：把一个应用，按照业务进行拆分，拆分为多个项目，此架构也称为垂直架构或分布式架构。

举个例子，方便理解：

比如最开始只有一台机器，它能承担1000个用户，但是后来发展为10000个用户：

横向：扩容机器，从一台机器，扩容到10台机器，每台机器负责1000个用户。（集群）
纵向：按照功能进行划分。（分布式）

集群和分布式

**集群（cluster）**是将一个系统完整的部署到多个服务器上，每个服务器都能提供系统的所有服务，多个服务器通过负载均衡调度完成任务，每个服务器称为集群的节点（node）。
分布式是将一个系统拆分为多个子系统，多个子系统部署在多个服务器上，多个服务器上的子系统协同合作完成一个特定任务。

举个生活实例：

有一个小餐馆，刚开始只有一个厨师，这个厨师他负责做饭相关的所有工作，但随着餐馆的生意的好转，一个厨师忙不过来：
1. 横向：再招聘一个厨师，这两个厨师都可以独立做饭。
2. 纵向：厨师的工作分为：洗菜，切菜，配菜，炒菜…..
  
  就可以单独招一个配菜师，负责洗菜，切菜，配菜….
后面生意如果更加好了，就可以再招聘多个配菜师，多个厨师。

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

从概念上，集群是多个计算机做同样的事情（可以替代），而分布式是多个计算机做不同的事情（不可替代）。
从功能上，集群的每一个节点功能是相同的，并且是可以替代的，分布式也是多个节点组成的系统，但是每个节点完成的业务是不同的，一个节点出现问题，这个业务就不可访问了。
从关系上，分布式和集群在实践中，很多时候是互相配合使用的，比如分布式的某一个节点，可能由一个集群来代替。分布式架构大多是建立在集群上的，所以实际的分布式架构设计中并不会把分布式和集群单独区分，而是统称为：分布式架构。

微服务架构

在分布式架构下，当部署的服务越来越多，重复的代码就会越来越多，服务的调用关系也会越来越复杂，我们可以把一些通用的，会被多个上层服务调用的共享业务，提取成独立的基础服务，组成一个个微笑的服务，这就是微服务。

微服务，可以理解为“很小的服务”，小到一个服务只对应一个单一的功能，只做一件事，这个服务可以单独部署运行。

微服务之间可以采用 REST 和 RPC 协议进行通信。（类似http，可以理解为接口的约定）

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

分布式架构和微服务架构：

分布式架构和微服务架构有很多相似之处，例如都强调将系统拆分成多个独立的模块，多个模块可以部署在不同的服务器上等。不过两者也存在一些区别：

基本概念

分布式架构：一种将系统分解成多个子系统、模块或组件，并将它们分布到不同的计算节点上运行的架构风格。这些节点可以是物理服务器、虚拟机或容器等，节点之间通过网络进行通信，以协同完成业务功能。（服务拆分，拆了就行）
微服务架构：一种特定的分布式架构风格，将一个大型复杂应用分解成多个小型、独立、松耦合的服务，每个服务专注于特定的业务功能，并且可以独立开发、部署和扩展。

服务粒度

分布式架构：服务粒度可以是较大的模块或子系统，例如按业务模块划分的用户模块、订单模块、支付模块等。
微服务架构：服务粒度更小，通常聚焦于单一的业务功能，例如用户服务中的用户注册服务、用户登录服务等。

服务耦合度

分布式架构：服务之间的耦合度相对较高，因为它们共同组成一个完整的系统，往往需要紧密协作。例如，分布式架构中的服务之间可能共享数据库或数据模型。
微服务架构：服务之间保持较低的耦合度，每个服务独立运行，有自己独立的数据库和数据模型，服务之间的交互通过轻量级通信协议进行。

数据管理

分布式架构：数据管理方式取决于具体的分布式架构设计，可以是集中式的数据库，也可以是分布式数据库等。
微服务架构：采用去中心化的数据管理方式，每个微服务都有自己的数据库和数据模型，数据的访问和操作都在服务内部进行。

部署方式

分布式架构：部署方式可以是集中式或分布式，多个子系统或模块可以部署在同一个服务器或不同的服务器上，部署方式相对较为灵活。
微服务架构：通常采用容器化技术（如Docker、Kubernetes等）进行部署，每个微服务可以独立部署在容器中，容器之间的隔离性和独立性较好。

分布式架构侧重于压力的分散，强调的是服务的分散化，微服务侧重与能力的分散，更强调服务的专业化和精细分工，从实践的角度来看，微服务架构通常是分布式服务架构，反之则未必成立，所以，选择微服务通常意味着需要解决分布式架构的各种难题。

<aside> 💡

注意：对于架构的发展，从单体架构 → 垂直架构 → 分布式架构 → 微服务架构。

所有的架构都是为了更好的服务产品，合适的才是最好的。

</aside>

微服务带来的挑战

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

微服务架构带来好处的同时, 也⾯临着⼀些挑战, 从单体服务转向微服务意味着管理更加复杂. 接下来我们从优势和挑战两个⽅⾯分析⼀下微服务架构

优势

易开发和维护. 每个微服务负责的业务⽐较清晰, 体量⼩, 开发和维护成本降低。
容错性⾼，⼀个服务发⽣故障, 可以使故障隔离在单个服务中, 不影响整体服务故障。
扩展性好，每个服务都是独⽴运⾏的, 我们可以结合项⽬实际情况进⾏扩展, 按需伸缩。
技术选型灵活，每个微服务都是单独的团队来运维，可以根据业务特点和团队特点，选择适合的技术栈。

挑战虽然微服务具备很多的优势, 但由于服务数的增加, 服务治理也是我们⾯临的巨⼤挑战。

服务依赖，随着服务的数量增多, 服务之间的关系也会变得更加复杂. ⼀个服务的更改, 需要考虑对其他服务的影响。
运维成本. ⼀个业务流程会涉及多个微服务共同完成, 有更多的服务需要编译, 部署, 运⾏, 甚⾄可能是不同的编程语⾔, 不同的运⾏环境, 当然也需要集群来处理故障转移等. 这对于运维⼈员⽽⾔, 挑战是巨⼤的。
开发和测试. ⼀个业务流程可能涉及多个微服务共同完成, 服务调⽤引⼊⽹络延迟, 不可靠的⽹络, 如何进⾏容错处理等问题. 这对开发和测试⽽⾔, 难度也会提升。
服务监控. 在⼀个单体结构中, 很容易实现服务的监控. 因为所有功能都在⼀个服务中, 微服务架构下, 不仅需要对整个链路进⾏监控, 还需要对每⼀个服务实现监控。
负载均衡. 微服务架构中的服务实例数量可能⾮常庞⼤，因此需要有效的服务发现和负载均衡机制来管理请求流量和保证⾼可⽤性。
….

微服务解决⽅案- 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 分布式消息
....

<aside> 💡

Spring Cloud 并不是Spring 团队研发的框架, 它只是把⼀些⽐较优秀的解决微服务架构中常⻅问题的开源框架基于SpringCloud规范进⾏了整合, 并基于SpringBoot的⻛格,对这些组件进⾏封装, 屏蔽掉了复杂的配置和实现原理. 为开发者提供了开箱即⽤的微服务开发体验. 这些开源技术的框架是由各个公司来维护的. Spring Cloud 就是这些微服务的⼤管家.

</aside>

就可以理解为：

买房之后需要装修，装修时，需要买家电，电视，空调，洗衣机，冰箱等。然后这个时候来了一个企业，出了一些套餐：

套餐一：电视1 + 空调1 + 洗衣机2 + 冰箱3，

套餐二：电视2 + 空调1 + 洗衣机2 + 冰箱4

……..

Spring Cloud就类似这个企业

Spring Cloud和SpringBoot的版本对应关系

由于Spring Cloud的所有子项目都依赖SpringBoot，所以SpringBoot和SpringCloud的版本之间也存在一定的对应关系。

这边建议一一对应版本信息，如果不对应的话后续可能会出现一些版本问题上的错误。

SpringCloud的实现方案

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

Spring Cloud Netflix
Spring Cloud Alibaba

Spring Cloud Netflix

SpringCloudNetflix是NetflixOSS(NetflixOpenSourceSoftware)在SpringCloud规范下的实现。

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

Eureka: 服务注册和发现
Zuul: 服务⽹关
Ribbon: 负载均衡
Feign: 服务调⽤组件
Hystrix: 断路器, 提供服务熔断和限流
Hystrix Dashboard: 监控⾯板
……….

在很⻓的⼀段时间⾥, Spring Cloud ⼀度被泛指 Spring Cloud Netflix. Spring Cloud⼀直以来把 Netflix OSS 套件作为其官⽅默认的⼀站式解决⽅案. 然⽽, Netflix公司在2018年前后宣布其核⼼组件Hystrix、Ribbon、Zuul等均进⼊维护状态, Spring Cloud 也被迫宣布删除这些维护模块.

<aside> 💡

spring-cloud-netflix 并没有从Spring Cloud的依赖中完全删除, 只是从2020.0版本起, 他只管理Eureka

</aside>

Spring Cloud Netflix 在很多公司都有⼤规模使⽤, ⼀旦停⽌更新, 短期看影响不⼤, 但⻓期显然是不合适的, Spring Cloud官⽅也提供了⼀些替换建议。

Netflix	推荐替代品	说明
Hystrix	Resilience4j	Hystrix也推荐大家使用Resilience4j代替自己
Hystrix Dashboard / Turbine	Micrometer + Monitoring System	说白了，监控这件事交给更专业的组件去做
Ribbon	Spring Cloud Loadbalancer	忍不住了，Spring终究亲自出手
Zuul 1	Spring Cloud Gateway	忍不住了，Spring终究亲自出手
Archaius 1	Spring Boot外部化配置 + Spring Cloud配置	比Netflix实现的更好、更强大

Spring Cloud Alibaba

Spring Cloud Alibaba是阿里巴巴基于Spring Cloud生态推出的一站式微服务解决方案‌，集成了阿里巴巴的开源中间件和云服务组件，提供分布式应用开发、服务治理、配置管理等核心功能，是Spring Cloud第二代实现的主要组成部分。‌‌它填补了Spring Cloud Netflix停更后的空白，成为当前主流的微服务实现方案。‌‌主要由 Nacos、Sentinel、Seata 等组件组成。

Spring Cloud 实现对⽐

功能	SpringCloud官方	Spring Cloud Netflix	Spring Cloud Alibaba
服务注册/发现	Eureka	Eureka	Nacos
服务调用	OpenFeign	Feign	Dubbo
配置中心	SpringCloudConfig	Archaius	Nacos
服务网关	SpringCloudGateway	Zuul	SpringCloudGateway
负载均衡	SpringCloud LoadBalance	Ribbon	Dubbo