2. 源数据保护组件分析

源数据保护组件分析是迁移工程中最关键的基线测绘环节。只有准确掌握现有组件的清单、依赖、接口契约、数据路径与潜在风险，才能制定零冲突的迁移方案。本章将带领你完成一次完整的“外科手术式”分析，所有输出都将直接复用至后续的组件解耦与迁入设计。

2.1 现有组件清单与依赖梳理

首先通过文件系统扫描、配置文件解析与运行时进程列表，生成一张版本精确、依赖透明的组件清单。以下是一个典型自建机房的组件实例（数据来自某金融核心交易系统）：

2.2 接口文档阅读——从 “死文档” 到 “活契约”

接口文档通常滞后于代码。正确做法是：文档 + 源码桩 + 网络抓包三路交叉验证。

• REST API：使用 OpenAPI 3.0 规范阅读，重点关注 securitySchemes 与 x‑rate‑limit 扩展字段。
• gRPC：阅读 .proto 文件中的 rpc 定义、oneof 字段与 google.api.http 注解。
• 自定义 TCP/二进制协议：借助 wireshark 或 tcpdump 录制样本，用 protobuf-decoder 或 Kaitai Struct 反序列化。

以下是一个 gRPC 接口桩的典型片段（KeyManager 的 GenerateKey RPC）：

// keymanager.proto (关键字段裁剪)
service KeyManager {
  rpc GenerateKey(GenerateKeyRequest) returns (GenerateKeyResponse);
  rpc RotateKey(RotateKeyRequest) returns (RotateKeyResponse);
}

message GenerateKeyRequest {
  string algorithm = 1;           // AES-256 / SM4
  int32 key_size = 2;            // 128 / 256
  string key_label = 3;          // 用于审计的别名
  google.protobuf.Duration ttl = 4;  // 有效时长
}

message GenerateKeyResponse {
  string key_id = 1;
  string version = 2;
  bytes encrypted_key = 3;       // 使用主密钥封装后的密文
  google.protobuf.Timestamp expires_at = 4;
}

2.3 数据流追踪——定位“隐形”配置与中间件

数据流追踪的目的是暴露所有间接调用路径，避免迁移后请求断链。推荐使用分布式追踪 + 静态代码分析双轨法：

1. 在测试环境启动 Jaeger 或 SkyWalking，对关键组件注入 opentelemetry-javaagent 或 Python OTEL SDK。
2. 构造一条典型加密请求（例如：用户登录 → Gateway → TokenService → Encryptor → KeyManager → 返回加密令牌）。
3. 从 Jaeger UI 中导出 Trace Graph，标记每个 span 的 service.name、http.url、peer.hostname。
4. 对比静态代码中 @FeignClient、@GrpcClient 或 restTemplate.exchange 的调用关系，补全遗漏节点。

以下是一个经过追踪后梳理出的加密请求完整数据流（仅展示关键跳转）：

UserRequest
  -> Gateway (port 443)
    -> TokenService (port 8080, GET /)
      -> KeyManager (port 50051, RPC CheckTokenStatus)
        -> DB (port 3306, SELECT _meta)
      <-- 返回  元数据
    <-- 返回 JWT
  -> Encryptor (port 8443, POST /encrypt)
    -> KeyManager (port 50051, RPC GetActiveKey)
      -> DB (port 3306, SELECT current_key)
    <-- 返回 AES-256-GCM 密钥（密文）
    -> 本地执行加密
  <-- 返回加密数据

2.4 风险识别——迁移前必须解决的“钉子”

依据前面三步的输出，识别四类典型风险：

2.5 组件依赖关系图（SVG）

以下内联 SVG 展示了现有组件的依赖与数据流方向，方框内为组件名，箭头上标注接口协议与端口，帮助一眼识别关键耦合点。

2.6 分析结果结构化归档

每一次组件分析都应输出一个 YAML 文件，作为迁移工程的“唯一真相来源”。建议格式如下：

# source_analysis_v2.3.yaml
components:
  - name: Encryptor
    version: v3.2.1
    dependencies:
      - name: KeyManager
        protocol: grpc
        endpoint: keymanager.internal:50051
        required: true
      - name: DB
        protocol: postgresql
        endpoint: pg.internal:5432
        required: false   # 仅缓存元数据，不阻塞
    dataflows:
      - id: encrypt_request
        trace_id: "a1b2c3"
        steps: [Gateway, Encryptor, KeyManager, DB]
    risks:
      - type: implicit_coupling
        description: "Encryptor 通过 local-socket 读取 /tmp/active_key 文件"
        severity: critical
        mitigation: "改为 grpc getActiveKey rpc"