Skip to main content

结构概述

术语​

Backstage "由三个部分组成，我们之所以这样将 "Backstage "分开，是因为我们看到有三组贡献者以三种不同的方式与 "Backstage "合作。

  • 核心 - 核心开发人员在开源项目中构建的基础功能。 应用程序 - 应用程序是Backstage应用程序的实例，可进行部署和调整。 应用程序将核心功能与附加插件联系在一起。 应用程序由应用程序开发人员构建和维护，通常是公司内的生产力团队。 插件 - 使Backstage应用程序对公司有用的附加功能。 插件可以是公司专用的，也可以是开源和可重复使用的。 在 Spotify，我们有 50 多个不同团队构建的 100 多个插件。 不同基础架构团队的贡献被添加到一个统一的开发人员体验中，这一点非常强大。

概览​

下图显示了在使用 Tech Radar 插件、Lighthouse 插件、CircleCI 插件和软件目录的公司内部部署 Backstage 时的情况。

该架构有 3 个主要组成部分：

  1. 核心Backstage用户界面 2. 用户界面插件及其Backstage服务 3. 数据库

要在实际环境中运行这种架构，通常需要将组件容器化。 为此提供了各种命令。

The architecture of a basic Backstage application

用户界面​

用户界面是一套插件的瘦客户端封装，它提供了一些核心用户界面组件和用于配置管理等共享活动的库。现场演示]

UI with different components highlighted

每个插件通常都在用户界面的一个专用 URL 上提供。 例如，light house插件在用户界面的以下网址注册/lighthouse. [了解更多]

The lighthouse plugin UI

CircleCI 插件可在以下网站下载/circleci.

CircleCI Plugin UI

插件和插件后端​

每个插件都是安装在用户界面上的客户端应用程序。 插件是用 TypeScript 或 JavaScript 编写的。 它们各自位于以下目录中backstage/plugins例如，light house插件的源代码可从以下网址获取backstage/plugins/lighthouse.

安装插件​

插件通常作为 React 组件安装在您的 Backstage 应用程序中。 例如、这里是一个导入 Backstage 示例应用程序中许多全页面插件的文件。

这些插件组件中的一个例子是CatalogIndexPage这是一个全页面视图，可以浏览 Backstage 目录中的实体。 在应用程序中安装它的方法是导入它并将其添加为一个元素，就像这样：

import { CatalogIndexPage } from '@backstage/plugin-catalog';

...

const routes = (
  <FlatRoutes>
    ...
    <Route path="/catalog" element={<CatalogIndexPage />} />
    ...
  </FlatRoutes>
);

请注意，我们使用"/catalog"作为该插件页面的路径，但我们可以为页面选择任何路径，只要它不与我们为应用程序中其他插件选择的路径相冲突即可。

这些从插件中导出的组件被称为 "插件扩展组件 "或 "扩展组件"。 它们是普通的 React 组件，但除了能被 React 渲染外，还包含各种元数据，用于将整个应用程序连接起来。 扩展组件是通过以下方式创建的create*Extension方法，您可以在可组合性文件.

目前，还没有基于配置的插件安装程序。 需要修改一些代码。

插件架构​

从架构上讲，插件有三种形式：

  1. 独立 2. 服务支持 3. 第三方支持

独立插件​

独立插件完全在浏览器中运行。技术雷达插件它不会向其他服务发出任何 API 请求。

tech radar plugin ui

安装到 Backstage 应用程序中的技术雷达的结构非常简单。

ui and tech radar plugin connected together

服务支持插件​

服务支持插件向运行 Backstage 的组织权限内的服务发出 API 请求。

例如，Lighthouse(兆光科技)插件会向light house审计服务......。lighthouse-audit-service是一个微服务，它运行 Googlelight houselibrary并将结果存储在 PostgreSQL 数据库中。

它的结构是这样的

lighthouse plugin backed to microservice and database

Backstage 中的软件目录是服务后端插件的另一个例子。 它从 Backstage 后端服务中获取服务或 "实体 "列表，并以表格形式呈现给用户。

第三方支持的插件​

第三方支持的插件与服务支持的插件类似，主要区别在于支持插件的服务托管在 Backstage 托管公司生态系统之外。

CircleCI 插件是第三方支持插件的一个例子。 CircleCI 是一种 SaaS 服务，无需任何Backstage知识即可使用。 它有一个 API，Backstage插件可通过该 API 显示内容。

从用户浏览器发送到 CircleCI 的请求会通过Backstage提供的代理服务，否则请求会被跨源资源共享政策阻止，该政策会阻止在以下地址提供浏览器页面https://example.comhttps://circleci.com 托管的资源提供服务。

CircleCI plugin talking to proxy talking to SaaS Circle CI

软件包架构​

Backstage 在很大程度上依赖于 NPM 软件包，无论是库的发布还是项目内代码的结构化。 虽然 Backstage 项目的结构化方式取决于您自己，但我们鼓励您遵循一套既定的模式。 这些模式有助于建立健全的项目结构，并使不同的 Backstage 项目之间相互熟悉。

下图显示了 Backstage 的软件包架构概览。 它以单个插件及其可能包含的所有软件包为视角，用较粗的边框和斜体文字表示。 插件周围是不同的软件包组，它们是插件的不同接口点。 请注意，并非所有库软件包列表都是完整的，因为为了简洁起见，软件包被省略了。

