系统（项目），网络，硬件运维
单体架构和微服务架构
|------|------------|----------------|
| 对比项 | 单体项目 | 微服务（多体） |
| 代码工程 | 1个工程 | 多个独立工程 |
| 部署 | 打1个jar包 | 每个服务各自打包 |
| 数据库 | 通常共用一个库 | 每个服务独立数据库 |
| 调用方式 | 本地方法调用 | 远程http/feign调用 |
| 修改上线 | 改一点，全部重新部署 | 只部署被修改的服务 |
| 本地启动 | 启动1次 | 要启动多个服务 |
| 学习难度 | 低，适合练手 | 高，需要学中间件 |
| 并发扩容 | 整体扩容 | 按需单独扩容某个服务 |
集群 vs 微服务（面试背诵，通俗版）
一、
集群：同一套程序，部署多份，多台机器一起跑【复制副本】
简单类比
• 单体集群：同一个饭店，雇2个一模一样的厨师，两个人都能做全套菜（副本扩容）
• 微服务：饭店拆分岗位，切菜的、炒菜的、收银的，各司其职；每个岗位还可以集群（切菜可以雇2个人）
✅ 重点：微服务里面每个服务本身，都可以做集群！两者不冲突，不是二选一
二、微服务架构优点（面试口述版）
1.服务解耦：各个业务互不影响。改订单代码，不用动用户服务。
2.独立开发、独立发布：单个服务可以单独上线、单独回滚，不用整体打包发布。
3.独立扩容：哪个模块压力大，单独扩容哪个。比如秒杀只有订单压力大，只扩容订单服务，不用扩容整个系统。
4.技术栈灵活：不同服务可以选合适技术（用户服务Java，搜索可以用Go）
5.故障隔离：订单服务崩了，用户、商品服务还能正常跑，不会整体宕机。
6.团队拆分：大团队可以按服务拆分小组，各司其职并行开发。
三、微服务缺点（面试官大概率追问，一起背）
1.架构复杂，引入很多组件：Nacos注册中心、网关、远程调用、分布式事务、链路追踪
2.运维成本高，服务多，部署监控麻烦
3.网络调用：服务之间远程调用，有网络延迟，要处理超时、重试
重点!
三种系统的具体分析
单体集群，分布式，微服务。
- 单体项目部署3台机器做负载均衡
👉 集群，不是分布式，不是微服务
- 一台电脑启动 order、storage、account三个服务，多进程，没有多实例副本(也可以有)
👉 分布式、微服务，无集群(也可以有)
- 你的cloud‑demo项目：order2个实例，storage2个实例，服务之间互相Feign调用
👉 同时具备：集群 + 分布式 + 微服务(只是提现每块服务具体拆分)
单体架构:
就是不拆分服务，把一整套系统部署到同一个服务器上(一般java只有一个启动类来同时启动三个服务模块)。(也可以集群)
分布式架构:
只是把每个服务拆开了(每个服务单独拆分，单独部署，单独发布等)三个启动器
微服务架构:
把每一个具体服务拆的更细了。(比如Java项目的ai模块想用Python做，就把用户中的登录和会员拆分出来了)。除了java中启动类其他启动类(根据不同语言来进行启动后端各个服务)。更加灵活了。
目前云原生(架构层面)
架构的演进过程:
