2. 服务画像基础：服务画像的定义、核心要素
在微服务与云原生架构下，一个中等规模系统往往包含上百个服务实例。如果没有统一的“画像”机制，运维与研发团队将面临以下困境：
- 黑盒运维：无法快速定位某个服务的技术栈版本、依赖关系与健康状态。
- 责任模糊：服务出问题时，不清楚该找哪个团队、SLA 承诺是什么。
- 变更失控：缺乏业务域归属信息，导致变更影响范围难以评估。
服务画像（Service Profile）正是为解决上述问题而生的元数据聚合模型。它通过结构化的方式，将服务的技术属性、业务属性、组织属性与契约属性统一描述，形成可被平台化消费的“服务身份证”。
2.1 服务画像的定义
服务画像是一组围绕单个微服务或应用的标准化元数据集合，它从四个维度完整刻画一个服务的全貌：
服务画像 = 技术栈 + 业务域 + 团队 + SLA
这四类信息共同构成服务在 CMDB（配置管理数据库）或服务目录中的核心记录，是后续实施质量门禁、自动化运维、容量规划的基础数据源。
2.2 核心要素详解
2.2.1 技术栈（Tech Stack）
技术栈描述服务运行时依赖的软件生态，包括但不限于：
- 编程语言与框架：Java 17 + Spring Boot 3.x、Go 1.21 + Gin、Python 3.11 + FastAPI。
- 中间件与存储：MySQL 8.0、Redis 7.x、Kafka 3.5、Elasticsearch 8.x。
- 基础设施：容器镜像版本、Kubernetes 资源规格（CPU/Memory 请求与限制）、Service Mesh 边车版本。
- 构建与部署：JDK 版本、Maven/Gradle 构建工具、Dockerfile 基础镜像。
技术栈信息直接服务于依赖升级、漏洞扫描与兼容性检查。例如，当 Redis 爆出高危漏洞时，运维平台可基于画像快速筛选出所有依赖 Redis 7.0 以下版本的服务。
2.2.2 业务域（Business Domain）
业务域将服务映射到企业的业务能力地图中，通常采用领域驱动设计（DDD）的限界上下文概念：
| 业务域层级 | 示例 | 说明 |
|---|---|---|
| 一级域 | 交易域 | 核心业务领域，如订单、支付、结算 |
| 二级域 | 订单子域 | 细分业务模块，如订单创建、订单查询 |
| 服务归属 | order-service | 具体服务实例，绑定到二级域 |
业务域标签的价值在于：
- 影响面分析：当“交易域”需要整体压测或限流时，可一键圈定所有关联服务。
- 故障定级：核心域服务故障通常触发 P0 级响应，而非核心域可能只触发 P2。
2.2.3 团队（Team）
团队信息明确服务的所有权与联系人，是运维协同的基石：
- 所属团队：如“交易研发组”、“支付中台组”。
- 负责人：技术负责人（TL）与值班 On-Call 人员。
- 沟通渠道：企业微信/钉钉群、Jira 项目 Key、GitLab Group。
- 维护模式：正常维护 / 仅修复 / 已冻结（EOL）。
最佳实践：团队信息应定期同步自 HR 系统或组织架构 API，避免人员变动后画像失准。
2.2.4 SLA（服务等级协议）
SLA 是服务对外承诺的质量契约，通常包含以下指标：
| SLA 维度 | 常见指标 | 典型目标值 |
|---|---|---|
| 可用性 | 月度/季度可用性百分比 | 99.9% (3个9) ~ 99.99% (4个9) |
| 延迟 | P50 / P95 / P99 响应时间 | P99 < 200ms |
| 吞吐量 | 每秒请求数 (RPS) / 每分钟事务数 (TPM) | 核心服务 ≥ 5000 RPS |
| 错误率 | HTTP 5xx 占比 / 业务错误码占比 | < 0.1% |
SLA 信息在质量门禁中的典型用途：当某次发布导致 P99 延迟从 150ms 飙升到 350ms 时，门禁系统可自动比对画像中的 SLA 阈值，判定本次变更“不通过”并触发回滚。
2.3 服务画像四要素关系图
下图展示了四个核心要素如何共同构成完整的服务画像，以及它们与外部平台（监控、CMDB、门禁引擎）的交互关系：
2.4 服务画像的存储与消费
在实际工程中，服务画像通常存储在以下位置之一：
- CMDB 系统：作为配置项（CI）的属性扩展，适合传统运维体系。
- 服务目录平台：如 Backstage、ServiceNow，提供开发者自助门户。
- Kubernetes 注解（Annotations）：将画像元数据直接注入服务 Pod，便于运行时发现。
以下是一个简化的服务画像 YAML 示例，展示四个要素的字段映射：
service-profile:
service-name: "order-service"
version: "2.1.0"
tech-stack:
language: "Java 17"
framework: "Spring Boot 3.2"
database: "MySQL 8.0"
cache: "Redis 7.2"
messaging: "Kafka 3.6"
container: "openjdk:17-jre-slim"
business-domain:
level1: "交易域"
level2: "订单子域"
domain-owner: "交易中台"
team:
name: "交易研发组"
tech-lead: "张三"
on-call: "李四"
chat-group: "https://weixin.qq.com/g/order-dev"
maintenance-mode: "normal"
sla:
availability: "99.95%"
latency-p99-ms: 200
error-rate-percent: 0.05
throughput-rps: 8000
注意：画像数据必须保持版本化与审计追踪。每次字段变更（如团队负责人更换、SLA 阈值调整）都应记录变更人、时间与原因，避免配置漂移。