📚 课程目录第2章平台工程基础

2. 平台工程基础：核心概念、IDP 架构与自助服务能力模型

平台工程并非简单的工具堆砌，而是一套以提升开发者体验（DX）和交付效率为目标的工程实践。本章将围绕三个核心支柱展开：平台工程的核心概念、内部开发者平台（IDP）的参考架构，以及自助服务能力的成熟度模型。理解这些基础，是后续设计容量压测自助服务接口的前提。

平台工程的核心在于构建一个“产品化”的内部平台，抽象底层基础设施的复杂性，为应用开发者提供一条自服务的黄金路径（Golden Path）。

概念	定义	在压测场景中的体现
黄金路径	经过验证、安全且高效的标准化交付流程，降低认知负荷。	预定义的压测脚本模板、标准化的压测环境配置、自动化的结果分析流程。
认知负荷	开发者完成一项任务所需的脑力资源。平台工程的目标是降低非功能性认知负荷。	开发者无需关心压测集群的扩缩容、监控指标采集、数据存储等底层细节。
抽象与封装	将底层基础设施（如K8s、虚拟机、网络）通过API或UI进行封装，对外暴露业务语义接口。	通过一个 `POST /api/v1/stress-test` 接口发起压测，而非直接操作K8s Job。
自助服务	开发者无需等待平台团队介入，即可通过平台提供的界面或API自主完成操作。	开发者在作业平台上自助创建、启动、停止压测任务，并查看实时报告。
平台即产品	将平台视为一个产品来运营，关注用户（开发者）体验、文档、SLA和持续迭代。	为压测服务提供清晰的API文档、版本管理、调用配额和错误反馈机制。

关键洞察： 平台工程的核心价值在于“赋能”而非“管控”。通过提供标准化的自助服务接口，平台团队将运维能力下放，使业务团队能够更快速地响应变化，同时确保合规与安全。

IDP 是平台工程理念的具体落地形态。一个典型的 IDP 架构通常包含四个核心层次，它们协同工作，为开发者提供端到端的自助服务体验。

在容量压测作业平台的上下文中，IDP 各层的职责映射如下：

自助服务能力并非一蹴而就，而是随着平台成熟度逐步演进的。我们可以通过一个能力模型来评估和规划平台的自助服务水平。该模型通常分为四个等级。

  课程目标定位： 本课程设计的“容量压测作业平台自助服务接口调用机制”，旨在帮助平台团队从 L2（自动化） 向 L3（自助服务） 跨越。核心交付物是一套定义清晰、版本可控、具备可观测性的 RESTful API，使业务团队能够像调用内部服务一样，自助完成压测任务的声明、执行与结果获取。

基于上述能力模型，在设计自助服务接口（特别是面向压测场景）时，应遵循以下原则：

以业务语义为中心： 接口路径和参数应反映业务意图，例如 /api/v1/stress-test 而非 /api/v1/run-job。参数使用 target_url、concurrent_users、ramp_up_time 等业务术语。
声明式而非命令式： 用户描述“想要什么”（如：对服务A进行100并发、持续5分钟的压测），而非“怎么做”（如：创建Pod、配置JMeter脚本）。平台负责将声明转换为具体操作。
异步与状态反馈： 压测任务通常是长时间运行的操作。接口应采用异步模式，立即返回一个任务ID，并提供状态查询端点（如 GET /api/v1/stress-test/{id}/status），避免请求超时。
可观测性内建： 每个接口调用都应产生可追踪的日志和指标。响应体中应包含任务ID、创建时间、当前状态、以及获取实时监控数据的链接。
版本控制与兼容性： 从第一个版本开始就引入API版本（如 /api/v1/），并制定向后兼容策略，确保接口演进不影响已有调用方。

常见陷阱： 在设计初期过度追求“智能化”（L4），导致接口过于复杂，难以维护。建议从L3的“自助服务”起步，先确保接口的稳定性、可用性和清晰的文档，再逐步引入智能推荐等高级特性。