为什么 Dapr 如此令人兴奋

如今你构建软件，您可以从数量众多的云服务中进行选择。仅 AWS 就每个月都在不断为其200多项服务添加新服务，而其他云提供商也都在跟上。 如果您的公司想与您的竞争对手竞争，您就需要充分利用这些服务，这些服务在不同的云提供商都有它的特色服务，我们的应用如何做到既是标准化又是可以个性化的，就拿消息队列来说吧，设置和管理您的消息队列并不会为您的产品增加任何价值，在Azure中期望使用Azure ServerBus，在阿里云你期望使用rocketmq，在私有云的k8s集群里你可以自由的选择rabbitmq，nat或者是redis，通过Dapr的components 让你无论是 Pub/Sub还是Binding 模块做到消息队列自由。

如果没有Dapr，你如何处理这个问题呢？通常都是让开发人员在具体的云提供商上平台选择他们想要的，虽然这听起来很有效，但对于几乎所有软件组织来说都是不切实际的，也不可取，因为开发人员会被各种选择所淹没。 应对这一挑战的方法是提供满足您特定需求的这些服务的一个子集，通常这是在平台团队中协作完成的，并在PaaS平台中体现出来。

Thoughtworks 的MartinFlow.Com有篇文章：​​介意平台执行差异​​： 开发人员生产力平台越来越被认为是管理工程团队认知负荷和缩短新功能上市时间的一种方式。然而，为了成功执行平台战略，组织需要培养一些基线能力。平台团队需要将平台视为一个软件产品，需要与用户对话，关注可靠的运营，以及健康的团队环境。Dapr 正是专门为构建平台而构建的，与其他方法相比具有一些优势，下面我认为特别重要的5点：

1、开发者友好的API

​​

首先要正确的是API。 平台构建者需要一种方法来放置护栏并为开发人员提供可以轻松使用的 API， Dapr 基于 Open Application Model (OAM)，最佳实践基于Kubernetes之上，对外提供标准的Http和Grpc 的API，  开发人员创建资源来请求特定服务也就很容易，例如利用Binding 构建块来使用Rabbitmq 消息队列，开发人员将执行简单的 kubectl apply ，然后通过标准的Http和Grpc 的API调用：

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: RabbitBinding
spec:
  type: bindings.rabbitmq
  version: v1
  metadata:
  - name: queueName
    value: queue1
  - name: host
    value: amqp://admin:[email protected]:5672
  - name: durable
    value: true
  - name: deleteWhenUnused
    value: false
  - name: ttlInSeconds
    value: 60
  - name: prefetchCount
    value: 0
  - name: exclusive
    value: false
  - name: maxPriority
    value: 5

对于 Kubernetes 开发人员来说，这很简单。这还有一个额外的好处，即我们可以无缝地融入庞大的 Kubernetes 工具生态系统。 特别是在当前流行的 GitOps ，而且在非 Kubernetes 开发人员也可以使用的。

2、 强大而灵活的组合

Dapr 每个标准的 API 背后的实现可能相当复杂，可能涉及设置正确的云提供商资源，如权限、网络、VPC 和数据库实例等等。 Dapr中的每个构建块都有来自云提供商的托管资源，Dapr 已经包括了AWS、Azure、GCP和阿里云的支持，并且社区正在增加各类组件的支持。

这些微服务基本构建块为开发人员提供跨平台跨语言的API实现。开发者可以专注于她请求的服务的属性，这些组合还可以与遗留或本地服务一起使用，这对于处于某种转型路径上的任何团队都至关重要。

Dapr利用Sidecar的模式，把代码中的一些横切关注点需求（Cross-cutting）分离和抽象出来，从而达到运行环境的独立和对外部依赖（包括服务之间）的独立.

3、强大的编程模型-Actors 和函数

Dapr 包含专门实现 ​​virtual actors 模式​​ 的运行时。 通过 Dapr 的实现，您可以根据 Actors 模型编写 Dapr Actor，而 Dapr 利用底层平台提供的可扩展性和可靠性保证，通过Actors的模式，让微服务可以以单线程的代码实现大规模并行处理。实际上，Actors这部分功能的开发人员就是来自于Service Fabric团队，两者的API也基本保持一致。通过这样的模式，也把Actors这种模式引入到了其他运行平台。

​​

同时，Dapr还可以和微软开源的FaaS开发框架Azure Functions进行集成，Dapr开发团队也基于Azure Logic App的边缘运行时版本为微服务应用提供了Workflows的能力。​​OpenFunction​​ 正是基于 Dapr 提供了一套灵活的 functions framework 机制（其中包含了借鉴 Google functions-framework 处理 HTTP 函数的部分）实现了与各种复杂中间件的对接，并搭载两种运行时——以 Knative serving 为基础的同步函数运行时，和以 KEDA 结合 Dapr 为基础的异步函数运行时 OpenFunctionAsync，以期实现对实际生产中大部分应用场景的覆盖。

4、在在 K8s 的帮助下生产就绪

一个优秀的开发者平台应该被视为一个产品，这包括许多方面，但一个重要的方面是它以高度可用的方式运行。我们有一种架构和运行分布式应用程序的方法哪就是采用 Kubernetes， Dapr的最佳实践是建立在Kubernetes之上，它使用 Kubernetes 控制器和持续协调的概念来运行平台，如果有什么东西坏了（它会），Dapr 将检查并修复状态，也就是你经常听到 Kubernetes 专家说的类似 Operators 和 control plane 的东西。

5、开源和开放治理

选择一个优秀的开发者平台的一个重要特征是开源的，由于开发人员平台将成为您软件交付的重要组成部分，您将希望确保您的投资安全。Dapr 不仅是开源的（当前采用MIT协议，捐献给CNCF之后将会改成Apache 2.0），正在捐献给CNCF，目前正处于尽职调查阶段，它也是公开社区管理的，Dapr于 2020 年 9 月​​首次转变为开放治理模式​​​，2021年9月成立了STC（ Dapr 指导和技术委员会），专注于与更广泛的 Dapr 社区合作，制定指导和技术委员会的章程、职责和愿景，并与成员一起引导以确保供应商中立。具体参见 ​​https://blog.dapr.io/posts/2021/09/20/announcing-daprs-steering-and-technical-committee/​​

​​