Loading... # 从零理解他人构建的基础设施架构 # 一、概述 ## 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. 流量路径图 ```mermaid 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. 状态依赖图 ```mermaid 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. 流水线阶段分析 ```mermaid 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. 组件交互分析 ```mermaid 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 流水线和关键组件四个维度入手。通过绘制架构图、分析配置文件、阅读源代码和监控数据，可以快速建立对系统的整体认知。 关键要点： 1. 从入口开始，逐层向内追踪流量 2. 定位所有状态存储，理解数据依赖 3. 通过 CI/CD 理解团队关注点 4. 深入关键组件，掌握核心逻辑 5. 建立可视化文档，持续更新维护 这套方法不仅适用于接手遗留系统，也适用于日常的系统维护和优化工作。 *** ## 参考资料 1. [Rohit Ghumare on X: Most valuable thing I learned from a senior SRE](https://x.com/ghumare64/status/2012587659298820470?s=20) 2. [Google SRE Book - Understanding Distributed Systems](https://sre.google/sre-book/table-of-contents/) 3. [The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win](https://itrevolution.com/book/the-phoenix-project/) 最后修改：2026 年 01 月 18 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