「2022 年什么会火？什么该学？本文正在参与“聊聊 2022 技术趋势”征文活动 」

原文：Why You Should Use Microsoft Dapr to Build Event-driven Microservices

作者：Dunith Dhanushka

微服务架构从本质上来说是分布式的。构建微服务总是会遇到极具挑战性的问题，比如说弹性服务调用、分布式事务处理、按需扩容以及严格一次(exactly-once)的消息处理。将微服务放在 Kubernetes 上并不是解决这些问题的银弹，因为 Kubernetes 没有应用程序逻辑。Spring Boot、Akka 和 Quarkus 这些框架在构建分布式微服务架构时很有用，但是它们与特定的编程语言耦合。

因此，我们还在寻找可移植的运行时来构建分布式、可扩展和事件驱动的微服务。

Dapr 分布式应用程序运行时

Dapr是一个可移植的、事件驱动的运行时，它使任何开发者能轻松地构建在云和边缘运行的弹性、无状态和有状态的应用程序，并且支持多种语言和开发框架。

在我看来，以下是 Dapr 胜过其竞争对手的要点。

Dapr 有预先建立的组件来解决一系列常见的问题。

Dapr将构建微服务应用程序的最佳实践编入开放、独立的构建块中，以解决日常问题，如状态管理、事件处理、与外部系统的 binding、 actor 等。

每个构建块都是完全独立的，我们可以在应用程序中使用其中的任意部分甚至是全部。

Dapr 的构建块 — 出处

Dapr 是可移植的

上面提到的构建模块可以作为一个可移植的运行时间。具体来说，Dapr 作为一个 Sidecar (边车)运行，允许我们的应用程序通过标准的 HTTP 和 gRPC 接口与它进行交互。这样开发者就能够用他们喜欢的语言和框架来构建可移植的应用程序。

Dapr 是跨平台的

Dapr 是跨平台的，这意味着我们可以在本地、任何 Kubernetes 集群以及其他安装了 Dapr 的托管环境中运行我们的应用程序。这使我们能建立在云和边缘运行的微服务应用。

Dapr 生态系统 — 出处

利用Dapr构建事件驱动的微服务

典型的事件驱动架构 — 出处

一个事件驱动的系统是由松耦合的、自治(self-contained)的组件组成的，这些组件利用事件来相互通信。我们可以对这些组件进行分组，并根据它们与事件的交互方式为它们分配以下角色。

事件生产者 -- 谁在生产事件？
事件消费者 -- 谁在消费事件？
事件服务器(broker) -- 谁来存储事件，直到它们被消费掉

构建一个事件驱动的系统意味着确定哪些组件将扮演上述角色，并仔细地使用事件对其异步交互进行建模。

在具有移植性和跨平台性的同时，以下是我们应该考虑用 Dapr 来构建下一个事件驱动系统的五个原因。

1. 用松耦合、多语言的组件组成你的系统

Dapr将其 API 作为一个 sidecar 架构公开，可以是容器，也可以是进程，不要求应用程序代码包含任何 Dapr 运行时代码。

如下图所示，应用程序代码可以通过标准接口（如 HTTP 和 gRPC ）与 Dapr API 进行通信。

构建块如何暴露一个公共 API，从你的代码中调用，使用组件来实现构建模块的能力。

这使得开发者可以选择他们最喜欢的编程语言来建立松耦合的、多语言的组件，这些组件构成了事件驱动系统，同时利用了 Dapr 带来的能力。

例如，一个基于 Java 的订单处理组件可以通过共同的 Dapr 运行时和一个基于 NodeJS 的电子邮件组件进行通信。

2. 用其构建块为生产和消费事件提供一流的支持

Dapr的发布/订阅组件提供了一个与平台无关的 API 来发送和接收消息，并保证至少一次。

