📚 课程目录第4章系统分层与边界

第4章系统分层与边界：接入层、业务层、数据层、基础设施层的职责划分

4.1 分层的本质与边界价值

在复杂企业级解决方案中，分层架构是控制复杂度、实现关注点分离的核心手段。每层只关注自身职责，通过明确定义的接口与相邻层通信，从而形成清晰的边界契约。分层带来的核心价值包括：

职责隔离：每层变更不影响其他层，降低重构成本。
复用性：基础能力（如认证、缓存）被上层共享调用。
可测试性：层间通过 Mock 接口独立验证，提升测试效率。
安全纵深：信任链路逐层传递，每一层都实施独立的访问控制。

  边界设计第一原则： 层与层之间只通过“接口契约”通信，禁止跨层直接访问数据或资源。接入层不能绕过业务层直接操作数据库，基础设施层不能感知业务语义。

4.2 四层架构总览与职责边界

下图展示解决方案的四层纵向切分，以及三类关键交互：数据流（请求方向）、控制流（管理方向）、信任链路（身份传递）。

4.3 各层核心职责与边界约束

下表从核心职责、关键组件、边界约束三个维度定义每一层，确保团队在协同开发时不越界、不重叠。

层级	核心职责	关键组件	边界约束
接入层	协议转换、请求路由、身份认证、流量防护	API 网关、负载均衡器、WAF 防火墙	不处理业务逻辑；不直接访问数据库或缓存
业务层	业务规则编排、事务管理、事件驱动、数据聚合	微服务、工作流引擎、消息队列	不对外暴露原生接口；不管理数据持久化细节
数据层	数据存储、缓存加速、备份恢复、数据完整性	关系数据库、Redis、对象存储	不包含业务逻辑；不直接对外提供 API
基础设施层	资源调度、监控告警、日志收集、容器编排	Kubernetes、Prometheus、ELK Stack	不感知业务语义；不处理应用层数据格式

边界检查技巧： 在架构评审时，用“这个组件是否做了不属于本层的事？”作为快速扫描问题。例如：业务层代码中出现了 SQL 语句，即属于越界行为，应下沉到数据层 DAO 或 Repository。

4.4 层间交互：数据流、控制流与信任链路

层间交互是边界设计的“胶水”，必须明确定义方向、协议、安全机制，否则分层架构会退化成“散装泥球”。

交互类型	方向	协议 / 载体	安全要求
数据流（请求）	接入层 → 业务层 → 数据层 → 基础设施层	HTTP/REST、gRPC、消息队列	TLS 加密传输；API Key 或 JWT 鉴权
控制流（管理）	基础设施层 → 数据层 → 业务层 → 接入层	带外管理接口、SSH、K8s API	双向 TLS（mTLS）；最小权限策略
信任链路	垂直贯穿所有层	JWT、OAuth2、SAML	签名验证；时效控制；逐层 Scope 缩减

信任链路设计要点： 用户身份在接入层完成认证后，生成包含 Role/Scope 的 JWT，业务层根据 Scope 判断是否允许操作，数据层根据 Role 过滤返回行级数据。每层只信任直接上游传递的凭证，不跨层信任。

常见陷阱： 信任链路“扁平化”会导致安全漏洞。例如：接入层认证后，业务层直接信任上游传递的 userId 而不重新校验，攻击者可通过篡改请求头越权操作。正确的做法是业务层使用 JWT 签名校验，而非直接信任 HTTP Header。

4.5 选型权衡与关键决策

每层的技术选型直接影响边界清晰度和团队协同效率。以下对比帮助架构师做出权衡决策：

决策维度	选项 A	选项 B	推荐场景
接入层网关	Kong / APISIX（功能丰富）	Nginx + Lua（轻量定制）	团队规模大选 A；极简团队选 B
业务层通信	gRPC（高性能、强类型）	REST（生态兼容、调试方便）	内部服务间选 gRPC；外部暴露选 REST
数据层缓存	Redis Cluster（高可用）	Local Cache（低延迟、无网络开销）	多节点共享数据选 Cluster；单节点高频读选 Local
基础设施编排	Kubernetes（生态标准）	Nomad / Docker Swarm（轻量运维）	复杂微服务选 K8s；中小规模选 Nomad

4.6 关键风险点与异常处理

分层架构在落地过程中，常因边界模糊或协同不规范引入风险。下表列出高频风险及应对措施：

