微服务平台应该提供哪些基础能力？

简化版

微服务平台应提供服务模板、构建发布、配置与密钥、服务发现、流量治理、可观测性、安全策略和自助运维等“铺好的道路”。平台目标是降低认知负担并统一安全底线，而不是替业务团队代写业务逻辑。

详细版

能力应围绕服务全生命周期：创建时脚手架和 owner 元数据，开发时本地环境与契约测试，交付时制品、供应链和灰度，运行时发现、配置、弹性、限流、熔断、日志指标 Trace，退出时归档与权限回收。

平台以自助 API/门户和声明式配置交付，提供默认值、逃生口与审计。用采用率、交付前置时间、变更失败率、MTTR 和开发者满意度衡量，不能只统计平台组件数量。

完整版教学

一、平台解决什么问题

没有平台时，每个团队各自拼 CI、鉴权、监控和发布，安全与可靠性取决于个人经验。平台把重复且高风险的非业务能力产品化，让团队把时间用在领域功能上。

记忆钩子：平台提供护栏和道路，不接管方向盘。

二、能力地图

阶段	核心能力	产物
创建	模板、目录、owner	可运行服务骨架
交付	CI/CD、制品签名、灰度	可追溯版本
运行	配置、发现、弹性、治理	稳定实例
观测	指标、日志、Trace、告警	可诊断证据
安全	身份、密钥、策略、审计	最小权限

三、Golden Path 与逃生口

Golden Path 提供经过验证的默认方案，例如自动注入健康检查、资源限制和遥测。它应覆盖 80% 常见场景，同时允许经审批扩展；完全封死会逼团队绕过平台。

逃生口必须可观测、有 owner 和到期时间，不能成为永久例外。例外数量反过来能提示平台能力缺口。

四、自助服务如何设计

开发者提交声明，平台异步创建仓库、流水线、身份和环境，并返回状态。操作必须幂等：同一 requestId 重试不能创建两个 Topic 或两套权限。

service.yaml -> validate policy -> provision -> verify -> catalog

失败时保留步骤状态并可补偿，不能用一个长脚本做到一半后让用户手工清理。

五、强制护栏的边界

密钥禁止入库、制品必须扫描、生产发布需审计等适合强制执行；语言框架、日志库版本则可给迁移窗口。护栏过严会拖慢交付，过松又无法建立基线。

策略应有版本、解释信息和灰度模式。先只告警观察影响，再阻断新资源，最后治理存量。

六、如何衡量平台价值

假设服务初始化从 3 天降到 30 分钟，但发布失败率从 5% 升到 8%，平台仍未成功。应联合看 lead time、部署频率、变更失败率、MTTR、采用率和工单量。

还要衡量认知负担：完成常见任务需要多少步骤、等待多久、是否能自助定位。平台可用性本身也要有 SLO 和灾备。

平台控制面应与工作负载数据面解耦；门户短时不可用时，已运行服务不应因此停止路由、鉴权或读取现有配置。

能力下线也需要迁移计划，避免业务服务永久依赖无人维护的旧模板和 API。

七、常见误区与追问

• 误区：采购 Kubernetes 就有微服务平台。 编排器只是运行底座的一部分。
• 误区：平台能力越多越好。 无用户的功能会增加维护和认知成本。
• 误区：统一等于禁止例外。 特殊负载需要受控逃生口。
• 误区：只看创建了多少服务。 应看交付质量与恢复效率。
• 追问：先建设什么？ 从最高频、最痛且可标准化的交付与观测闭环开始。
• 追问：平台故障怎么办？ 控制面降级不应立即中断已有数据面，并需独立灾备。
• 追问：如何推动采用？ 让默认路径更快更安全，以产品指标持续改进。

八、加强记忆

平台能力按“创建—交付—运行—观测—安全—退出”覆盖生命周期，以 Golden Path 提供默认护栏，以受控逃生口保留弹性。自助操作要幂等可恢复，平台价值用交付速度、失败率和 MTTR 共同证明，而非用组件清单证明。