开发者门户是面向开发者提供的一站式云端平台,即开即用,随时随地在云端交付软件全生命周期,覆盖从代码创建、流水线、部署、API管理、到运行监控全方位的开发支撑,提供软件研发流程的端到端支持,全面支撑落地应用开发。使企业中的所有软件以及谁拥有该软件都可被发现,不再有孤儿软件隐藏在软件生态系统的黑暗角落。
主要功能
在一个位置管理组织内所有软件
统一概述,每个团队都可以查看他们所拥有的服务和相关资源
可发现,不在有印在在技术堆栈中的孤儿软件
文档
技术文档管理,支撑从模板创建,直接对接应用组件
使用开发者门户软件模板时,项目会自动获得技术文档站点
代码和文档位于同一位置,可以在更新代码时直接更新文档
标准
一键式部署,存储库在git中自动配置,并且流水线已自动配置
根据标准构建,使用组织内最佳实践技术栈直接创建
可发现,不在有隐藏在技术堆栈中的孤儿软件
管理服务
对接kubernetes,围绕服务所有者提供服务
在统一视图中获取所有服务部署,无需再梳理服务列表
多个K8,一个UI,从本地测试迁移到生产环境,无需切换仪表板
用户输入注册好的用户名和密码,登录持续交付平台。开发测试平台使用单点登录模式,您登录任一平台即可操作。若您没有开发测试平台账号,点击【注册】按钮完成账号注册。
使用开发者门户管理的对象(软件、文档、类库等等)都可以在服务目录中查询。服务目录展示当前平台所有使用者管理的服务对象。进入系统,可以看到当前平台中的所有组件列表、包括微服务、微前端、API、文档和工具等。
可在左侧导航栏中按类型筛选服务实体。默认情况下,软件目录显示已登录用户团队拥有的组件,但是,也可以切换到【全部】,以查看企业内的所有组件,支持基本的搜索和筛选,方便用户查找目标组件。
开发者门户通过yaml配置服务实体进行定义和管
部分字段释义
apiVersion和 kind[必填]
kind指当前实体在开发者门户中的类型,核心类型有API、Component、Resource,当然,您可以自定义kind并添加到服务目录中。
资源是操作组件所需的物理或虚拟基础架构
apiVersion是针对特定实体制定规范的规范格式版本,当前版本为 backstage.io/v1alpha1
;如有更新,管理员会同步所有的使用者。
metadata[必填]
包含有关实体的元数据的结构,即不是实体规范本身直接组成部分的事物。
spec[可选]
描述实体的实际规范数据。
所有类型(kind)通用字段:metadata
name[必填] 实体的名称。此名称既用于人眼识别实体,也用于机器和其他组件引用实体(例如,在URL中或来自其他实体规范文件)。
在任何时间点,在给定命名空间(如果指定)中,名称必须对于每种类型都是唯一的。这种唯一性约束不区分大小写。
默认规则如下:
例:visits-tracking-service,CircleciBuildsDumpV2_avro_gcs
namespace[可选]
实体所属的命名空间的 ID。是一个字符串,其格式限制与上面的名称相同。目前,建议不要指定名称空间,除非您有特定的需要。不指定命名空间代表该实体属于“default”命名空间。
title[可选]
实体的显示名称,若指定了title,实体的显示名称则是title字段,而非name字段值。注意,title字段仅用于显示,若您需要引用某个实体,请使用该实体的name字段。
description[可选]
可读的实体描述,适合一目了然地概述实体的目的。
labels[可选]
附加到实体的可选键/值对,它们的用法与Kubernetes 对象标签相同。
它们的主要目的是引用其他实体,以及以某种方式对当前实体进行分类的信息。它们通常用作查询或筛选器中的值。
键和值都是字符串,受以下限制的约束。
键具有可选前缀,后跟斜杠,然后是必需的名称部分。前缀(如果存在)必须是有效的小写域名,总共最多 253 个字符。必须由[a-z0-9A-Z]序列组成,可能由[-.]之一分隔,总共最多 63 个字符。
前缀保留供后台核心组件使用。backstage.io/
值是遵循与name相同限制的字符串。
annotations[可选]
一个附加到实体的任意非识别元数据的对象,在使用上与Kubernetes 对象注释相同。其目的主要是(但不限于)参考外部系统。例如,这可能是对从中摄取实体的git ref的引用,也可能是对监控和日志记录系统、PagerDuty时间表等的引用。用户可以将这些添加到描述符YAML文件中。其键值要求与name相同。
tags[可选]
单值字符串的列表,例如,用于以各种方式对目录实体进行分类。这与元数据中的标签不同,因为标签是键值对。
这些值是用户定义的,例如用于组件的编程语言,如 或 。javago
此字段是可选的,目前没有特殊的语义。
键值约束与name相同。
links[可选]
与实体相关的外部超链接的列表。链接可以提供可能位于 开发者门户本身之外的其他上下文信息。例如,管理仪表板或外部 CMS 页面。
用户可以添加指向描述符 YAML 文件的链接,以提供外部内容和资源的其他参考信息。
链接的字段包括:
字段 | 类型 | 描述 |
---|---|---|
url | String | [必填]标准uri格式的 url(例如https://example.com/some/page) |
title | String | [可选]链接的用户友好显示名称。 |
icon | String | [可选]表示要在UI中显示的可视图标的键。 |
component描述软件组件。它通常与构成组件的源代码密切相关,并且应该是开发人员可能认为的"软件单元",通常具有独特的可部署或可链接的工件。软件研发工作的核心便是component,例如一个微服务,一个前端网站。component的部分字段如下。
spec.type[必填]
字符串形式的组件类型。支持任何类型的组件,但内置三种,如需添加,可自定义。
spec.lifecycle[必填]
组件的生命周期状态,默认为以下值。如有需求,可自定义添加。
spec.owner[必填]
对组件所有者的实体引用。组件的所有者是对组件承担最终责任的单一实体(通常是团队),并且具有开发和维护组件的权限和能力。如果出现问题或请求功能,他们将是联系点。
spec.providesApis[可选]
对组件提供的 API 的实体引用的数组,代表该组件实体可提供的API服务。
spec.consumesApis[可选]
对组件使用的 API 的实体引用的数组,代表该组件实体使用的API服务。
component描述软件组件。它通常与构成组件的源代码密切相关,并且应该是开发人员可能认为的"软件单元",通常具有独特的可部署或可链接的工件。软件研发工作的核心便是component,例如一个微服务,一个前端网站。component的部分字段如下。
metadata.tags[可选]
可与模板关联的字符串列表,例如 ['recommended', 'react']
此列表还将在前端使用,以显示给用户,以便您可以按这些标记搜索和分组模板。
spec.type[必填]
由该模板创建的组件类型,如website。这用于筛选模板,理想情况下应与模板创建的组件spec.type匹配。
spec.parameters[必填]
使用模板创建组件时,UI页面上显示的字段。参见使用模板创建组件小节,界面中所有显示及要输入的字段都是由这里定义的。
spec.steps[可选]
使用模板创建组件时的步骤,参见使用模板创建组件小节,每一步均是由这里定义。
spec.owner[必填]
该模板的所有者
spec.type[必填]
字符串形式的 API 定义类型,默认类型有:
spec.lifecycle[必填]
API 的生命周期状态,如production。默认类型:
spec.owner[必填]
API的所有者。
spec.definition[必填]
API的定义,基于spec.type定义的格式。
若您同时使用了项目协作平台,这里的项目便是项目协作平台的项目,也是项目协作平台与开发者门户工作对接的桥梁。 如需添加项目,请从项目协作平台中添加。
一个项目有一个或多个产品,一个产品有一个或多个应用,一个应用由一个或多个组件组成。在【项目】中,可以看到使用当前平台的项目,通过项目可以进入到项目包含的组件中。
component中的每一种类型实体都是一个组件,常用的组件有以下四种:website、service、documentation、API,您可以自定义组件类型。每一个组件都可以在服务目录中查询到。
组件有两种添加方式:基于模板从无到有创建、通过注册将已有组件纳入开发者门户。
一:通过模板添加
二:注册现有组件
模板可以帮助您统一企业技术架构,将推广和复用的技术栈在开发者门户中作为模板,将代码框架,以及某些 变量中的模板,发布到指定位置。帮助开发人员快速创建组件,或是页面,包括单独发布的HTML页面(以markdown文档发布)。
模板以yaml的形式存储在代码仓库中,存储位置联系管理员获取。使用描述模板及其元数据的小定义创建模板。一个简单的模板例子:
模板配置参考YAML配置中的kind:Template。
【创建中】找到对应的模板,点击选择,进入创建流程,可以创建的组件类型有:前端工程、后端服务、后端微服务、文档、API、库(前端组件、工具等)。创建页面对于每个模板可能看起来不同,以spring boot gRPC为例
输入组件名称、对应的镜像包名称、填写描述以便平台用户可以了解此服务功能、选择组件所有者,可以是团队、组织或个人。填写完成点击【下一步】进入代码仓库配置。此处页面中的字段即使yaml配置中的spec.parameters字段值。此处的步骤,即spec.steps配置。
下拉选择存储库主机URL;输入需要创建的存储库所有者:可以输入的字段为gitlab中group名称(将会创建在此group下创建)、gitlab用户名(将会在此用户命名空间下创建);输入存储库名称,对应代码仓的repo,输入完成点击【下一步】进行CI配置。
与CI配置相同,选择使用的模板,并基于模板修改CD配置。点击【下一步】预览信息,可以返回修改,如确定不需要再修改信息,点击创建完成。
创建过程日志在界面中输出,可查看不同阶段输出日志,当创建完成,点击【repo】跳转到代码仓。
上述模板对应的配置为:
apiVersion: backstage.io/v1beta2
kind: Template
metadata:
name: springboot-template
title: Spring Boot gRPC Service
description: Create a simple microservice using gRPC and Spring Boot Java
tags:
- recommended
- java
- grpc
spec:
owner: service@example.com
type: service
parameters:
- title: 提供一些简单的信息
required:
- component_id
- owner
- java_package_name
properties:
component_id:
title: 名称
type: string
description: 组件的唯一名称
java_package_name:
title: java包的名称
type: string
description: java包的名称。eg (io.backstage.blah)
description:
title: 描述
type: string
description: 帮助其他人了解此网站的用途。
owner:
title: 所有者
type: string
description: 组件的所有者
ui:field: OwnerPicker
ui:options:
allowedKinds:
- Group
- title: 选择存储库
required:
- repoUrl
properties:
repoUrl:
title: 存储库位置
type: string
ui:field: RepoUrlPicker
ui:options:
allowedHosts:
- gitlab.dev.rdev.tech
- title: 选择流水线模板
required:
- fileID
properties:
fileID:
title: 模板
type: string
description: 选择流水线模板
ui:field: CICDPicker
ui:options:
rows: 5
steps:
- id: template
name: 生成应用
action: fetch:template
input:
url: ./skeleton
# copyWithoutRender:
# - .github/workflows/*
cookiecutterCompat: true
values:
component_id: '{{ parameters.component_id }}'
description: '{{ parameters.description }}'
artifact_id: '{{ parameters.component_id }}'
java_package_name: '{{ parameters.java_package_name }}'
owner: '{{ parameters.owner }}'
destination: '{{ parseRepoUrl parameters.repoUrl }}'
http_port: 8080
- id: publish
name: 推送
action: publish:gitlab
input:
allowedHosts: ['gitlab.dev.rdev.tech']
description: '这是 {{ parameters.component_id }}'
repoUrl: '{{ parameters.repoUrl }}'
- id: register
name: 注册应用
action: catalog:register
input:
repoContentsUrl: '{{ steps.publish.output.repoContentsUrl }}'
catalogInfoPath: '/catalog-info.yaml'
- id: create
name: 配置流水线
action: configuration:pipeline
input:
name: '{{ parameters.name }}'
description: '{{ parameters.description }}'
owner: '{{ parameters.owner }}'
repoUrl: '{{ parameters.repoUrl }}'
fileID: '{{ parameters.fileID }}'
component: '{{ parameters.component_id }}'
output:
remoteUrl: '{{ steps.publish.output.remoteUrl }}'
entityRef: '{{ steps.register.output.entityRef }}'
在首页点击【创建服务】进入跟踪微服务,此功能是将已经存在的一个业务实体(微服务、微前端、组件等)注册进微服务平台。
前置条件:
组件实体所在存储库的根目录中包含以下内容的文件:catalog-info.yaml
在【注册现有组件】页面,输入组件的URL,此URL为改组件代码仓中catalog.ymal文件地址。如:https://gitlab.dev.rdev.tech/micro-service/bktest90/-/blob/master/catalog-info.yaml
输入完成后点击【分析】进入下一步,预览文件,确认信息无误后点击【导入】完成注册。
进入一个前端组件或后端组件(类型为website或service),可以获取到此应用的生命周期数据。
点击MERGE REQUEST可以查看该组件代码提交情况。
对代码进行自动化静态扫描,若不通过则终止构建,扫描结果如下;若无代码扫描结果并提示缺少注释,在缺定您希望开启代码扫描后按照提示在组件的catalog-info.yaml文件中添加相应注释即可开启
除静态扫描外,还可以检测出代码中的TODO代码段.
在CI/CD页面显示此组件的流水线记录
构建完成,镜像被推倒镜像仓库中,可以在HARBOR页面看到镜像信息
流水线构建完成,触发自动部署,部署情况显示在ARGOCD页面。
镜像成功部署后将会自动启动,对应的pod信息可以在kubernetes页面看到。这是 是一个面向服务所有者,而不是集群管理员的需求。无论这些服务以何种方式或位置部署,无论是在本地主机还是生产环境,开发人员都可以轻松检查其服务的运行状况。
API通常来自于组件,在微服务架构中,大型服务都被拆分成了独立的微服务,每个微服务通常会以RESTFUL API的形式对外提供服务。通过API,我们可以清楚的知道企业内已经提供的接口服务,一方面减少重复开发的工作,另一方面可以了解到不同的微服务可以提供哪些服务,以及在api网关管理中了解api的使用情况及链路追踪。
可以在【APIs】中看到平台所有后端服务对外提供的接口。
注册API需要按照API的要求格式编写yaml配置文件。其中,definition字段选填,内容是此API的接口详情,通过definition字段的描述,开发者门户可以解析此接口的类型及输入输出,并可以做简单接口测试。
基础配置:
接口配置:
API与服务的关系需要在服务的catalog-info.yaml中配置。如下例中名为petstore的service提供3个api,通过providersApis描述此服务提供的接口,在服务详情中,可以看到提供的API列表,同时,在API的详情中可以看到提供此接口的服务是petstore 。
通过创建组件入口进入注册页面,在注册页面中的URL字段中输入API对应的ymal地址,如图,底图为某接口配置文件,小窗为微服务平台注册组件页面。
通过注册API,可以在【APIs】中看到该接口。也可直接在此处查看平台已有的接口。进入查看某一接口,可以获取此接口描述、代码地址(若有权限可以查看其代码仓中源代码)、提供此接口的服务,以及订阅此接口的消费实体。
若在API中定义了definition字段,则可以在API详情中的【定义】中看到该接口的描述。
点击【try it out】可以查询该接口返回值
技术文档是类似文档的代码解决方案,开发人员将技术文档编写在markdown文件中,这些文件与他们的代码一起存在。
特征
•与软件环境无关,无论软件环境如何设置,都可以部署技术文档
•从服务页面中可以查找服务的的技术文档
•只需编写markdown文档即可创建用于任何目的的纯文档站点
•搜索和查找文档
创建基本文档设置
技术文档建立在代码方法等文档上,即,文档应该靠近代码。我们强烈建议您将文档添加在代码目录中。
开发者门户中应用默认添加了一组软件模板,所有这些软件模板都包含启动和运行技术文档站点并开始文档别写所需的一切
文档示例——服务文档
文档示例——单站点文档
先决条件:
为文档实体所在存储库的根目录中创建一个包含以下内容的文件:mkdocs.yml
通过以下行添加到组件存储库根目录中来更新组件的实体描述:catalog-info.yaml
文档使用backstage.io/techdocs-ref注释来下载文档源文件,以生成实体的 TechDocs 站点。
在存储库的根目录中创建一个文件夹,其中至少包含一个文件。(如果添加更多 markdown 文件,请确保更新 mkdocs.yml 文件中的导航,以便为文档获取正确的导航。/docsindex.md
提交更改,打开拉取请求合并,将获得更新的文档。
例如,某单文档站点在代码仓库中的目录如下:
1.在左侧导航栏中点击【创建】——【注册现有组件】进入注册页面
2.在注册页面中填写第一步URL,此地址为该文档实体的catalog-info.yaml文件地址。如https://gitlab.dev.rdev.tech/dev_platform/backstage_mkdocs/-/blob/master/catalog-info.yaml
3.在输入URL之后点击【分析】开发者门户将会解析该文件,识别当前文档实体并回显相关信息
4.点击【导入】即可将该实体添加到服务目录中
当您仅需要发布一个文档而非代码的技术文档是,例如:入门教程。可以通过文档模板创建,该模板仅报含文档配置和牧人标记文件的组件。点击【创建】中的documentation类型的模板卡片中的【选择】,完成从模板创建文档
在创建流程中,输入相关的信息,这里的字段与service是一致的
在最后一步预览信息,确认信息输入正确,点击【创建】即可完成文档创建,在服务目录中可以查看到创建的文档。
APISIX 是一个云原生、高性能、可扩展的微服务 API 网关。
它是基于 Nginx 和 etcd 来实现,和传统 API 网关相比,APISIX 具备动态路由和插件热加载,特别适合微服务体系下的 API 管理。
APISIX 是基于云原生的微服务 API 网关,它是所有业务流量的入口,可以处理传统的南北向流量,也可以处理服务间的东西向流量,也可以当做 k8s ingress controller 来使用。
APISIX 通过插件机制,提供动态负载平衡、身份验证、限流限速等功能,并且支持你自己开发的插件。
可以把 Apache APISIX 当做流量入口,来处理所有的业务数据,包括动态路由、动态上游、动态证书、
A/B 测试、金丝雀发布(灰度发布)、蓝绿部署、限流限速、抵御恶意攻击、监控报警、服务可观测性、服务治理等。
创建一个 路由(Route )并与上游服务(通常也被称为Upstream或后端服务)绑定,当一个 请求(Request) 到达 Apache APISIX 时,Apache APISIX 就会明白这个请求应该转发到哪个上游服务中。
因为我们为 Route Apache APISIX Route
这条路由配置意味着,当它们满足下述的 所有 规则时,所有匹配的入站请求都将被转发到 httpbin.org:80 这个上游服务:
•请求的 HTTP 方法为 GET。
•请求头包含 host 字段,且它的值为 example.com。
•请求路径匹配 /services/users/, 意味着任意的子路径,例如 /services/users/getAll?limit=10。
当这条路由创建后,我们可以使用 APISIX 对外暴露的地址去访问上游服务。
路由Route ,通过定义一些规则来匹配客户端的请求,然后根据匹配结果加载并执行相应的 插件,并把请求转发给到指定 Upstream。
Route 中主要包含三部分内容:匹配规则(比如 uri、host、remote_addr 等),插件配置(限流限速等)和上游信息。 请看下图示例,是一些 Route 规则的实例,当某些属性值相同时,图中用相同颜色标识。
进入APISIX——路由,点击【创建】按钮
第一步:设置路由信息
第二步,设置上游服务
第三步,插件配置
上游服务Upstream 是虚拟主机抽象,对给定的多个服务节点按照配置规则进行负载均衡。Upstream 的地址信息可以直接配置到 Route(或 Service) 上,当 Upstream 有重复时,就需要用“引用”方式避免重复了。
如图所示,通过创建 Upstream 对象,在 Route 用 ID 方式引用,就可以确保只维护一个对象的值了。
Upstream 的配置可以被直接绑定在指定 Route 中,也可以被绑定在 Service 中,不过 Route 中的配置 优先级更高。
•上游对象创建后,均可以被具体 Route 或 Service 引用
•为了方便使用,也可以直接把上游地址直接绑到某个 Route 或 Service
进入APISIX——上游服务,点击【创建】按钮
输入相关基础信息,点击下一步预览,确认输入无误后点击【提交】完成创建
服务Service 是某类 API 的抽象(也可以理解为一组 Route 的抽象)。它通常与上游服务抽象是一一对应的,Route 与 Service 之间,通常是 N:1 的关系,参看下图。
•不同 Route 规则同时绑定到一个 Service 上,这些 Route 将具有相同的上游和插件配置,减少冗余配置。
•也可以为 Route 指定不同的插件参数或上游
•注意:当 Route 和 Service 都开启同一个插件时,Route 参数的优先级是高于 Service 的。
进入APISIX——服务列表,点击【创建】按钮
输入基本信息,选择插件并配置,预览确认无误后点击【提交】即可创建
对于 API 网关通常可以用请求域名、客户端 IP 地址等字段识别到某类请求方, 然后进行插件过滤并转发请求到指定上游,但有时候这个深度不够。知道 API Consumer(消费方)具体是谁,这样就可以对不同 API Consumer 配置不同规则。
Consumer 是某类服务的消费者,需与用户认证体系配合才能使用。 比如不同的 Consumer 请求同一个 API,网关服务根据当前请求用户信息,对应不同的 Plugin 或 Upstream 配置。
识别消费者的过程:
1.授权认证:比如有 key-auth、JWT 等。
2.获取 consumer_name:通过授权认证,即可自然获取到对应的 Consumer name,它是 Consumer 对象的唯一识别标识。
3.获取 Consumer 上绑定的 Plugin 或 Upstream 信息:完成对不同 Consumer 做不同配置的效果。
进入APISIX——消费者,点击【创建】按钮
在创建页面输入基础信息并配置插件,预览之后确认便可成功创建