后端架构设计

1. 业务与场景分析

1. 明确业务边界与核心价值：
   • 这个系统解决什么问题？必须支撑的核心用例是什么？
   • 是「读多写少」还是「写多读少」、是「强事务」还是「弱一致、高可用」优先。
2. 用户与流量特征：
   • 日活 / 峰值 QPS / 并发连接数的预估与增长曲线。
   • 高峰时段（秒杀、促销、节假日）、地域分布（单区域、多区域）。
3. 非功能性需求：
   • 可用性目标（例如 99.9%、99.99%）、恢复时间 RTO / 恢复点 RPO。
   • 响应时间 SLO（p95/p99）、容量上限、数据保留周期。
4. 合规与安全：
   • 是否涉及隐私数据（手机号、身份证、医疗、金融）、合规要求（如 GDPR、等保）。
   • 审计要求（操作审计、访问日志、风控日志）。

2. 系统分层与整体架构

1. 分层架构（典型四层）：
   • 接入层：API Gateway、BFF、反向代理、负载均衡（Nginx/Envoy/API Gateway）。
   • 业务层：领域服务 / 应用服务，承载核心业务流程与领域逻辑。
   • 基础服务层：用户、订单、支付、通知等通用服务；鉴权、配置、风控等平台服务。
   • 基础设施层：数据库、缓存、消息队列、搜索引擎、对象存储、第三方服务。
2. 单体 vs 微服务 vs 模块化单体：
   • 单体：小团队、早期项目，业务频繁变化、领域边界尚不清晰。
   • 模块化单体：一个部署单元，内部按领域模块划分，清晰的模块边界和依赖。
   • 微服务：边界清晰的领域服务，独立部署、独立扩缩容，但引入分布式复杂度。
3. 同步调用与异步解耦：
   • 核心链路尽量短、稳定，避免链路过长拉低整体可用性。
   • 非核心、耗时操作（通知、报表、日志处理）尽量异步化，通过 MQ/事件总线解耦。
4. 内外部接口：
   • 内部服务接口：gRPC / 内部 HTTP API、清晰的契约与版本管理。
   • 外部开放接口：OpenAPI/REST/GraphQL，需考虑限流、鉴权、配额、灰度发布。

3. 领域建模与数据设计

1. 领域划分与上下文：
   • 识别核心子域（订单、库存、风控、计费等），划分领域边界和上下文。
   • 用「上下文映射」明确领域之间的依赖关系与集成模式（防腐层、翻译层）。
2. 领域模型与聚合设计：
   • 找出聚合根（Order、User、Product 等），控制事务边界。
   • 避免「巨型聚合」导致的锁争用与事务膨胀，按一致性需求拆分聚合。
3. 数据建模：
   • OLTP 主库：关系型数据库（MySQL/PostgreSQL），结构化交易数据。
   • OLAP / 报表：数仓、ClickHouse、ElasticSearch 等，支撑分析与搜索。
   • 规范化 vs 反规范化：交易模型偏规范化，读模型可以适度反规范化。
4. 多租户与隔离策略：
   • 逻辑隔离：同一 DB、表内加 tenant_id。
   • 物理隔离：不同 DB / 实例，适用于大客户或合规要求高的场景。
   • 中间层隔离：按租户路由到不同集群、不同资源池。

4. 存储、缓存与一致性

1. 存储选型：
   • 关系型数据库：强事务、复杂查询、主从复制、分库分表策略。
   • KV 存储 / NoSQL：高并发读写、弱事务、键值或文档数据模型。
   • 搜索引擎：ES / OpenSearch，适用于模糊查询、聚合分析。
2. 缓存策略：
   • 缓存层级：本地缓存（堆内 / 本机）、分布式缓存（Redis/Memcached）。
   • 缓存模式：旁路缓存（Cache Aside）、读写穿透（Read/Write Through）。
   • 缓存更新：TTL、异步刷新、主动失效、双写一致性方案。
3. 数据一致性与幂等：
   • 强一致 vs 最终一致：交易类场景尽量在一个聚合内完成强一致。
   • 幂等设计：请求幂等键（业务唯一号）、乐观锁、去重表、消息幂等消费。
4. 分库分表与扩展性：
   • 分片键选择：稳定性、热点避免、跨分片事务的处理策略。
   • 路由层：中间件或业务层路由逻辑，避免 SQL 写死分片逻辑。

5. 接口设计与协议

1. API 设计原则：
   • 统一风格：资源命名、HTTP 动词、状态码与错误码规范。
   • 版本管理：通过 URL、Header 或网关进行 API 版本控制。
2. 序列化协议：
   • 对外 REST/JSON 友好，易调试、生态成熟。
   • 内部可考虑 gRPC/Protobuf 提高性能与类型安全。
