背景

随着云原生的理念和技术逐渐深入人心，很多企业都在思考和实践如何落地，实实在在地达成云原生所承诺的目标：使工程师能够轻松地对系统作出频繁和可预测的重大变更。

越来越多的企业认识到，以 Kubernetes 为代表的云原生技术确实可以作为构建企业自己的内部平台的基础底座，并且大大赋能运维团队，但同时也意识到 Kubernetes 对开发人员而言复杂度还是太高了，有陡峭的学习曲线。
能找到会用 Kubernetes 的开发人员可能不难，但能找到精通的人恐怕就不容易了。

那现在的开发者体验到底如何呢？设想一个新加入的开发人员，他经常会问：

• 我们的技术标准和架构规范是什么？
• 可以用哪些开发语言、框架、开源软件？什么版本？我们使用什么编码规范和代码风格？
• 到哪儿能找到项目文档？还有架构图、拓扑图？
• 有什么微服务 API 可以调用？
• 有没有现成的项目模版可以重用？
• 代码提交到哪儿？多长时间提交一次？测试覆盖率需要达到多少？
• 怎么构建镜像？
• 怎么触发流水线执行部署应用？
• 到哪儿查看应用的遥测信息如运行日志、指标、分布式跟踪信息？
• ……

运气好的话，上述问题都能找到对应的人给出对应的答案。之后呢？他们还需要申请多个系统的账号，分别打开多个工具的界面（如 Wiki 查看文档信息，Jira 查看用户故事或缺陷，Jenkins 查看流水线执行状态，Kubernetes 查看应用负载运行状况等）, 熟悉各自的操作，不时的切换和 copy & paste，人工串联起整个工作流程，费时费力，还容易出错。

麦肯锡公开的一份研究报告 1 指出：开发者效率高的公司比开发者效率低的公司的收入增长速度快 4-5 倍。它们的营业利润率也更高，创新能力更是高 55 倍！处于前四分位的公司的总股东回报率也高 60%，营业利润率高 20%。由此可见，开发者效率是企业塑造核心竞争力的关键因素之一。

那如何弥合这些开发体验上的差距？

我们来看 Gartner 关于开发者体验的报告 2，其中推荐的关键实践包括：

• 建立内部开发者门户，理顺软件开发流程，支持重用、分享和协作，以提升开发体验和效能
• 通过开发者门户提供内置 “安全护栏 (Guardrail)” 的自助服务，在快速敏捷交付迭代创新的同时，兼顾治理规范的要求
• 把开发者门户作为产品，积极听取开发者的反馈，持续演进和创新，适应不断变化的需求。

Backstage简介

Backstage 起源于音乐流媒体巨头 Spotify，它的 Vision 正是”Kubernetes for Developer Experience”。

Backstage 大致的发展时间线如下：

• 2016 年发起的内部项目，用于构建 Spotify 内部开发者门户，Spotify 的开发人员的上手时间比以前减少了 55%，在内部得到广泛使用
• 2020 年 3 月的 “黑客周”，正式开源
• 2020 年 9 月贡献给 CNCF 进入沙箱阶段
• 2022 年 3 月从沙箱进入正式孵化阶段
• 2022 年 3 月 17 日正式 GA，发布了 1.0 版本。
  目前有 100 多个知名公司与机构公开采用，包括 Netflix,Expedia,Splunk, 美国航空、VMWare 等。

Backstage 提供了统一的 UI 体验和可扩展的核心框架。在此基础上主要包括：

• Software Catalog: 软件目录，统一管理软件系统的各个组件
• Software Templates: 软件模版，快速创建项目和脚手架 (Scaffolding)，确保符合技术标准和规范
• TechDocs: 技术文档，统一发布，查找和使用技术文档 (Markdown 格式)
• Kubernetes: 运行在 Kubernetes 上的资源如 Deployment, Pod 等的可见性
• Search: 搜索软件目录和技术文档，基于 Lunr、ElasticSearch 或 Postgres 等
  

Backstage 的系统模型

Backstage 的 Software Catalog 定义了一套描述软件系统的模型：

主要类型包括：

• Domain: 某个业务领域，如电商
• System：组成 Domain 的各个应用系统，如商品目录、购物车、订单等系统
• Component：系统中的组件，如订单前台页面 SPA，订单微服务组成了订单系统
• Resource：系统中的资源，如订单数据库、订单执行的消息中间件等
• API：组件既可以发布 API (符合 OpenAPI、AsyncAPI、GraphSQL 等) 供使用方调用，可以使用其它组件提供的 API，如订单微服务组件发布订单 API 供前台页面调用

每个项目需要提供描述自己的元数据（catalog-info.yaml），与源代码一起保存在版本控制系统，如 Git 里面。元数据主要包括

• 所属的种类 (domain/system/component/resource 等)
• 名字、描述
• 标签、注解
• 类型（service/website/library）
• 所属的 system/component
• 负责的团队 (group/user)
• 服务的生命周期（production/experimental/deprecated）
• 依赖项（component/resource）
• 提供的 API、使用的 API 等
  
  完整的配置项参见：https://backstage.io/docs/features/software-catalog/descriptor-format

Backstage 的生态系统

Backstage 可以无缝集成主流的源代码管理系统如 Github, GitLab,AWS S3 等，并支持使用第三方认证包括 Github, GitLab, Okta, Auth0, Atlassian 等。

Backstage 开源社区很活跃，生态系统 (https://backstage.io/plugins) 中有大约 60 个现成的插件，覆盖软件开发生命周期，可以大致分类为如下：

• 敏捷管理： Jira
• 源代码管理：Github Pull Requests, Github Insights
• 质量：SonarQube, FOSSA, Google Lighthouse,
• 发现：API Docs, Harbor, Home, Tech Radar, TODO, Cost Insights
• CI/CD：Argo CD, Azure Pipelines, Circle CI，Github Actions,Gitlab, Jenkins, Travis CI
• 监控：Datadog,Grafana,Kafka,New Relic,PagerDuty,Prometheus
• 安全：Snyk,Security Insights
• Infrastructure: AWS CloudFormation, AWS Lambda
  可以看到，插件已经初步完备，并且还在持续增加和丰富中，相信大部分企业典型的需求都可以得到满足。即使目前还未完全满足，企业也可以而且应该开发自己的插件，并贡献回社区，这样的社区生态才会越来越好！

Backstage资料

Backstage 官网: https://backstage.io/
Backstage 架构: https://backstage.io/docs/overview/architecture-overview
Backstage Demo入口: https://backstage.io/demos

附注

此文章转发自【TAP 系列文章 4 | 基于 Backstage 的 TAP 开发者门户】