SpringCloud快速入门（1）---- 微服务介绍

很多初学SpringCloud的小伙伴，上手第一件事就是迷茫：单体、集群、分布式、微服务到底有什么区别？为什么要用微服务？SpringCloud到底解决了什么问题？

接下来按如下顺序讲解SpringCloud 是如何诞生的：单体架构 ➡ 集群架构 ➡ 分布式架构 ➡ 微服务架构

1、单体架构

1.1 介绍

单体架构 ：将项目所有功能（用户、商品、订单、支付、后台管理）全部写在一个工程里，代码耦合在一起，打包成一个war/jar包，部署在一台服务器上运行。

通俗理解：一个项目、一个包、一台服务器、包含所有功能。

1.2 诞生背景

互联网早期、初创项目、小型内部系统，用户量少、并发低、业务简单，开发人员少，不需要复杂架构。例如：小型企业考勤系统、个人博客、初创简易商城。

1.3 单体架构优点

• 开发简单：代码集中，结构简单，IDE调试方便，新手容易上手

• 部署便捷：仅需打包一个文件，一键部署，无需复杂配置

• 运维成本低：只维护一台服务器、一个项目

• 无网络损耗：模块内部本地调用，没有网络传输延迟，事务容易保证

1.4 出现的问题

随着业务发展、用户量增加，单体架构的致命缺陷全部暴露：

1. 单点故障风险：只有一台服务器，服务器宕机、程序报错，整个系统直接瘫痪

2. 并发能力差：单台服务器硬件资源有限（CPU、内存），高并发场景下卡顿、崩溃

3. 代码严重耦合：所有功能在一个工程，代码臃肿，修改一个功能容易影响其他功能

4. 扩容成本高：只能升级服务器硬件（纵向扩容），硬件有物理上限，且昂贵

5. 发布效率低：哪怕只修改一行代码，也要整体重新打包、部署、重启

1.5 解决方案

为了解决单点故障、单服务器并发上限 问题，引入集群架构。

2. 集群架构

2.1 名词定义

集群架构 ：把同一个项目，复制多份，部署到多台服务器上，每台服务器运行一模一样的代码，配合负载均衡器分发请求。

通俗理解：复制多台一模一样的服务器，干一样的活，分担压力。

2.2 为什么需要集群

针对性解决单体架构两大痛点：

1. 解决单点故障：一台服务器宕机，其他服务器正常工作，系统不会瘫痪

2. 提升并发能力：多台服务器共同承接用户请求，横向扩容，突破单台硬件限制

2.3 集群架构新增问题

集群只是简单复制项目，没有改变代码结构，旧问题仍存在，还诞生新问题：

1. 代码耦合问题依旧存在：代码还是一坨，维护、修改困难

2. 会话共享问题：用户第一次访问服务器A，第二次访问服务器B，登录状态丢失（Session不一致）

3. 资源浪费严重：商城中订单模块并发高、后台管理模块并发低，集群全部扩容，低访问模块浪费服务器资源

4. 数据库瓶颈未解决：集群所有服务共用一个数据库，高并发下数据库最先崩溃

2.4 解决方案

• 临时优化：引入Redis做Session共享，解决登录状态不一致问题；
• 架构升级：拆分项目，把不同业务拆分开，引出分布式架构。

3. 分布式架构

3.1 名词定义

分布式架构：按照业务功能，将一个大项目拆分成多个独立的子项目（子服务），每个子服务单独部署在服务器上，各司其职，通过网络互相调用。

通俗理解：拆分业务，用户服务管登录注册、订单服务管下单、商品服务管商品，各司其职，远程通信协作。

3.2 为什么需要分布式

1. 解耦代码：业务拆分，修改订单代码不会影响用户、商品模块

2. 精准扩容：哪个服务并发高，就单独扩容哪个服务，不浪费服务器资源

3. 开发协作高效：不同团队开发不同服务，代码互不干扰，不会出现代码冲突

3.3 分布式架构新增问题

分布式解决了代码耦合问题，但把本地调用变成远程网络调用，引出大量全新难题：

1. 服务调用复杂：服务A调用服务B，需要知道对方地址、端口，硬编码维护极其麻烦

2. 服务雪崩风险：某一个服务宕机，调用它的上游服务全部阻塞，连锁崩溃

3. 分布式事务问题：跨服务操作数据库，无法保证数据一致性（如下单扣钱、库存不同步）

4. 配置管理混乱：服务越多，配置文件越多，修改配置需要逐个重启服务

5. 监控排查困难：一次请求跨多个服务，报错后难以追踪问题位置

3.4 解决方案

分布式需要一套完整的工具链治理服务，而微服务架构就是规范化、标准化的分布式架构，SpringCloud应运而生。

4. 微服务架构

4.1 名词定义

微服务架构 ：是精细化、标准化、可治理的分布式架构。将业务拆分为粒度更小、独立自治的服务，每个服务职责单一、独立部署、独立数据库，搭配完善的服务治理组件（注册中心、网关、熔断、配置中心等）。

4.2 分布式和微服务的区别

• 分布式：是一种思想，只要项目拆分部署、远程调用，就是分布式，没有严格规范

• 微服务：是分布式的最佳实践，拆分更细、规范严格、自带完整治理体系

简单总结：微服务一定是分布式，分布式不一定是微服务。

4.3 为什么需要微服务

专门解决分布式架构的治理难题，提供全套解决方案：

1. 服务注册发现：不用硬编码地址，自动感知服务上下线

2. 熔断降级限流：防止服务宕机引发雪崩，保障系统稳定性

3. 统一网关：统一拦截请求，做鉴权、限流、路由

4. 统一配置中心：集中管理所有服务配置，动态刷新无需重启服务

5. 链路追踪：可视化追踪请求链路，快速排查分布式报错