3. 错误处理与返回结构：
   • 统一错误码规范（业务错误码 + HTTP 状态码）。
   • 清晰的错误语义（用户可见 vs 内部日志用）。

6. 安全与权限体系

1. 身份认证：
   • 内部系统：JWT、Session、单点登录（SSO）、OAuth2.0。
   • 对外 API：API Key、签名机制、防重放、防篡改。
2. 授权与权限控制：
   • RBAC（基于角色）、ABAC（基于属性），细粒度资源权限。
   • 多租户权限隔离、超级管理员 / 租户管理员分级。
3. 数据安全：
   • 传输加密：全链路 HTTPS/TLS。
   • 存储加密：磁盘加密、字段级加密（如银行卡、身份证）。
   • 日志脱敏：对敏感字段脱敏存储，访问审计与操作留痕。

7. 性能与扩展性

1. 扩展方式：
   • 垂直扩展：提升单机配置（CPU/内存/IO）。
   • 水平扩展：多实例 + 负载均衡，服务无状态化。
2. 性能优化方向：
   • 热点路径优化：找出最频繁、最耗时的接口与 SQL。
   • 使用缓存、索引优化、读写分离、批量操作减少往返。
3. 容量规划：
   • 基于峰值流量与性能测试结果，预估实例数与资源配额。
   • 预留安全冗余（如 30% 以上），为突发流量留空间。
4. 限流与熔断：
   • 限流：按用户、IP、接口、租户等维度做 QPS/QPD 限制。
   • 熔断与降级：组件异常时快速失败、返回降级结果，保护核心链路。

8. 高可用与故障恢复

1. 冗余与备份：
   • 多实例、多可用区部署，避免单点故障。
   • 数据备份策略（全量 + 增量）、备份恢复演练。
2. 故障检测与自动恢复：
   • 健康检查：liveness/readiness 探针、心跳机制。
   • 自动拉起：服务挂掉后自动重启、自动摘除故障节点。
3. 灰度与发布策略：
   • 蓝绿发布、金丝雀发布、灰度路由控制。
   • 回滚策略：配置可回滚、版本可切换，确保故障可快速恢复。

9. 监控、日志与可观测性

1. 指标监控（Metrics）：
   • 基础资源：CPU、内存、磁盘、网络、连接数。
   • 业务指标：QPS、RT、错误率、超时率、队列堆积、订单成功率等。
2. 日志（Logs）：
   • 结构化日志：统一字段（traceId、userId、tenantId、requestId）。
   • 分级存储：访问日志、业务日志、错误日志、审计日志。
3. 链路追踪（Tracing）：
   • 使用 OpenTelemetry/Jaeger/Zipkin 等实现跨服务链路追踪。
   • 把慢调用、异常、重试链路可视化，便于排障。

10. 开发流程与工程实践

1. 代码结构：
   • 清晰的模块划分（domain、application、infra、interfaces）。
   • 统一编码规范与代码检查（lint、格式化、静态扫描）。
2. 测试策略：
   • 单元测试：核心领域逻辑必须有覆盖。
   • 集成测试：接口级联调、与外部依赖（DB/MQ/第三方）的联调。
   • 回归与冒烟测试：发布前自动化验证核心用例。
3. CI/CD：
   • 自动化构建、测试、发布流水线。
   • 不同环境（dev/test/stage/prod）的配置与发布策略。

11. 配置与环境管理

1. 配置中心：
   • 动态配置：开关位、阈值、路由规则可在线调整。
   • 配置分环境、分租户管理，支持灰度下发。
2. 多环境隔离：
   • 开发、测试、预发布、生产环境隔离，避免交叉污染。
   • 测试数据与生产数据严格隔离，权限分级。

12. 第三方依赖与集成

1. 第三方服务评估：
   • SLA、限流策略、费用、合规（是否允许存储个人数据）。
   • 失败模式：超时、错误码、返回异常数据的处理。
2. 依赖抽象与防腐层：
   • 对第三方 SDK 做适配/封装，避免业务直接依赖第三方接口细节。
   • 方便未来替换供应商或自建能力。

13. 演进规划与可维护性

1. 演进路线：
   • 从单体 → 模块化单体 → 部分微服务 → 平台化。
   • 在真实压力与业务需求驱动下渐进式拆分，而不是一开始就全微服务。
2. 可维护性：
   • 文档：接口文档、架构文档、运维手册、故障手册。
   • 代码一致性：统一技术栈、统一库版本，降低认知负担。

---

上面的这些维度，可以作为你做任何后端项目架构设计时的一张「检查清单」：从业务场景 → 架构风格 → 数据与一致性 → 安全与性能 → 高可用与可观测性 → 工程实践与演进规划，逐项思考、补齐，就能搭出一个相对完整、可落地的后端架构方案。