利用 Radius Resource Types 扩展平台工程能力

Azure 孵化团队此前已向 CNCF（云原生计算基金会）贡献了多个知名开源项目，包括 KEDA、Dapr、Copacetic、Drasi 以及本文重点介绍的 Radius。

Radius 是一个专为平台工程师打造的云原生平台构建工具，旨在帮助企业构建内部开发者平台（Internal Developer Platform，IDP），提升应用团队与平台团队之间的协作效率。借助 Recipes、Environments 和 Application Graph 等核心功能，Radius 支持构建与云平台无关的应用程序。

几周前，团队推出了一项新功能 Radius Resource Types，这是在早期用户反馈指导下推出的重要能力升级，代表着平台工程向前迈进了一大步。Radius 可帮助平台工程师构建“以应用为中心”的 IDP，而非以基础架构为中心的 IDP。

现在，通过 Radius Resource Types，平台工程师可以根据自身组织的需求，自定义资源类型，并通过 Radius Recipes 实现具体资源逻辑。这些 Recipes 可以是新的，也可以是现有的 Terraform 配置或 Bicep 模板。更值得称赞的是：同一个 Resource Type 可以在不同 Environment 中使用不同的 Recipe，真正实现跨环境、跨平台的灵活交付。

Radius 的演进之路

最初推出 Radius 时，它的使命是以云原生的方式重新定义应用程序开发模型。开发者可以定义应用程序及其资源，这些资源可以来自 AWS、Azure 或是 Kubernetes。Radius 通用控制平面（Radius Universal Control Plane）可以理解这些类型，并与 Radius 环境配置（Radius Environment configurations）结合，将应用程序及其资源部署到正确的云平台与区域，实现跨云交付。

许多采用多云战略的企业告诉我们，他们面临的最大难题是：如何构建真正具备可移植性的应用。这促使团队在 Radius 中建立了对开源、可移植资源类型和 Dapr 资源类型的支持，这两种类型都允许开发者能够构建跨云平台可迁移的应用。

此外，借助 Recipes 和 Environments，平台团队还能根据不同的用例，针对不同的需求定制资源类型。比如，同一个数据库资源可以根据是否为生产环境而采用不同配置。这实现了 Radius 将应用定义与平台实施分离的最初愿景。

虽然早期用户喜欢使用 Recipes 部署开源和 Dapr 类型，但他们也反馈：希望能创建自己的资源类型。在实际场景中，很多组织已经拥有内部开发平台（IDP），其中包含了为业务定制的资源类型，而这些类型最初并不被 Radius 平台支持。他们需要一种方式，将自己的资源类型引入 Radius，并通过 Recipes 进行部署，就像使用内部资源类型一样方便。

这些自定义资源既可以是简单的，比如一个 PostgreSQL 数据库，并允许开发者指定资源规格；也可以是复杂的抽象类型，比如一个完整的 Web 服务资源，将一整套基础设施封装为一个资源类型。

Radius Resource Types

在听取了早期用户的反馈后，Radius 推出了全新功能 —— Radius Resource Types。新功能将 Recipe 的支持范围，从内建资源类型拓展到用户自定义资源类型，让平台工程师可以为其组织定义自己的资源类型，并提供面向开发者的定制化 API。

Radius Resource Types 的推出，实现了资源接口与底层配置解耦。这种解耦为平台工程师提供了强大的能力，平台工程师可以灵活控制资源的实现逻辑，并按需调整且不会影响开发者已有的使用方式。而开发者只需关注资源接口，无需关心其部署细节。

全新功能不仅提升了平台工程师的管理能力，也极大简化了开发者的体验，让资源使用变得更加模块化、可复用、易维护。

作为微软中国南区核心合作伙伴及HKCSP 1T首批授权云服务商之一，领驭科技正积极整合Azure OpenAI的强大功能，包括先进的自然语言处理、分析和推理能力，到其产品和行业解决方案中。

Azure OpenAI服务通过其大规模生成式AI模型，支持企业客户根据特定需求和场景，开发创新应用，涵盖辅助写作、代码编写、多媒体内容生成以及数据分析等多个领域，为互联网、游戏、金融、零售、医药等行业以及自动驾驶和智能制造等前沿技术领域带来深远影响。