前言 - 面向 .NET 开发人员的 Dapr

提示

此内容摘自电子书《面向 .NET 开发人员的 Dapr》,可在 .NET 文档上获取,也可作为免费可下载的 PDF 脱机阅读。

《面向 .NET 开发人员的 Dapr》电子书封面缩略图。

随着云采用的发展浪潮,“云原生”开发(通常使用微服务体系结构构建)发生了重大转变。 这些微服务既无状态又有状态,在云和边缘运行,采用目前可用的多种语言和框架。 推动这种企业转变的是加快上市时间的市场力量以及构建云服务的规模和效率。 即使在 COVID-19 之前,企业也在加速云采用,要求开发人员执行更多工作来构建这些分布式系统应用程序。 这在 COVID-19 之后就只能加速了。 企业中开发人员寻求专注于业务逻辑,同时依靠平台为应用程序提供缩放性、复原能力、可维护性、弹性和云原生体系结构的其他属性,正因如此,也转向隐藏底层基础结构的无服务器平台。 不应期望开发人员成为分布式系统专家。 无论你是在 Kubernetes 等基础结构上构建,还是在无服务器平台上构建,Dapr 都可为你提供帮助。

Dapr 是一个以开发人员为中心的企业微服务编程模型平台,其要求是“任何语言、任何框架、随处运行”。 它使构建分布式应用程序变得简单且可移植到任何基础结构(从公有云到分层边缘,甚至到单节点 IoT 设备)。 它的出现源于我们在 Azure 中构建服务的经验,以及我们花费时间与客户一起在 Azure Kubernetes 服务和 Azure Service Fabric 上构建应用程序。 我们一次又一次地看到他们必须解决的常见问题。 显然,需要提供开发人员可以使用的常见微服务最佳做法的“库”,不仅需要用于新的绿色领域应用程序,而且还有助于现有应用程序的现代化。 在容器化、分布式和网络化的云原生世界,sidecar 模型已作为首选方法出现,其方式与在客户端/服务器生成中首选 DLL 的方式相同。 使用 Dapr 的 sidecar 和 API,开发人员可以借助单个 HTTP 或 gRPC 本地调用轻松获得分布式系统功能的所有能力。

为了应对开发人员面临的各种情况,Dapr 提供了一些功能,例如状态管理、服务到服务调用、发布/订阅以及与具有 I/O 绑定的外部系统集成,这些功能基于 Azure Functions 的触发器和绑定。 反过来,这些功能利用 Dapr 的组件模型,这样你无需更改任何代码便可“交换”不同的基础状态存储等。 此组件模型使代码更具可移植性、更灵活,并允许试验最适合你的需求的代码。 开发人员无需学习和将服务 SDK 合并到代码中,也无需担心针对特定部署环境的身份验证、机密管理、重试或条件代码。

本书展示了 Dapr 如何通过逐渐“Daper 化”典型 .NET 参考应用程序 eShop 来缩短开发时间和减少整体代码维护。 例如,在原始 eShop 实现中,为了在 Azure 服务总线和 RabbitMQ 之间抽象以在服务之间发布事件,编写大量代码。 现在所有这些代码都可以丢弃,并直接替换为 Dapr 的发布/订阅 API 和组件模型,该模型具有更广泛的发布/订阅代理,而不只是两个代理。 Dapr 的执行器组件模型在经过修改的 eShop 应用程序中使用时,显示出可以轻松构建长时间运行的、有状态的、事件驱动的工作流应用程序,同时消除了并发和多线程处理的所有难题。 在本书结束时,你将看到 Dapr 为应用程序开发带来巨大简化,我坚信所有开始云原生应用构建旅程的开发人员都应使用 Dapr。

我们在 2019 年 10 月公开发布了 v0.1 版 Dapr,现在过了一年半,我很高兴地说 Dapr 已准备好将 v1.0 版本用于生产。 将 Dapr 升级到 v1.0 确实需要社区努力。 很高兴看到开源社区围绕 Dapr 进行联合并且从首次发布以来就在增长,从 2019 年 10 月的 114 位参与者发展到 2021 年初的 700 多个参与者 - 在 16 个月内增加了 6 倍! 对项目的贡献已进入每个 Dapr 存储库,包括开立问题、评论功能建议、提供示例,当然还有贡献代码。 社区成员对项目贡献最大的部分包括 Dapr 运行时、文档、CLI、SDK 和创建丰富的组件生态系统。 保持这种开放对 Dapr 的未来至关重要。

但是,Dapr 才刚开始,你应该会看到更多 Dapr 功能和 Azure 服务中对 Dapr 的更多支持。 希望你能够利用 Dapr 来专注于核心业务逻辑并加速微服务开发。 我们很高兴邀请你加入我们 Dapr 社区,参与此旅程 (https://github.com/dapr/) 和 Discord (https://aka.ms/dapr-discord)。

新式分布式系统非常复杂。 你可以从小型、松散耦合、可独立部署的服务开始。 这些服务跨进程和服务器边界。 然后,它们使用不同类型的基础结构支持服务(数据库、消息代理、密钥保管库)。 最后,这些分散的部分组合在一起构成应用程序。

Microsoft Azure CTO 兼技术专家 Mark Russinovich