IT现有架构如何重构

实际场景：旧服务器架构的整理与优化

核心痛点： 团队重建、文档缺失、旧架构凌乱、扩展性差。

1. 资产梳理环节

⭐ 面对一个完全陌生且没有文档的旧架构，你如何在不影响业务的情况下，快速梳理出完整的拓扑结构和依赖关系？

• 流量入口分析
  • DNS 与 CDN： 查阅域名的解析记录（CNAME/A记录），确定对外暴露的入口 IP。
  • 负载均衡器（SLB/Nginx）： 分析接入层的 Nginx 配置文件（/etc/nginx/conf.d/）。这是最宝贵的文档，它明确指出了：
    • 入口 URL 对应哪些后端服务器（Upstream）。
    • 流量转发规则（基于路径、域名还是权重）。
  • 出口防火墙： 查阅云厂商的安全组策略或硬件防火墙规则，看哪些端口向外开放。
• 进程与通信链梳理
  • 进程网络视图： 在各台核心服务器上执行：ss -ntlp
  • 文件描述符分析： 使用 lsof -p <PID> 查看进程打开了哪些配置文件、日志文件和 Socket 连接。
  • 配置溯源： 寻找 config.yaml, .env, properties 等配置文件。通过搜索这些文件中的 IP/域名，可以瞬间理清应用间的上下游依赖（Service Dependency）。
• 数据库依赖
  • 慢查询日志/Processlist： 在数据库上执行 SHOW PROCESSLIST 或分析 Slow Query Log，这不仅能发现性能瓶颈，还能通过连接源 IP 识别出“谁在使用这个库”。
  • 连接池配置： 检查应用侧代码或配置中的 JDBC/Redis 连接字符串，确定应用与数据库的映射关系。
• 全链路观测
  • APM 工具（链路追踪）： 如果环境允许，挂载一个轻量级的 APM（如 SkyWalking 或 OpenTelemetry Agent，选择非侵入式方式）。让它自动去“跑”一遍流量，它会自动生成一份动态拓扑图。这是最快且最准确的方式。

2. 优化重构

⭐ 在重构过程中，你会如何平衡‘系统的稳定性’与‘新技术架构的引入’？如果重构中途出现业务中断，你的回滚策略是什么？

• 使用灰度发布，平滑切换新旧系统
  • 逐步剥离： 在旧架构外围构建新架构。通过 Nginx 或网关层，将特定比例（如 1%）或特定路径（如 /api/v2）的流量切向新架构。
  • 影子测试 (Shadowing)： * 将流量同时镜像一份发送给新旧两个系统。
    • 对比两者的输出结果是否一致，但不以新系统的结果作为最终响应。
    • 作用： 在不影响用户的情况下，用真实流量验证新技术的稳定性
  • 成熟度优先： 核心组件（如 100T 数据的存储）坚持使用成熟方案（如 Ceph, MinIO）。
  • 局部试点： 新技术（如 Service Mesh）先在非核心、低负载业务中试运行 2-4 周。
• 核心回滚策略：
  • 流量回滚
    • 在负载均衡器（LVS/Nginx） 一键将流量权重从新环境切回旧环境。旧环境在重构期间必须保持热备（Warm Standby）状态。
  • 数据回滚
    • 双写（Double Write）： 在切换初期，应用层同时向旧库和新库写入数据。
    • 数据平滑退回： 如果新架构运行 10 分钟后发现逻辑错误，由于旧库也有这 10 分钟的数据，切回流量后业务可以无缝衔接。

3. 标准化后续维护

⭐ “为了防止新架构重蹈覆辙，你会引入哪些自动化工具（如 Terraform, Ansible）或流程来保证基础设施的代码化（IaC）？”

A. 资源编排层：Terraform

用于管理底层“硬”资源（如虚拟机、私有网络 VPC、存储桶、数据库实例）。

• 常用场景： 在云平台上快速创建 10 台带 10T 磁盘的服务器。
• 防止重蹈覆辙的关键： State 文件管理。通过将架构定义为 .tf 文件，任何资源的增删改都会在代码仓库（Git）中留下记录，而不是在控制台上点来点去。

B. 配置管理层：Ansible

用于管理系统内部的“软”配置（如安装 Nginx、配置 MySQL 双主、设置 100T 备份脚本）。

• 常用场景： 一键将 100 台服务器的 sshd_config 修改为统一的安全配置。
• 防止重蹈覆辙的关键： 幂等性（Idempotency）。无论执行多少次，结果都是一致的，这保证了服务器集群不会因为手动修改而产生“配置漂移”。

C. 镜像构建层：Packer

在重构 100T 大数据的环境下，数据恢复速度至关重要。

• 做法： 预先将所有优化好的内核参数、备份工具集成到 OS 镜像（AMI/QCOW2）中。
• 意义： 扩容时直接拉起镜像，无需等待安装脚本运行。