架构演变 之 超市进化

1. 单机架构 → 小卖部（夫妻店）

• 场景：一个老板包揽所有工作——进货、摆货、收银、打扫，店里只有一个小仓库。
• 对应架构：所有功能（数据库、业务逻辑、页面）都挤在一台服务器上。
• 问题：
  • 人一多就排队（并发差）；
  • 老板生病/仓库着火，店直接关门（单点故障）；
  • 想卖更多东西？只能把小仓库塞爆（性能瓶颈）。

---

2. 分层架构 → 中型超市（分部门协作）

• 场景：超市大了，老板雇了员工，分成了 前台收银组、理货组、仓库管理组。
  • 前台：只负责收银（用户界面层）；
  • 理货组：处理商品上架、促销（业务逻辑层）；
  • 仓库组：管库存和进货（数据库层）。
• 对应架构：系统分三层（表现层、逻辑层、数据层），各层独立。
• 优点：
  • 分工明确，招人容易（维护方便）；
  • 仓库爆了可以租隔壁仓库（数据库单独扩容）。
• 缺点：
  • 部门间得频繁沟通（层间调用多，性能损耗）；
  • 促销活动需要三个部门一起改（耦合度高）。

---

3. 微服务架构 → 大型连锁超市（独立业务线）

• 场景：超市变成连锁品牌，每条业务线独立运营：
  • 生鲜区：自己管进货、定价、促销；
  • 日用品区：单独管理库存和配送；
  • 收银系统：统一对接所有区域。
• 对应架构：每个业务拆成独立服务（用户服务、订单服务、支付服务），通过API交互。
• 优点：
  • 生鲜区坏了，日用品区照常营业（容错性强）；
  • 生鲜区可以自己升级冷链系统（独立部署）。
• 缺点：
  • 各区域要协调促销活动（服务间通信复杂）；
  • 总部的监控中心必须盯着所有区域（需要分布式监控）。

---

4. 分布式架构 → 全国连锁超市（多地分仓）

• 场景：超市覆盖全国，每个城市有分店和仓库：
  • 北京店：服务北方用户，库存从华北仓调货；
  • 上海店：服务南方用户，库存从华东仓调货；
  • 总部同步各仓库存，避免超卖。
• 对应架构：数据库和服务器分散在多地，数据同步（如MySQL主从复制、Redis集群）。
• 优点：
  • 北京用户不用从上海调货（低延迟）；
  • 华北仓着火，华东仓能顶替（高可用）。
• 缺点：
  • 总部得确保各仓库存一致（数据一致性难题）；
  • 建分仓成本高（服务器和运维成本翻倍）。

---

5. Serverless架构 → 临时快闪店（外包按需雇人）

• 场景：超市在圣诞节临时开个快闪店：
  • 不雇长期员工，按当天客流量临时找兼职；
  • 卖完就撤场，不操心后续运维。
• 对应架构：代码丢给云平台，按调用次数计费（如AWS Lambda）。
• 优点：
  • 不用养员工（省服务器成本）；
  • 突然来1000个顾客？平台自动派兼职（自动扩容）。
• 缺点：
  • 快闪店只能卖圣诞商品（适合短期/特定场景）。

---

总结：超市规模决定架构选择

超市阶段	对应架构	核心矛盾
小卖部	单机架构	规模小但扛不住风险
中型分部门超市	分层架构	分工明确但协作效率低
大型连锁超市	微服务架构	灵活但管理成本高
全国分仓超市	分布式架构	抗压但数据同步难
临时快闪店	Serverless	省心但受限于场景

补充说明

1. 什么情况下微服务内部用单体架构？

• 场景：业务简单，代码量少，比如一个“用户积分计算服务”。
• 特点：
  • 代码不分层，所有逻辑堆在一起（比如直接在一个类里处理请求、计算积分、写数据库）；
  • 不拆分模块，没有明确的接口隔离；
  • 适合快速开发，小团队维护。

2. 什么情况下微服务内部用分层架构？

• 场景：业务复杂，需要多人协作，比如“订单服务”包含下单、支付、退款等多个子模块。
• 特点：
  • 分层：比如分Controller（接请求）、Service（业务逻辑）、DAO（操作数据库）；
  • 模块化：按功能拆包，比如order.controller、order.service、order.repository；
  • 依赖隔离：Service层不直接操作数据库，通过接口调用DAO层。
• 注意点：
• 接口层（Controller/API）：仅处理请求/响应、参数校验；
• 业务层（Service）：核心逻辑，禁止直接操作数据库；
• 数据层（Repository/DAO）：仅负责数据库/外部API调用。

---

-微服务架构下的每个服务，可以是单体，也可以是分层架构
-使用Serverless→ 通常不分层，一个函数干一件事。