3. 服务目录设计原则：以开发者为中心、标准化、可发现性、可组合性、安全合规
服务目录是平台工程面向开发者的“产品货架”。设计原则决定了开发者能否快速找到所需能力、安全地组合资源，并形成可复用的标准化交付路径。以下五大原则构成了服务目录的架构基石。
3.1 以开发者为中心：降低认知负载
平台的核心用户是开发者，服务目录的设计必须从开发者的工作流和心智模型出发，而非从底层基础设施的拓扑结构出发。
- 面向意图的命名：使用开发者熟悉的业务术语（如“创建微服务”、“部署金丝雀版本”），而非技术术语（如“申请VM”、“配置Ingress”）。
- 最小必要信息：表单字段默认折叠高级选项，只展示必填项。通过智能默认值减少决策点。
- 即时反馈：提交服务请求后，立即返回预估等待时间或异步通知链接，避免黑盒等待。
实践要点：定期对开发者进行“认知负载测试”——记录完成一次标准部署所需的点击次数、表单填写项数和等待决策的时间。目标是将平均操作步骤控制在 5 步以内。
3.2 标准化：消除碎片化
标准化是平台工程实现规模化的前提。服务目录必须强制或引导开发者使用经过平台团队验证的黄金路径（Golden Path）。
| 标准化维度 | 描述 | 示例 |
|---|---|---|
| 运行时基座 | 统一的基础镜像、运行时版本、Sidecar 代理版本 | 所有 Java 服务必须使用 OpenJDK 17 + 特定安全补丁 |
| 配置规范 | 统一的配置格式、密钥管理方式、日志输出格式 | 日志必须输出为 JSON 格式，包含 traceId 和 spanId |
| 部署策略 | 预定义的部署策略模板（滚动、蓝绿、金丝雀） | 生产环境仅允许使用“金丝雀部署”模板，自动控制流量比例 |
| 监控与告警 | 自动注入的监控探针、预配置的告警规则 | 每个服务自动绑定 P99 延迟告警和错误率告警 |
避坑提醒：标准化不等于僵化。应为高级用户保留“脱离黄金路径”的选项，但必须通过审批流程或额外责任声明来平衡灵活性与合规性。
3.3 可发现性：让服务“被找到”
开发者不知道的能力等于不存在。服务目录必须具备强大的搜索、分类和推荐机制。
- 多维度分类：按技术栈（Java/Go/Python）、按环境（开发/测试/生产）、按团队（支付/用户/订单）进行标签化。
- 全文搜索：支持模糊搜索服务名称、描述、标签，甚至搜索服务模板内的代码片段。
- 依赖关系可视化：展示服务之间的调用关系、数据依赖和版本兼容性。
3.4 可组合性：乐高式服务构建
服务目录不应只是静态列表，而应支持开发者像搭积木一样组合基础服务单元，快速构建满足业务需求的复合服务。
- 服务模板（Blueprint）：预定义的服务骨架，包含代码脚手架、CI/CD 流水线、基础设施即代码（IaC）片段。
- 能力插件：可插拔的横切关注点，如认证鉴权、日志采集、缓存策略、消息队列绑定。
- 版本兼容性矩阵：自动检测并提示服务模板与插件之间的版本兼容性，避免组合后出现依赖冲突。
组合示例：开发者选择“Spring Boot 微服务模板” + “Redis 缓存插件 v2.1” + “Kafka 消息插件 v1.3”，平台自动生成兼容的 Dockerfile、Helm Chart 和部署配置。
3.5 安全合规：内置而非附加
安全与合规必须嵌入服务目录的设计中，成为默认行为，而非事后审计项。
| 安全维度 | 服务目录内置措施 |
|---|---|
| 访问控制 | 基于 RBAC/ABAC 的细粒度权限，控制谁可以查看、申请、修改服务 |
| 密钥管理 | 自动集成密钥管理服务（KMS），禁止明文存储任何凭证 |
| 合规扫描 | 服务模板提交时自动触发合规策略检查（如 SOC2、PCI-DSS） |
| 审计日志 | 记录所有服务目录的变更操作，支持不可篡改的审计追踪 |
| 依赖扫描 | 自动扫描服务模板中的开源依赖，标记已知漏洞（CVE） |
3.6 五大原则的协同关系
这五大原则并非孤立存在，而是相互增强的有机整体：
- 标准化 为 可组合性 提供可靠的接口和契约。
- 可发现性 让 标准化 的服务模板更容易被开发者找到和使用。
- 以开发者为中心 的设计确保 安全合规 措施不会成为开发效率的阻碍。
- 安全合规 的自动化检查反过来增强了 标准化 的执行力。
核心结论：一个成熟的服务目录，是开发者体验、运维效率与安全治理的平衡点。设计时优先保障“以开发者为中心”和“标准化”，再逐步叠加“可发现性”和“可组合性”，最后将“安全合规”作为贯穿始终的约束条件。