第3章 系统顶层架构分层：接入层、业务层、数据层、基础设施层
3.1 系统边界与分层原则
系统顶层架构的核心在于 关注点分离 与 边界定义。本章将架构划分为四个基本层次：接入层、业务层、数据层、基础设施层。每一层都有明确的职责边界，通过定义清晰的接口契约（通常是API或消息协议）进行交互，从而降低耦合，便于独立迭代与原型快速验证。
关键原则：
- 单向依赖：上层依赖下层，下层不依赖上层。例如，业务层可以依赖数据层，但数据层不能反向依赖业务层。
- 职责内聚：每一层只处理本层关注的问题，不越权。
- 接口稳定：层间接口在设计初期即需达成一致，原型实现时应优先mock或stub下层服务以验证上层逻辑。
3.2 分层职责与模块职责
| 架构层 | 核心职责 | 典型模块/组件 | 关注点 |
|---|---|---|---|
| 接入层 | 终端用户/外部系统的入口点，处理协议适配、请求路由、身份认证、限流熔断。 | API Gateway、负载均衡器、反向代理（Nginx / Envoy）、WebSocket 网关 | 安全、流量控制、协议转换 |
| 业务层 | 核心业务逻辑编排、领域模型管理、工作流调度、业务完整性校验。 | 微服务实例、业务编排引擎、消息分发器、状态机 | 高内聚、低耦合、事务边界 |
| 数据层 | 数据持久化、缓存、索引、实时/批量计算、数据一致性保障。 | 关系型数据库、NoSQL、消息队列、搜索引擎、缓存集群 | 数据一致性、性能、容量规划 |
| 基础设施层 | 提供计算、存储、网络、监控、部署和运维能力。 | Kubernetes / Docker、对象存储、监控告警、CI/CD、服务网格 | 弹性、可观测性、成本控制 |
3.3 数据流 / 控制流 / 信任链路
理解分层架构的运行时行为，需要区分三组关键流：
- 数据流：从接入层接收请求，经业务层处理，最终流向数据层进行持久化或返回结果。数据在层间传递时需保持完整性，原型中可用简单JSON或Protobuf验证。
- 控制流：主要存在于接入层到业务层之间，用于负载均衡、熔断、限流等策略。在原型阶段，可以模拟控制流配置以验证降级策略。
- 信任链路：接入层与外部系统之间，业务层与数据层之间。接入层负责外部信任（Token/JWT），业务层依赖数据层内置的访问控制。
原型匹配要点：在原型实现中，可以使用Mock技术快速模拟下层服务。例如，业务层原型可以预先定义数据层接口，并返回固定的模拟数据，从而避免过早引入数据库基础设施。
3.4 方案选型权衡
- 接入层：自研Gateway vs. 开源方案（如Kong、APISIX）。自研灵活性高，但原型阶段开源方案更快捷。
- 业务层：单体 vs. 微服务。原型阶段推荐单体架构+模块化分包，避免分布式复杂性拖慢验证。
- 数据层：关系型 vs. NoSQL。根据业务查询模式和数据一致性要求做取舍。原型阶段优先使用轻量级数据库（如SQLite in-memory模式）。
- 基础设施层：物理机 vs. 容器化。原型阶段可使用docker-compose本地部署，快速启动环境。
关键风险点：分层不当会导致“共享层”现象，即业务逻辑渗透到数据层或接入层。在原型期需要建立严格的层间接口评审机制，避免后期重构成本急剧上升。
3.5 落地步骤
- 定义层间接口契约：使用OpenAPI或Protobuf定义接入层→业务层、业务层→数据层的接口。
- 构建基础设施层原型：配置docker-compose环境，包含必要的中间件（如Redis、MySQL in-memory）。
- 实现数据层Stub：使用内存数据结构或本地文件模拟数据库操作。
- 实现业务层核心逻辑：不依赖真实数据，直接调用Stub。
- 接入层验证：使用curl或Postman测试Gateway路由与鉴权流程。
- 集成测试并调整分层边界：检查是否存在逻辑泄漏或依赖循环。
3.6 原型实现匹配要点
- 接入层：使用Nginx或轻量级网关（如Express Gateway）模拟请求转发。
- 业务层：采用工厂模式+策略模式，便于未来快速替换为微服务。
- 数据层：使用Repository模式封装数据访问，确保替换存储引擎时不污染业务代码。
- 基础设施层：使用Kubernetes Minikube本地集群验证服务发现和水平扩缩。
3.7 验收标准
- 接入层能正确路由请求并执行基本鉴权。
- 业务层能独立部署，并通过Stub完成业务流程。
- 数据层接口清晰，切换存储方案无需改动业务层代码。
- 基础设施层（容器化环境）一键启动，原型环境可重复搭建。