云原生计算基金会(简称 CNCF)最近宣布接受 Dapr 作为 CNCF 的孵化器项目。在此之前,Dapr 宣布成立 Dapr 项目指导和技术委员会(简称 STC)。
作为 CNCF 托管的项目,Dapr 也在技术方面保持中立。CNCF 提供了监管、市场支持和社区拓展方面的能力。CNCF CTO Chris Aniszczyk 表示:
分布式应用程序和微服务为容器和云原生奠定了基础,但开发具备可伸缩性和可靠性的分布式应用程序非常困难。Dapr 可以很好地与 CNCF 的其他项目集成,并为开发人员提供最佳实践,他们可以使用任意的编程语言和框架来开发应用程序。我们非常欢迎 Dapr 加入 CNCF,以及 Dapr 社区所做的工作。
微软在 2019 年推出了 Dapr。今年 2 月份,Dapr 团队发布了 Dapr 1.0。很多 组织 在生产环境中使用 Dapr。今年 3 月份,InfoQ报导 了阿里云在云上采用 Dapr 的案例。一些主流的云厂商平台和本地环境均有采用 Dapr。
现在,该项目由 Dapr STC 以及来自阿里巴巴、英特尔和微软的代表共同管理。STC 把握项目的整体方向,并为项目维护者提供技术指导。
最近,InfoQ 采访了 Dapr 及 KEDA 的联合创建者 Yaron Schneider,他同时也是 Dapr STC 的成员。
Yaron Schneider:Dapr 成为 CNCF 的孵化器项目将在以下几个方面给项目本身以及云原生生态系统带来影响。对于 Dapr 来说,它将吸引更多的 CNCF 开发者的注意,带来新的贡献和视角。对于 CNCF 来说,Dapr 开发者社区会将以应用程序为中心的视角和专业知识带入整个生态系统。随着越来越多的开发者的加入,他们会加入更多有利于 Dpar 用户的特性。
Schneider:我们看到了针对该项目的贡献力度、采用它的企业和初创公司都有了巨大的增长。10 月份,我们举办了第一个 DaprCon 大会,很多采用者在大会上分享了他们的故事。我强烈建议大家去看一下大会的内容,了解一下从该项目出现至今的发展历程。随着项目加入 CNCF,我非常期望看到有更多的采用者。
Schneider:STC 目前由来自不同公司的 5 位成员组成,后续可能会增加到 11 位。没有哪个单独的组织可以代表整体,由此保证了中立性。从特性方面来看,Dapr 的维护者们是主要的决策者,STC 的引入并不会改变这一点。不过,STC 把握项目的整体方向,所以,加入新的构建块和 API 可能需要经过 STC 的审批。
Schneider:微服务开发者们会发现 Dapr 很有用,因为它可以帮他们完成很多事情。Dapr 提供了很多 API 到工具层面的最佳实践,帮助开发者完成状态管理和发布 / 订阅之类的分布式系统特性。我们发现,对于那些在 Kubernetes 上部署应用程序的开发者来说,Dapr 特别有用。Dapr 提供的 API 可以在本地开发环境和 Kubernetes 集群上保持一致。
Schneider:我们试着确定基础性的东西——测试基础设施和发布管道及流程。我们希望向社区开放 Dapr 的发布流程。在特性方面,即将发布的 1.5 版本将会带来配置构建块,一个已经开发了好几个月的特性。
Schneider:Dapr 加入 CNCF 之后,我希望 Dapr API 能够成为一个标准,并与 Go 语言实现彻底分离。这一改变将允许出现其他不同的实现,比如 Dapr 边缘发行版。2.0 版本目前不在发布日程中,不过,后续可能会考虑支持非 Go 语言组件以及动态组件加载。
Schneider:Dapr 官方 文档 和 入门示例 是学习 Dapr 最好的资源。除了这些,还有其他一些很好的书籍。我推荐“Introducing Distributed Application Runtime (Dapr)”和“Practical Microservices with Dapr and .NET”。当然,我自己也写了一本《学习 Dapr》。
Dapr 是一个开源、可移植、基于事件驱动的运行时,开发者可以用它构建运行在云端和边缘的具有弹性、无状态、有状态、基于微服务的应用程序。其目标是帮助开发者解决分布式系统问题,让他们能够专注于编写业务逻辑,大幅提升他们的效率以及缩短开发时间。微软最近推出的 Azure Container App 预览版也支持 Dapr。
查看英文原文:
https://www.infoq.com/news/2021/11/dapr-joins-cncf/
点个在看少个 bug 👇