从零理解他人构建的基础设施架构
一、概述
1. 背景
当你接手一个由他人构建的基础设施系统时，快速理解其架构和工作原理是 SRE（站点可靠性工程师）的核心能力。这种能力决定了你排查问题的效率和系统改进的质量。
2. 核心价值
- 快速定位问题根因，减少故障恢复时间
- 识别系统瓶颈和潜在风险点
- 制定合理的优化和重构方案
3. 适用场景
- 接手遗留系统
- 跨团队协作排查问题
- 系统迁移和重构
二、理解基础设施的四步法
1. 从入口开始，向内追踪流量
A. 确定系统入口
入口是所有外部请求进入系统的第一道关口，包括：
- API Gateway（API 网关）
- Load Balancer（负载均衡器）
- CDN 边缘节点
- Ingress Controller（Kubernetes 入口控制器）
B. 流量追踪方法
- 请求链路追踪：使用 Jaeger、Zipkin、SkyWalking 等工具
- 网络抓包：tcpdump、Wireshark 分析网络流量
- 日志分析：从访问日志中提取请求路径
- 配置文件：阅读 Nginx、HAProxy、Envoy 等配置
C. 流量路径图
graph LR
A[外部请求] --> B[CDN]
B --> C[负载均衡]
C --> D[API 网关]
D --> E[服务 A]
D --> F[服务 B]
E --> G[缓存层]
F --> G
E --> H[数据库]
F --> H
D. 关键检查点
- 路由规则：哪些 URL 路径映射到哪些服务
- 认证鉴权：请求如何验证身份和权限
- 限流熔断：如何保护后端服务
- 负载均衡策略：轮询、最少连接、一致性哈希
2. 定位状态存储位置
A. 状态类型识别
系统状态通常存储在以下位置：
| 存储类型 | 典型技术 | 用途 |
|---|---|---|
| 关系型数据库 | MySQL、PostgreSQL | 持久化数据、事务 |
| 缓存 | Redis、Memcached | 热数据、会话 |
| 消息队列 | Kafka、RabbitMQ | 异步处理、事件流 |
| 对象存储 | S3、MinIO | 文件、图片 |
| 搜索引擎 | Elasticsearch | 全文检索、日志 |
B. 状态发现方法
- 配置文件：检查数据库连接字符串、缓存配置
- 依赖注入：查看代码中的服务依赖
- 网络连接：使用 netstat、ss 查看活跃连接
- 服务发现：Consul、Etcd、Kubernetes Service
C. 状态依赖图
graph TB
subgraph 应用层
App[应用服务]
end
subgraph 数据层
DB[(数据库)]
Cache[(缓存)]
Queue[(消息队列)]
Search[(搜索引擎)]
end
App -->|读写| DB
App -->|查询| Cache
App -->|发送/消费| Queue
App -->|搜索| Search
D. 关键问题
- 数据一致性：如何保证多个数据源的同步
- 缓存策略：穿透、击穿、雪崩的防护措施
- 队列消费：重试机制、死信队列处理
- 备份恢复：数据备份和灾难恢复方案
3. 阅读 CI/CD 流水线
A. 为什么 CI/CD 重要
CI/CD 流水线反映了团队真正关心的内容：
- 测试重点：哪些模块有完整的测试覆盖
- 部署策略：蓝绿部署、金丝雀发布、滚动更新
- 依赖管理：第三方库的版本和升级策略
- 监控告警：部署后的健康检查和告警配置
B. CI/CD 配置文件位置
- GitHub Actions：
.github/workflows/ - GitLab CI：
.gitlab-ci.yml - Jenkins：
Jenkinsfile - CircleCI：
.circleci/config.yml - ArgoCD：ArgoCD Application 配置
C. 流水线阶段分析
graph LR
A[代码提交] --> B[代码检查]
B --> C[单元测试]
C --> D[构建镜像]
D --> E[安全扫描]
E --> F[集成测试]
F --> G[预发布部署]
G --> H{人工审批}
H -->|通过| I[生产部署]
H -->|拒绝| J[回滚]
D. 关键检查项
- 构建步骤：如何编译和打包应用
- 测试覆盖：单元测试、集成测试、端到端测试
- 环境配置：开发、测试、预发布、生产环境差异
- 部署策略：如何灰度和回滚
4. 深入关键组件
A. 组件优先级排序
根据以下因素确定深入顺序：
- 故障影响：组件故障对业务的影响程度
- 调用频率：被其他服务依赖的数量
- 复杂程度：代码和配置的复杂度
- 历史问题：过往故障和问题的频率
B. 组件分析方法
- 架构文档：系统设计文档、API 文档
- 源代码：关键路径和核心逻辑
- 运行状态：日志、指标、链路追踪
- 监控大盘：Grafana、Kibana、告警规则
C. 组件交互分析
sequenceDiagram
participant U as 用户
participant G as 网关
participant A as 认证服务
participant B as 业务服务
participant D as 数据库
U->>G: 发起请求
G->>A: 验证令牌
A-->>G: 验证结果
G->>B: 转发请求
B->>D: 查询数据
D-->>B: 返回数据
B-->>G: 响应结果
G-->>U: 返回响应
D. 关键问题
- 服务边界：每个服务的职责和边界
- 通信协议：REST、gRPC、GraphQL、消息队列
- 错误处理：超时、重试、降级、熔断
- 数据流：请求和响应的完整路径
三、实战检查清单
1. 入口层检查
- [ ] 确认所有入口点（API 网关、负载均衡、CDN）
- [ ] 绘制流量路径图
- [ ] 检查路由规则和转发策略
- [ ] 验证认证鉴权配置
- [ ] 测试限流和熔断机制
2. 数据层检查
- [ ] 列出所有数据存储系统
- [ ] 绘制数据依赖图
- [ ] 检查连接池和超时配置
- [ ] 验证备份和恢复策略
- [ ] 测试故障转移机制
3. 部署流程检查
- [ ] 阅读 CI/CD 配置文件
- [ ] 理解部署策略和步骤
- [ ] 检查环境配置差异
- [ ] 验证回滚机制
- [ ] 测试完整部署流程
4. 监控告警检查
- [ ] 查看监控大盘
- [ ] 理解关键指标含义
- [ ] 检查告警规则和阈值
- [ ] 验证告警通知渠道
- [ ] 测试故障响应流程
四、常见陷阱与建议
1. 常见陷阱
A. 过度依赖文档
- 问题：文档可能过时或不完整
- 建议：以代码和配置为准，文档为辅
B. 忽略边缘场景
- 问题：只关注正常流程，忽略异常处理
- 建议：特别关注超时、重试、降级逻辑
C. 缺少全局视角
- 问题：陷入单个组件细节，忽略整体架构
- 建议：先整体后局部，先主干后分支
D. 忽略历史问题
- 问题：不了解过去的故障和改进
- 建议：阅读故障复盘报告和问题追踪记录
2. 最佳实践建议
A. 建立可视化文档
- 使用架构图、流程图、时序图
- 保持图表与代码同步更新
- 使用 C4 模型、UML 等标准方法
B. 记录决策过程
- 为什么选择这种架构
- 为什么使用这种技术
- 为什么这样配置参数
C. 建立知识库
- 维护常见问题 FAQ
- 记录故障处理手册
- 分享最佳实践文档
D. 定期复盘
- 每次故障后更新架构理解
- 定期评审架构文档准确性
- 持续改进可视化工具
五、工具推荐
1. 架构可视化工具
| 工具 | 用途 | 特点 |
|---|---|---|
| Mermaid | 绘制架构图 | 简单易用，支持多种图表 |
| PlantUML | UML 建模 | 功能强大，适合复杂系统 |
| Draw.io | 在线绘图 | 免费，支持导出多种格式 |
| C4 Model | 架构建模 | 专为软件系统设计 |
2. 链路追踪工具
| 工具 | 特点 | 适用场景 |
|---|---|---|
| Jaeger | 开源，兼容 OpenTelemetry | 微服务架构 |
| Zipkin | 轻量级 | 中小型系统 |
| SkyWalking | 国产，功能全面 | 需要深度监控 |
| Datadog APM | 商业产品，易用 | 对成本不敏感 |
3. 依赖分析工具
dep：Go 依赖分析mvn dependency:tree：Maven 依赖树npm ls：Node.js 依赖树pdm lock：Python 依赖锁定
六、总结
理解他人构建的基础设施是一项系统性工程，需要从流量入口、状态存储、CI/CD 流水线和关键组件四个维度入手。通过绘制架构图、分析配置文件、阅读源代码和监控数据，可以快速建立对系统的整体认知。
关键要点：
- 从入口开始，逐层向内追踪流量
- 定位所有状态存储，理解数据依赖
- 通过 CI/CD 理解团队关注点
- 深入关键组件，掌握核心逻辑
- 建立可视化文档，持续更新维护
这套方法不仅适用于接手遗留系统，也适用于日常的系统维护和优化工作。