3. 服务画像概念：定义、维度与治理关系

服务画像是微服务治理的“数字身份档案”。它通过多维度标签对每个微服务进行结构化描述，将分散的运维数据、代码元数据、业务归属和稳定性历史聚合为一个可查询、可分析、可参与策略决策的实体。在 DORA 度量体系中，服务画像是连接原始指标与质量门禁策略的桥梁——没有画像，门禁无法区分“核心支付服务”与“内部工具服务”的差异化要求。

3.1 什么是服务画像

服务画像（Service Profile）是对一个微服务全生命周期属性的结构化建模。它不同于简单的服务名或 IP 列表，而是包含技术、组织、业务、部署、稳定性五个维度的标签集合。画像数据通常存储在 CMDB、服务注册中心或专门的治理平台中，并随服务演进持续更新。

画像的粒度是单个微服务实例或服务单元。对于多实例部署的服务，画像在服务级别统一，实例级别可附加部署模式标签。

3.2 画像包含的五个核心维度

下表列出每个维度的典型标签、数据来源及在 DORA 度量中的用途：

3.3 画像与微服务治理的关系

服务画像是微服务治理策略的“输入参数”。治理决策（如是否允许紧急变更、是否需要人工审批、回滚超时阈值设多少）不再依赖人工经验，而是由画像标签组合自动推导。下图展示画像如何驱动治理闭环：

上图展示了服务画像在治理闭环中的核心位置：

1. 画像输入：五个维度标签聚合为服务画像。
2. 策略推导：治理引擎根据画像组合（如“核心交易 + Java + 低稳定性”）生成差异化策略（如强制代码审查、回滚超时 5 分钟）。
3. 门禁执行：质量门禁在 CI/CD 管线中按策略拦截或放行变更。
4. 反馈更新：门禁执行结果和 DORA 度量数据（如变更失败率）反馈回画像，更新历史稳定性标签，形成持续改进闭环。

3.4 画像在质量门禁中的典型应用场景

以下列表展示画像标签组合如何直接映射为门禁规则：

• 场景一：核心交易 + 低稳定性 → 门禁要求：必须通过全量回归测试 + 变更必须由两名高级工程师审批 + 回滚超时阈值设为 3 分钟。
• 场景二：内部工具 + 高稳定性 → 门禁要求：仅需单元测试通过 + 单点审批即可部署。
• 场景三：无服务器部署 + 新团队 → 门禁要求：强制进行部署前压测 + 部署频率限制为每天不超过 3 次。
• 场景四：历史 P0 事故服务 → 门禁要求：变更后自动触发 15 分钟金丝雀观察期 + 自动回滚条件设为错误率上升 1%。

3.5 画像数据模型示例

以下是一个简化的服务画像 JSON 结构，展示五个维度的实际数据组织方式：

{
  "serviceName": "payment-service",
  "version": "2.1.0",
  "techStack": {
    "language": "Java 17",
    "framework": "Spring Boot 3.2",
    "database": "MySQL 8.0",
    "cache": "Redis 7.2",
    "rpc": "gRPC 1.58"
  },
  "team": {
    "owner": "payment-team",
    "type": "internal",
    "size": 8,
    "onCallRotation": "primary"
  },
  "businessDomain": {
    "domain": "core-transaction",
    "criticality": "P0",
    "sla": "99.99%"
  },
  "deploymentMode": {
    "platform": "Kubernetes",
    "workloadType": "Deployment",
    "replicas": 6,
    "rollbackStrategy": "blue-green"
  },
  "stabilityHistory": {
    "last30dIncidents": 1,
    "last90dP0Incidents": 0,
    "currentSLA": "99.97%",
    "mtbf": "720h"
  }
}

该数据模型可直接被门禁引擎消费，用于动态计算每个变更请求的风险等级和对应的门禁规则。

3.6 画像治理的成熟度演进

团队在落地服务画像时，通常经历以下三个阶段：