Sunqy 文档库

主题

05 · 服务架构：分层 / 模块化 / 微服务 ​

代码少的时候随便写都能跑，一长大就乱。本篇讲服务端怎么组织代码：分层、模块化、微服务的演进与代价。

速览卡 ​

项内容
一句话定位从"一个文件"到"多个服务"的组织演进，以及每一步的真实代价
核心内容分层架构、模块化单体、微服务、网关与服务发现、熔断限流、演进判断
读完能回答代码该分几层？什么时候该拆微服务？网关和限流是干嘛的？
相关板块C04 · 一致性事务 ｜ C06 · 异步与消息 ｜ C08 · 可观测性

一、分层架构：后端的第一原则 ​

层职责类比前端
路由/接口层收请求、校验、返回组件/路由
业务层业务规则、编排业务逻辑层
数据访问层读写数据库Repository
text
API 层 → 业务层 → 数据访问层 → DB

核心规则：依赖只向下。业务层不该知道 HTTP，数据层不该知道业务。这样每一层都能单独测试、替换。

二、模块化单体：90% 项目的最优解 ​

在"一个大服务"里按业务切模块：

text
my-api/
├── users/        # 用户模块：路由+业务+数据访问
├── orders/       # 订单模块
├── payments/     # 支付模块
└── common/       # 共享基础设施
方案优点缺点
模块化单体简单、一致性好、易部署规模极大时耦合
微服务独立扩展、独立团队复杂度爆炸

判断：除非有"独立伸缩、独立发布、独立团队"的真实诉求，否则先模块化单体。微服务是架构债务的产物，不是起点。

三、微服务：什么时候才值得 ​

拆微服务是为了解决这几个真实痛点，缺一不可：

痛点微服务解决
单服务太大，团队互相踩脚拆开独立开发
部分模块要独立扩缩容独立部署
不同模块要不同技术栈独立实现
故障隔离一个挂了别的还活着

而它的代价是：

代价说明
分布式事务一致性变难（见 C04）
服务发现/网关谁在哪、流量怎么进
可观测性跨服务排障（见 C08）
运维部署、监控成倍

一句话：微服务把"代码复杂度"换成"运维复杂度"。小项目换不起。

四、网关与服务发现 ​

组件干什么类比
API 网关统一入口：鉴权、限流、路由、日志前端 BFF 的服务端版
服务发现服务实例在哪、健康与否注册中心 + 心跳
text
客户端 → 网关 → 订单服务
                └→ 支付服务（经服务发现找到实例）

网关把"横切关注点"（鉴权/限流/日志）从业务服务里抽走，业务代码更干净。

五、熔断与限流 ​

机制解决做法
限流流量超过处理能力按 IP/用户/接口限 QPS
熔断下游挂了别把我也拖挂连续失败即快速失败，不再调用
降级保核心功能非核心功能给兜底结果

类比前端：熔断像"接口 5xx 就停掉轮询"，降级像"图片加载失败给占位图"。

六、演进判断：一个决策框架 ​

text
项目多大？  ── 小/中 → 模块化单体（默认）
                │
              大且团队多 → 有没有独立伸缩/发布诉求？
                              有 → 微服务
                              无 → 模块化单体

进阶路径：模块化单体 → 按模块独立部署 → 需要时再拆服务。别一上来就微服务。

自检清单 ​

  • [ ] 能把一个服务按"API/业务/数据"三层组织
  • [ ] 能说出模块化单体 vs 微服务的适用边界
  • [ ] 知道微服务的四项代价（事务/服务发现/可观测/运维）
  • [ ] 能说清网关、限流、熔断、降级各解决什么
  • [ ] 用决策框架判断"我的项目要不要拆微服务"

常见误区 ​

  • 误区：微服务更先进，直接上。 它把代码复杂度换成运维复杂度，小项目是负收益。
  • 误区：分层就是多建几个目录。 分层的价值在"依赖单向、边界清晰"，不是目录好看。
  • 误区：网关只有大厂才用。 一个聚合入口在中小项目也能简化鉴权/限流。
  • 误区：熔断和限流一回事。 限流防自己过载，熔断防下游把自拖挂。

动手练习 ​

练习 A：重构分层 ​

把你现有的 Todo API 重构成 API/业务/数据三层，验证每层能独立测试。

练习 B：模块化 ​

把一个功能（如支付）拆成独立模块，定义它与其他模块的边界。

练习 C：架构评审 ​

给一个你见过的项目做架构评审：它现在是哪种形态、该不该演进、为什么。

相关文档 ​

本区 ​

其他域 ​