2.8c 架构设计
← 2.8b 后端开发 | 首页 | 下一节: 2.8d 基础设施 →
- API 架构：
- 标准：REST（资源导向，无状态，利用 HTTP 方法语义）、SOAP（协议导向，XML 消息格式，强类型契约）。
- 安全性：速率限制防爬虫、CAPTCHA 防机器攻击、OAuth 2.0 / API Key 认证。
- 弹性：断路器模式（Circuit Breaker）——第三方服务故障时，临时熔断该依赖的调用，快速失败而非长时间等待，防止级联故障。
- 外部化配置（Externalized Configuration）：将配置（数据库连接串、开关等）从代码中分离到环境变量、配置中心，使同一份构建产物可部署到不同环境。
- 一切皆代码（Everything as Code）：将基础设施（Terraform, Ansible, Docker, K8s）、配置、文档（Markdown + CI 检查）、培训内容全部以代码形式管理。好处：单一真实来源、Peer Review、版本历史、CI/CD 自动化、打破团队壁垒。
- 单体 vs 微服务：
- 单体：简单部署、易调试，但大型单体耦合严重、扩展困难。
- 微服务：独立部署、独立扩展、技术栈自由，但引入分布式复杂度（网络延迟、数据一致性、服务发现）。
- 领域驱动设计（DDD）：围绕业务领域建模，关注限界上下文（Bounded Context）、聚合（Aggregate）、实体（Entity）、值对象（Value Object）、领域事件（Domain Event）。
- 六边形架构（端口与适配器）：将核心业务逻辑与外部依赖（数据库、UI、第三方 API）隔离，通过端口（Port）和适配器（Adapter）连接。
- 数据建模：创建信息系统的数据模型的过程。三个层次：
- 概念模型：技术无关的业务数据描述，与利益相关者讨论需求。
- 逻辑模型：转化为可实现的表/列/类结构。
- 物理模型：考虑分区、索引、存储等具体实现细节。 数据模型是动态文档，随业务变化演进。常用方法：ERD、UML 类图、IDEF1X。
- Service Mesh：微服务通信基础设施层，处理服务间流量管理、负载均衡、服务发现、重试/超时、可观测性，让业务代码不感知网络层。
- 关键协议理解：HTTP/HTTPS（应用层）、TCP/UDP（传输层）、LDAP（目录服务）、SSH（安全远程）、SMTP（邮件）。
来源
- Romén Rodríguez-Gil — Everything 'As-code': https://www.romenrg.com/blog/2019/12/31/everything-as-code/
- Wikipedia — Data modeling: https://en.wikipedia.org/wiki/Data_modeling