风险点	症状	根因	异常处理措施
层间接口膨胀	每次需求变更需改多层接口	接口契约粒度太细，未聚合	引入 BFF（Backend For Frontend）做接口聚合，减少层间调用次数
跨层直接访问	业务层代码中出现 SQL/HQL	缺乏代码审查或架构守护	启用 ArchUnit / 自定义 Linter 规则，禁止业务层依赖数据层实现
信任链路断裂	跨层调用返回 403/401	JWT Scope 未逐层传递或签名密钥不统一	统一 Token 签发中心，每层使用公共验证库，避免重复解析
数据流循环依赖	层 A 调用层 B，层 B 又回调层 A	业务逻辑未正确分层，双向依赖	引入事件驱动（消息队列）解耦，将循环依赖改为异步发布/订阅

  架构守护自动化： 在 CI 流水线中增加“分层依赖检查”步骤，使用工具（如 ArchUnit、Structure101）自动校验代码依赖方向，违反则构建失败。这是从流程上强制边界纪律的有效手段。

4.7 落地实施步骤（协同流程）

以下操作步骤定义架构师、各层负责人、质量保障在分层落地中的协同流程，包含输入/输出物：

输出分层架构设计文档（架构师）
输入：需求说明书、非功能需求（QPS、延迟、可用性）
输出：layered-architecture-v1.md，包含层定义、接口契约、数据流图谱
各层负责人评审边界（各层 TL）
输入：分层设计文档
输出：评审签字确认的边界划分清单，boundary-checklist.xlsx
定义层间接口契约（架构师 + 各层 TL）
输入：边界清单
输出：Protobuf / OpenAPI 定义文件，api-contract/ 目录
输出数据流与控制流图谱（架构师）
输入：接口契约文件
输出：data-flow-diagram.svg、control-flow-table.md
制定信任链路安全策略（安全工程师）
输入：数据流图谱
输出：trust-chain-policy.md，包含 JWT 结构、Scope 列表、签名算法
各层并行原型开发（各层开发团队）
输入：接口契约、安全策略
输出：各层 Mock 服务 + 单元测试，mock/ 目录
集成联调验证边界（质量保障）
输入：各层 Mock 服务
输出：集成测试报告 integration-report.md，包含边界违规问题清单

4.8 验收标准与检查表

以下检查表用于验收分层边界是否清晰、交互是否规范：

#	验收项	验收标准	状态
1	各层职责无重叠	任意一个组件只属于一个层级，没有跨层归属模糊	□ 通过 □ 整改
2	层间接口已定义	所有跨层调用都有 Protobuf 或 OpenAPI 定义，且版本化管理	□ 通过 □ 整改
3	数据流完整覆盖	从用户请求到数据返回的所有路径都已映射到对应层，无遗漏	□ 通过 □ 整改
4	控制流可观测	监控告警、日志收集、运维指令都能追溯到具体层级和组件	□ 通过 □ 整改
5	信任链路安全	JWT 签名已验证、Scope 逐层缩减、无明文传递敏感字段	□ 通过 □ 整改
6	无跨层直接依赖	代码依赖分析工具未检测到业务层直接引用数据层实现类	□ 通过 □ 整改

验收执行建议： 在集成测试阶段，使用“混沌工程”方式随机中断某层服务，观察上下游是否按边界隔离（例如：数据库宕机时，业务层应返回降级响应而非穿透到接入层）。

4.9 边界示例：接入层网关配置

以下 Nginx 配置片段展示接入层如何通过反向代理、认证拦截、路由分发实现边界职责，不侵入业务逻辑：

# 接入层 - API 网关边界配置示例
server {
    listen 443 ssl;
    server_name api.example.com;

    # TLS 终止（接入层职责）
    ssl_certificate /etc/ssl/certs/api.crt;
    ssl_certificate_key /etc/ssl/private/api.key;

    # 身份认证拦截（接入层边界）
    location /api/ {
        auth_request /auth;
        auth_request_set $auth_user_id $upstream_http_x_user_id;

        # 路由到业务层（不直接访问数据库）
        proxy_pass http://business-cluster:8080/;
        proxy_set_header X-User-ID $auth_user_id;
        proxy_set_header X-Request-ID $request_id;
    }

    # 认证端点（内部调用，不对外暴露）
    location = /auth {
        internal;
        proxy_pass http://auth-service:8081/verify;
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
    }

    # 健康检查（不经过业务层）
    location /health {
        return 200 "OK";
        add_header Content-Type text/plain;
    }
}

该配置严格遵循接入层边界：只做 TLS 终止、认证拦截、路由转发，不包含任何业务逻辑或数据库查询。业务层只需信任 X-User-ID 头（配合 JWT 签名校验），实现层间解耦。

📚 课程目录

第4章 系统分层与边界：接入层、业务层、数据层、基础设施层的职责划分

4.1 分层的本质与边界价值

4.2 四层架构总览与职责边界

4.3 各层核心职责与边界约束

4.4 层间交互：数据流、控制流与信任链路

4.5 选型权衡与关键决策

4.6 关键风险点与异常处理

4.7 落地实施步骤（协同流程）

4.8 验收标准与检查表

4.9 边界示例：接入层网关配置

第4章系统分层与边界：接入层、业务层、数据层、基础设施层的职责划分