Package architecture

概览​

上图中的箭头表示运行时对目标软件包代码的依赖关系。 这种严格的依赖关系图只适用于运行时dependencies可能有devDependencies虽然有一些箭头显示了对前端、后端和同构软件包集合的依赖，但这些仍然必须遵守左下方显示的重要兼容性规则。

app和backend软件包是 Backstage 项目的入口。app软件包是前端应用程序，它汇集了一系列前端插件，并根据组织的需要对其进行定制。backend软件包是为Backstage应用程序提供动力的后端服务。 值得注意的是，在一个项目中，每个软件包都可以有一个以上的实例。 特别是backend将软件包拆分成更小的部署单元，每个单元使用更少的插件集来实现各自的目的，这样可以使软件包受益匪浅。

插件包​

一个典型的插件最多由五个软件包组成，两个前端软件包、两个后端软件包和一个同构软件包。 插件内的所有软件包必须共享一个共同的前缀，通常的形式为@<scope>/plugin-<plugin-id>但替代品如backstage-plugin-<plugin-id>或@<scope>/backstage-plugin-<plugin-id>除了这些前缀，每个软件包都有自己独特的后缀，表示它们的作用。 除了这五个插件包，插件还可以安装额外的前端和后端模块，以启用可选功能。 有关后缀及其作用的完整列表，请参见插件包结构 ADR.

-react,-common和-node插件库使其他插件能够在插件的基础上构建和扩展插件，同样也使插件能够依赖和扩展其他插件。 正因为如此，插件库软件包最好允许重复安装自己，因为最终可能会出现作为各种插件的依赖安装的版本混杂的情况。 此外，禁止插件直接从其他插件导入非库软件包，插件之间的所有通信都必须通过库和应用程序本身来处理。

前端软件包​

前台软件包主要分为两组，第一组是 "前台应用程序核心"，这组软件包只在以下情况下使用app这些软件包有助于建立应用程序的核心结构，并为插件库提供基础。

第二组是其他共享软件包，进一步分为 "前端插件核心 "和 "前端库"。 核心软件包被认为是特别稳定的，构成了前端框架的核心。 它们最重要的作用是形成每个插件的边界，并提供一套工具，帮助您将插件集合组合成一个正在运行的应用程序。 其他前端软件包是更传统的库，作为创建插件的构件。

后端软件包​

后端库软件包目前并不共享与前端软件包类似的插件架构。 相反，它们只是帮助您构建后端服务的构建模块和模式的集合。 不过，这在未来很可能会发生变化。

常用软件包​

通用软件包是所有其他页面都有效依赖的软件包。 这一组软件包的数量要少得多，但它们也非常普遍。 由于通用软件包是同构的，必须在前端和后端同时执行，因此它们绝不允许依赖任何前端或后端软件包。

Backstage CLI 自成一类，几乎所有其他软件包都依赖于它，但它本身并不是一个库，必须始终作为开发依赖库。

决定代码的位置​

有时很难决定将插件代码放在何处。 例如，是否应直接放在-backend插件包或-node一般来说，你应该尽量减少代码的曝光率。 如果不需要公开 API，最好不要使用。 如果不需要被其他插件使用，那就直接放在插件包里。

下面的图表可帮助您决定代码的位置。

Package decision

数据库​

正如我们所看到的lighthouse-audit-service和catalog-backend需要使用数据库。

Backstage 后端及其内置插件基于克耐克斯这样可以提供很好的隔离性，使它们可以彼此独立地执行迁移和演进。

Knex 库支持多种数据库，但在撰写本文时，Backstage 主要针对其中两种数据库进行了测试：SQLite(主要用作内存中的模拟/测试数据库)和 PostgreSQL(首选的生产数据库)。 据报告，其他数据库(如 MySQL 变体)也能正常工作，但是没有进行充分的测试然而

缓存​

Backstage 后端及其内置插件也能利用缓存存储来提高性能或可靠性。 与支持数据库的方式类似，插件会接收逻辑上分离的缓存连接，这些连接由关键字引擎盖下

在撰写本文时，Backstage 可以配置为使用三种缓存存储之一：内存(主要用于本地测试)、memcache 或 Redis(更适合生产部署的缓存存储)。 适合您的 Backstage 实例的缓存存储取决于您自己的运行时间限制和您正在运行的插件的要求。

将内存用于缓存​

backend:
  cache:
    store: memory

使用 memcache 进行缓存​

backend:
  cache:
    store: memcache
    connection: user:[email protected]:11211

使用 Redis 进行缓存​

backend:
  cache:
    store: redis
    connection: redis://user:[email protected]:6379
    useRedisSets: true

关于 useRedisSets 标记的说明这里.

欢迎为支持其他高速缓存存储库做出贡献！

容器化​

上图所示的Backstage架构示例将 Docker 化为三个独立的 Docker 映像。

1.前端容器 2.后端容器 3.light house审计服务容器

Boxes around the architecture to indicate how it is containerised

运行以下命令即可构建后端容器：

yarn run build
yarn run build-image

这将创建一个名为example-backend.

light house-审计-服务(lighthouse-audit-service)容器已在 Docker Hub 上公开发布，可通过以下链接下载并运行

docker run spotify/lighthouse-audit-service:latest