认识微服务架构
在入门Spring Cloud 之前，我们需要先了解下什么是微服务，在架构发展的过程中，项目开发遇到了哪些问题，以及Spring Cloud是用来解决什么问题的。
单体架构 vs 微服务架构的区别
在学习微服务之前，先了解它与传统单体架构的核心差异，能帮助我们更好地理解微服务的设计初衷
下图表示了单体架构到微服务架构的发展过程
单体架构将所有功能模块（如用户管理、订单处理、支付系统等）打包在一个应用程序中，部署在单一服务器或集群上。
- 特点
- 代码集中在一个代码库，开发工具和技术栈统一
- 部署简单，只需打包成一个应用（如 JAR、WAR 包）
- 初期开发速度快，适合小型项目
- 随着系统扩大，代码量激增，维护难度指数级上升
- 任何模块的修改都需要整体重新部署
- 技术栈受限，无法针对不同模块选择最优技术
也就是说，单体架构会把业务的所有功能实现都打包在⼀个项目。业务的所有功能实现都打包在⼀个war包或者Jar包中，我们将这种方式就称为单体架构。
这种架构开发和部署都很简单，⼀个项目就包含了所有的功能，省去了多个项目之间的交互和调⽤消耗，直接部署在⼀个服务器即可。
当网站的用户量越来越大，需求也会越来越多，流量也会越来越大，服务可能就会⾯临以下问题：
- 后端服务器的压力就会越来越大，负载越来越高，甚⾄出现无法访问的情况
- 业务场景逐渐复杂，为了满⾜用户的需求，单体应⽤也会越来越⼤，各个业务代码之间的耦合度也会越来越高，任何⼀个问题，都需要整个项目重新构建，发布
- ⼀个任何简单的问题都可能会导致整个应用挂掉
我们从两个方向进行优化:
- 横向: 添加服务器，把单台机器变成多台机器的集群，即利用集群的思想。
- 纵向: 把⼀个应用，按照业务进行拆分，拆分为多个项目，此架构也称为垂直架构，即利用分布式的思想。
而在在分布式架构下，当部署的服务越来越多，重复的代码就会越来越多，服务的调⽤关系也会越来越复杂。
我们可以把⼀些通用的会被多个上层服务调⽤的共享业务提取成独⽴的基础服务，组成⼀个个微小的服务，这就是微服务。这样就使得平均的服务器压力更小，单个服务故障影响范围小。
将应用拆分为多个独立的、可独立部署的小型服务，每个服务专注于完成单一业务功能，通过网络通信协同工作，这就是微服务架构。
- 特点
- 每个服务独立开发、测试、部署和运维
- 服务间通过 HTTP、RPC 等协议通信
- 可根据不同服务的需求选择不同技术栈（如订单服务用 Java，搜索服务用 Python）
- 单个服务故障通常不会导致整个系统崩溃
- 可针对高负载服务单独扩容，资源利用率更高
- 整体复杂度上升，需要解决服务协调、分布式事务等问题
分布式系统 vs 微服务架构
很多人会把分布式和微服务弄混淆，这二者是不能划等号的，思想和编码设计都完全不同
简单来说：微服务是一种架构设计思想，而分布式是一种系统部署形态。二者的本质、目标和实现方式都存在显著差异。
分布式系统（Distributed System）由多个独立计算机（节点）通过网络连接组成的系统，这些节点协同工作，对外表现为一个统一的整体。是从 “物理部署” 角度描述系统，多节点协同工作，解决性能和可用性问题。
本质上是为了解决 “物理资源分散” 问题，通过将任务拆分到多个节点执行，突破单台计算机的硬件限制（如 CPU、内存、存储、算力）。
分布式系统的核心思想是 “资源整合”：通过将多台计算机连接成一个整体，实现单节点无法完成的大规模计算或存储（例如，用 100 台服务器共同存储 PB 级数据）。
分布式系统的设计更多由技术限制驱动：例如，单台服务器无法处理每秒 10 万次请求，因此需要分布式部署多个节点分担压力。
- 核心特征
- 节点间通过网络通信（而非共享内存）
- 每个节点有独立的操作系统和进程
- 系统需要处理节点故障、网络延迟等分布式问题
- 典型案例：分布式数据库（如 MySQL 集群）、Hadoop 分布式计算框架、分布式缓存（如 Redis 集群）
而微服务架构将单一应用拆分为多个小型、自治的服务，每个服务聚焦于特定业务功能，通过轻量级通信协议（如 HTTP/REST）协同工作。是从 “架构设计” 角度描述系统，按业务拆分服务，解决复杂度和迭代效率问题。
本质上是解决 “软件架构复杂度” 问题，通过拆分业务边界，实现服务的独立开发、部署和扩展，适应快速变化的业务需求。
微服务架构的核心思想是 “业务解耦”：通过拆分业务模块，让每个服务独立演化，避免单体系统 “牵一发而动全身” 的问题（例如，订单服务的修改不影响商品服务）。
微服务架构的设计更多由业务需求驱动：例如，电商平台需要快速迭代订单功能，同时不影响商品展示功能，因此将二者拆分为独立服务。
- 核心特征
- 按业务领域拆分服务（而非按技术层）
- 服务独立部署、独立升级、独立扩缩容
- 服务拥有自治的数据存储
- 典型案例：电商系统（商品服务、订单服务、支付服务等）、外卖平台（用户服务、配送服务、商家服务等）
所以说，他们的关系如下
- 微服务架构一定是分布式系统（服务部署在不同节点，通过网络通信）。
- 分布式系统不一定是微服务：例如，一个单体应用部署在多台服务器上（通过负载均衡实现分布式部署），但并未按业务拆分为服务，这是分布式系统但不是微服务。
何为微服务，如何理解
其实上面所说的已经较为清除了，但是这里再单独拿出来说一些
微服务架构是一种将复杂应用拆分为多个小型、自治服务的设计模式，其核心目标是通过 “分而治之” 解决单体应用的复杂度问题，支持独立迭代和弹性扩展。要理解微服务，需从其核心组件（服务拆分、服务发现、负载均衡、配置管理等）的作用和协同逻辑入手。
为什么需要微服务
想象一个电商单体应用：用户、商品、订单、支付等功能打包在一个代码库中，部署在一台服务器上。随着业务增长，会出现以下问题：
- 代码量爆炸，团队协作冲突（改一个功能需全量测试）；
- 技术栈固化（想换框架需重构整个应用）；
- 扩展受限（订单模块压力大时，需整体扩容服务器，资源浪费）。
微服务通过 “拆拆拆 + 联联联” 解决这些问题：
- “拆”：按业务边界拆分服务（服务拆分），每个服务独立开发、部署；
- “联”：通过服务发现、负载均衡等机制让服务间高效通信；
- “稳”：通过配置管理、熔断降级等保障系统稳定性。
从一个请求看微服务整体的实现流程
以 “用户下单” 为例，看各组件如何配合：
- 用户在 APP 点击 “下单”，请求发送到网关（如 Spring Cloud Gateway）；
- 网关将请求转发给订单服务；
- 订单服务需要检查商品库存，此时：
- 订单服务向注册中心查询 “商品服务” 的可用实例列表（服务发现）；
- 用负载均衡策略（如轮询）选择商品服务的实例 A（10.0.0.5:8082）；
- 调用商品服务实例 A 的 “查询库存” 接口；
- 订单服务需要验证用户信息，同理通过服务发现和负载均衡调用用户服务；
- 下单过程中，若配置中心更新了 “订单超时时间”，订单服务实时生效新配置；
- 订单创建成功后，返回结果给用户。
服务拆分是什么
服务拆分就是将单体应用按业务边界拆分为多个微服务的过程，是微服务设计的基础。
服务拆分是微服务的起点，决定了后续架构的合理性。其核心原则是 “高内聚、低耦合”：每个服务聚焦单一业务能力，服务间通过定义清晰的接口通信，避免交叉依赖。
拆分原则
- 单一职责：每个服务专注于完成一个业务领域的功能（如用户服务只处理用户相关操作）
- 高内聚低耦合：服务内部功能紧密相关，服务间依赖尽可能少
- 基于业务能力：按业务部门或业务流程拆分（如电商可拆分为商品、订单、支付、物流等服务）
- 数据自治：每个服务通常拥有自己的数据库，避免多个服务共享数据库
如何拆分？
按业务领域拆分（推荐）：
基于 “领域驱动设计（DDD）”，将业务划分为独立领域（如用户域、商品域、订单域）。例如：
- 电商系统可拆分为：用户服务（登录、注册）、商品服务（商品 CRUD、库存）、订单服务（下单、履约）、支付服务（支付接口、退款）。
避免按技术层拆分：不要拆分为 “数据库服务”“缓存服务”，这类拆分违反业务边界，会导致服务间依赖混乱。
拆分的 “度”：粒度如何把握？
- 过小：服务数量爆炸，通信成本剧增（例如拆成 “用户注册服务”“用户登录服务”，二者强关联，反而复杂）；
- 过大：接近单体，失去微服务优势（例如 “交易服务” 包含订单、支付、物流，仍难以独立迭代）。 判断标准：一个服务可由 1-5 人团队独立维护，且修改时无需频繁协调其他服务。
服务发现是什么
服务发现就是在动态变化的微服务集群中，让服务消费者能自动找到服务提供者的机制。
服务拆分后，每个服务可能部署多个实例（例如订单服务部署在 3 台服务器上，IP 分别为 10.0.0.1:8081、10.0.0.2:8081、10.0.0.3:8081）。其他服务（如用户服务）需要知道 “订单服务在哪”，这就是服务发现的作用。
核心问题：服务地址如何管理？
传统方式：写死 IP（硬编码），但服务扩容 / 迁移时需手动修改，极不灵活；
服务发现方案：引入 “注册中心” 作为中介：
服务启动时，将自己的 IP: 端口注册到注册中心（如 Nacos、Eureka）；
注册中心的工作流程
1
2订单服务实例1 → 注册 → 注册中心 ← 发现 ← 用户服务
订单服务实例2 → 注册 → 注册中心 ← 发现 ← 用户服务服务下线时，从注册中心注销；
其他服务通过注册中心查询目标服务的可用地址列表。
负载均衡是什么
负载均衡实现了将请求分发到多个服务实例，避免单个实例过载，提高系统可用性和响应速度。
服务发现解决了 “服务在哪” 的问题，但多个实例如何分配请求？例如用户服务同时调用订单服务的 3 个实例，需避免某台服务器压力过大，这就是负载均衡的作用。
核心逻辑：
- 从注册中心获取目标服务的可用实例列表；
- 按预设策略（如轮询、权重、最少连接数）选择一个实例处理请求。
常见负载均衡方案：
客户端负载均衡（微服务常用）： 负载均衡逻辑在调用方（如用户服务）内部实现，例如 Spring Cloud 的 Ribbon。
流程：用户服务从注册中心拉取订单服务地址列表 → 本地用轮询策略选择实例 → 直接调用该实例。
优势：减少中间节点，降低延迟。
服务端负载均衡（传统架构常用）：
所有请求先经过负载均衡器（如 Nginx），由其分配到具体实例。但是负载均衡器可能成为瓶颈。
常见策略
- 轮询：依次调用每个实例（1→2→3→1…），适合实例性能相近的场景；
- 随机：随机选择服务实例
- 权重：给性能好的实例分配更高权重（如实例 1 处理 60% 请求，实例 2 处理 40%）；
- 最少连接：优先选择当前连接数最少的实例，适合请求处理时间差异大的场景。
配置管理
微服务就必然需要集中管理所有微服务的配置信息（如数据库连接、API 密钥、限流阈值等），并支持动态更新。
微服务部署实例多（可能几十上百个），若每个实例的配置（如数据库密码、接口超时时间）都写在代码里，修改时需逐个重启，效率极低。配置管理的作用是集中管理配置，支持动态更新。
核心需求：
- 集中存储：所有服务的配置保存在配置中心（如 Nacos、Apollo）；
- 动态推送：配置修改后，自动同步到所有相关服务实例，无需重启；
- 环境隔离：区分开发、测试、生产环境的配置（如生产库密码和测试库密码不同）。
工作流程：
- 开发人员在配置中心修改 “订单服务超时时间” 为 5 秒；
- 配置中心将新配置推送给所有订单服务实例；
- 订单服务实例实时更新本地配置，后续请求按新超时时间处理。
典型配置场景：
- 数据库连接信息、缓存地址；
- 限流阈值（如每秒最多处理 1000 个请求）；
- 功能开关（如临时关闭 “优惠券使用” 功能）。
这么一看，理解微服务的核心是权衡
理解微服务的关键，它是 “业务复杂度增长到一定阶段” 的选择，而非必须。小型应用用单体架构更高效，只有当业务规模和团队规模达到阈值（如足够多的人团队、千万级用户），微服务的优势才会超过其带来的复杂性。
随着产品的复杂性和流量的增加，技术架构也在不断的发⽣变化，不论是早期的单体架构还是现在⼴泛使用的微服务架构，都是为了更好的服务产品，解决问题。
微服务架构带来好处的同时，也⾯临着⼀些挑战，从单体服务转向微服务意味着管理更加复杂，接下来我们从优势和挑战两个方向分析⼀下微服务架构。
优势
- 易开发和维护：每个微服务负责的业务比较清晰，体量小，开发和维护成本降低.
- 容错性高：⼀个服务发生故障，可以使故障隔离在单个服务中，不影响整体服务故障.
- 扩展性好：每个服务都是独立运行的，我们可以结合项⽬实际情况进⾏扩展，按需伸缩.
- 技术选型灵活：每个微服务都是单独的团队来运维，可以根据业务特点和团队特点，选择适合的技术栈
虽然微服务具备很多的优势, 但由于服务数的增加, 服务治理也是我们⾯临的巨⼤挑战. 挑战
- 服务依赖：随着服务的数量增多，服务之间的关系也会变得更加复杂，⼀个服务的更改 需要考虑对其他服务的影响.
- 运维成本：⼀个业务流程会涉及多个微服务共同完成，有更多的服务需要编译、部署、运行，甚⾄可能是不同的编程语言，不同的运⾏环境，当然也需要集群来处理故障转移等，这对于运维人员而言挑战是巨⼤的.
- 开发和测试：⼀个业务流程可能涉及多个微服务共同完成，服务调⽤引⼊⽹络延迟，不可靠的⽹络，如何进行容错处理等问题，这对开发和测试而言难度也会提升.
- 服务监控：在⼀个单体结构中, 很容易实现服务的监控，因为所有功能都在⼀个服务中, 微服务架构下，不仅需要对整个链路进⾏监控，还需要对每⼀个服务实现监控.
- 负载均衡：微服务架构中的服务实例数量可能⾮常庞大，因此需要有效的服务发现和负载均衡机制来管理请求流量和保证⾼可⽤性
选择微服务架构的话，以上这些问题都需要我们解决，我们是自己研发还是选择市场上比较成熟的技术拿来⽤呢？全球的互联网公司都在积极尝试自己的微服务落地方案，在Java领域最引⼈注⽬的就是Spring Cloud。
