微软推出面向云原生时代的开源应用平台Radius

Dapr和KEDA已经是云原生计算基金会（CNCF）稳定项目的一部分，微软最近也提交了Copacetic。因此，该公司还计划在未来六个月内将Radius提交给CNCF也就不足为奇了。

有了 Radius，开发人员就能将应用部署到私有云、微软自己的 Azure 和亚马逊的 AWS，不久还将支持Google云。这里的总体思路是，虽然 Kubernetes 使得构建至少在理论上可以在任何地方运行的应用程序变得更加容易，但这些应用程序也变得越来越复杂，从而增加了管理它们的难度。理想情况下，应用平台可以抽象出这一切，让开发人员专注于编写应用。

我们过去曾见过试图将所有基础架构从开发人员手中抽象出来的其他应用平台，包括 Cloud Foundry 项目和围绕它构建的商业服务，如 VMware 的 Tanzu 应用服务。但正如Azure首席技术官兼微软技术研究员马克-鲁西诺维奇（Mark Russinovich）告诉我的那样，Radius正在采用一种截然不同的方法来解决这个问题：

"我们正在做的与众不同的事情之一是，我们希望 Radius 能够支持所有类型的应用程序，而不仅仅是对应用程序的架构有纵向意见，或者只支持某种模式的应用程序（如 12 要素），或者要求应用程序本身以某种方式编写。Radius 本身对应用程序的编写方式不持任何意见，而且足够灵活，可以支持企业中仍在构建的大量两层和三层应用程序。虽然现在已经实现了容器化，但它们仍然是这种架构。此外，它还能支持复杂的基于微服务的应用，包括十几或二十几个微服务。"

他还指出，竞争对手的平台都非常注重描述应用程序或微服务的计算层之间的关系，但它们往往将构成现代应用程序的其他云资源作为外部关注点。

"Radius的目标是，作为开发人员，我可以完整地描述我的应用--不仅仅是计算部分，还有它们使用的资源，比如，在这个前端和这个后端之间有一个PubSub。这个微服务上有一个状态存储，所有云资源中的任何资源都可以这样描述。因此，你最终会得到一个完整的应用图。作为开发人员有动力利用 Radius 来描述这些关系，因为它背后为你做了很多工作。"

微软指出，它设计 Radius 是为了满足开发人员的需求。例如，它并没有试图完全重塑基础设施即代码（infrastructure-as-a-code）的概念，而是利用了 Terraform（也可能是 OpenTofu，只要保持兼容即可）和 Bicep 等现有工具。它还集成了 GitHub Actions 等 CI/CD 服务。

Radius 的核心是一个通用控制平面，它基于 Azure Resource Manager 部署引擎，也就是公司在 Azure 中用于管理应用程序部署的部署协调器，公司将在未来六个月内开源这个资源管理器。他还指出，部署引擎之上的特定域基础设施即代码语言Bicep已经开源。

微软还与康卡斯特（Comcast）和葡萄牙千禧银行（Millennium BCP）合作，使Radius可以在任何云上运行。

在许多方面，微软对Radius采用了与Dapr分布式应用程序运行时相同的整体策略。它将该服务作为一个开源项目推出，并将其置于 CNCF 的管理之下。随后，Dapr 还催生了一些围绕该项目的商业活动，包括 Diagrid 等公司，也许有一天 Azure 本身也会提供基于 Radius 的应用平台。