发布消息需要你的服务对 Dapr 发布/订阅组件进行网络调用，该构件作为一个 Sidecar 暴露出来。这个构件然后调用Dapr 发布/订阅组件，该组件封装了一个特定的消息服务器(broker)应用。为了接收消息，Dapr 代表你的服务订阅Dapr 发布/订阅组件，并在消息到达时将其传送到对应的终端。

这种方法使你的服务实现具有可移植性，并减少对底层消息传递基础设施的依赖。Dapr 目前支持广泛的消息代理，包括Redis、Kafka、NATS和类似 AWS SQS/SNS、Azure EventHubs和Google Pub/sub等的云服务。

此外，你可以用来自外部系统的事件触发你的服务，或者用 Dapr Binding 与外部系统对接。 Binding 不需要写模板代码来连接和轮询消息系统（如消息队列和消息总线）。

3. 轻松驾驭Kubernetes的真正力量。

Dapr 是平台无关的，可以在任何托管环境下运行，包括本地、Kubernetes 和公有云，例如 AWS、Azure 和 GCP。

在 Kubernetes 上部署事件驱动的微服务在按需扩容、高可用性和可移植性方面有一些额外的好处。对于 Kubernetes，Dapr 集成了 KEDA，这是一个用于 Kubernetes 的事件驱动的自动扩容程序。Dapr 的许多发布/订阅组件与 KEDA 提供的扩容程序无缝集成。这使得我们可以将自动扩容的需求交给底层平台，并专注于业务逻辑。

4. Dapr 提供丰富的可观测性。

事件驱动的应用程序经常被批评没有监控事件。但当有了正确的监控工具，这个问题就可以解决了。

Dapr 提供了丰富的监控追踪工具，以监测架构中的事件。通过 Zipkin 等工具，Dapr 为我们的服务提供分布式跟踪。Dapr 负责自动向 Zipkin 发送跟踪数据，这样我们的服务就不需要手动编写相关的代码了。Dapr 利用 OpenTelemetry 标准来收集跟踪数据，因此我们可以将其替换成任何兼容的跟踪工具。

Dapr 提供符合 OpenTelemetry 的跟踪收集 — 出处

5. Dapr 用 CloudEvents 格式来包装事件

在事件驱动的系统中，事件格式的标准化是至关重要的。这使得异构系统能够以共识的格式来交换事件。

CloudEvents 是一个描述事件的规范。它的目的是简化互操作。随着事件驱动架构的兴起，CloudEvent 的流行也就不足为奇了。

Dapr 使用CloudEvents 1.0 规范作为其消息格式，以实现消息路由，并为每个消息提供额外的信息。任何由应用程序发送至使用Dapr的主题(topic)的消息都会被自动 "包裹 "在云事件中，使用 Content-Type 的 header 值作为数据类型属性。 Dapr 实现了以下 CloudEvent 字段。

id
source
specversion
type
datacontenttype (可选)

如下的例子展示了CloudEvent v1.0 将 XML 内容被序列化为 JSON。

{
"specversion" : "1.0",
"type" : "xml.message",
"source" : "https://example.com/message",
"subject" : "Test XML Message",
"id" : "id-1234-5678-9101",
"time" : "2020-09-23T06:23:21Z",
"datacontenttype" : "text/xml",
"data" : "<note><to>User1</to><from>user2</from><message>hi</message></note>"
}
复制代码

写在结尾，Dapr 在 Github 上已经收获了超过 10k 的 star 。作为一个非侵入的运行环境，Dapr 结合了 Serverless 和 Server Mesh 的部分概念，并且有着相当优秀的移植性。在学习使用时，你甚至可以使用 windows 并且不安装 docker 等容器运行时。从个人的角度来说，这是相当对开发者相当友好的，这意味着它有着较低的学习成本，当然除了它有一个可能挨骂的爹: 巨硬。

那么看完本文之后，你是怎么看待这项技术呢？

为什么应该使用Dapr来构建事件驱动的微服务？