2. 服务画像定义：什么是服务画像，服务画像的核心维度

2.1 服务画像的定义

服务画像（Service Profile）是对一个微服务静态属性与动态行为的结构化描述。它帮助 SRE 和 DevOps 团队回答以下关键问题：

• 这个服务有多重要？ —— 业务属性决定 SLI 的权重和告警优先级。
• 它用什么技术实现？ —— 技术栈决定流水线中工具链的选择和测试策略。
• 它承受什么样的流量？ —— 流量特征决定压测模型和容量规划口径。
• 它多久变一次？ —— 变更频率决定流水线的触发策略和部署节奏。

服务画像不是一成不变的，它应该随着服务演进持续更新，并与 CMDB、服务目录、监控系统保持同步。

2.2 服务画像的核心维度

服务画像由四个核心维度构成，每个维度下包含若干关键属性。下表给出了完整的维度定义与典型取值：

2.3 服务画像四维关系图

下图展示了四个核心维度之间的逻辑关系：业务属性作为顶层驱动，技术栈和流量特征作为运行基础，变更频率作为动态调节因子，共同输出差异化的 SLI 口径策略。

2.4 各维度详解

2.4.1 业务属性

业务属性是服务画像的顶层分类，它直接关联到服务的商业价值和 SLO 承诺。常见的业务属性分类包括：

• 服务等级（Tier）： Tier-0（基础设施）、Tier-1（核心业务）、Tier-2（支撑业务）、Tier-3（工具/内部服务）。
• 业务域： 支付域、用户域、商品域、订单域、数据域等。
• SLO 目标： 可用性 99.99% / 99.9% / 99%，延迟 P99 < 100ms / < 500ms。
• 合规要求： PCI-DSS、GDPR、HIPAA 等。

2.4.2 技术栈

技术栈维度描述了服务的实现语言、框架、中间件依赖和部署形态。不同技术栈对流水线的要求差异巨大：

• 语言与框架： Go + gRPC、Java + Spring Boot、Python + FastAPI、Node.js + Express。
• 中间件： Redis、Kafka、RabbitMQ、MySQL、PostgreSQL、MongoDB。
• 部署形态： 容器化（Kubernetes）、虚拟机、Serverless（FaaS）、裸金属。
• 构建工具： Maven/Gradle、Go build、npm/pnpm、Bazel。

2.4.3 流量特征

流量特征描述了服务在生产环境中的请求模式，它直接影响压测 SLI 和容量规划口径：

• QPS 峰值： 日常 QPS、大促峰值、突发流量倍数。
• 请求模式： 读多写少（9:1）、写多读少（1:9）、读写均衡。
• 调用链深度： 同步调用跳数、异步消息依赖、外部 API 依赖。
• 流量来源： 用户端、内部服务、定时任务、外部 Webhook。

2.4.4 变更频率

变更频率是服务画像中最动态的维度，它决定了流水线的触发策略和部署节奏：

• 高频变更： 每天 10+ 次部署，通常对应前端、BFF、配置中心服务。
• 中频变更： 每天 1~5 次部署，对应大部分业务服务。
• 低频变更： 每周/每月 1 次部署，对应基础库、中间件、数据管道。
• 零变更： 只读服务、静态资源服务，流水线仅用于监控和告警。

2.5 服务画像与 SLI 口径的映射关系

服务画像的四个维度不是孤立存在的，它们共同决定了 CI/CD 流水线中每个阶段的 SLI 口径。下表展示了典型的映射关系：

2.6 服务画像的落地流程

在实际组织中，服务画像的建立需要遵循以下步骤：

1. 初始化： 从 CMDB 或服务目录导出所有服务列表，补充业务属性标签。
2. 技术栈扫描： 通过代码仓库分析工具自动识别语言、框架、依赖。
3. 流量基线采集： 从监控系统（Prometheus、Datadog）拉取过去 30 天的 QPS、延迟、错误率数据。
4. 变更频率统计： 从 CI/CD 平台（Jenkins、GitLab CI、ArgoCD）统计过去 30 天的部署次数。
5. 画像入库： 将四个维度的数据写入服务画像数据库，并关联到流水线配置。
6. 持续更新： 设置定时任务（每周/每月）自动刷新流量特征和变更频率数据。

2.7 本章小结