简介： 尽管 Dapr 在国外有很高的关注度，但在国内知名度非常低，而且现有的大量 Dapr 材料也偏新闻资讯和简略介绍，不足对 Dapr 的深度解读。在 Dapr v1.0 公布之际，我心愿能够通过这篇文章帮忙大家对 Dapr 造成一个精确的认知：把握 Dapr 我的项目的倒退脉络，理解其外围价值和愿景，领悟 Dapr 我的项目背地的“道之所在”—— 云原生。

作者 | 敖小剑 阿里云高级技术专家、Dapr Maintainer

Dapr 是 2019 年 10 月微软开源的分布式运行时，在往年 2 月份刚刚公布了 v1.0 正式版本。尽管推出至今不过一年半工夫，但 Dapr 发展势头非常迅猛，目前曾经在 GitHub 上播种了 1.2w 星。阿里是 Dapr 开源我的项目的深度参与者和晚期采纳者，率先进行了生产落地，团体外部有十几个利用在应用 Dapr；目前已有 2 位 Dapr 成员，是 Dapr 我的项目中除微软之外代码奉献最多的公司。

尽管 Dapr 在国外有很高的关注度，但在国内知名度非常低，而且现有的大量 Dapr 材料也偏新闻资讯和简略介绍，不足对 Dapr 的深度解读。在 Dapr v1.0 公布之际，我心愿能够通过这篇文章帮忙大家对 Dapr 造成一个精确的认知：把握 Dapr 我的项目的倒退脉络，理解其外围价值和愿景，领悟 Dapr 我的项目背地的“道之所在”—— 云原生。

回顾：Service Mesh 原理和方向

1. Service Mesh 的定义

首先，让咱们先疾速回顾一下“Service Mesh”的定义，这是 Dapr 故事的开始。

以下内容摘录自我在 2017 年 10 月 QCon 上海做的演讲 “Service Mesh：下一代微服务 ”：

Service Mesh 是一个基础设施层，用于解决服务间通信。古代云原生利用有着简单的服务拓扑，服务网格负责在这些拓扑中实现申请的牢靠传递。
在实践中，服务网格通常实现为一组轻量级网络代理，它们与应用程序部署在一起，而对应用程序通明。

在 Service Mesh 的定义中，简短地形容了 Service Mesh 的要害特色：

• 定位基础设施层；
• 性能是服务间通信；
• 采纳 Sidecar 部署；
• 特别强调无侵入、对利用通明。

相熟 Service Mesh 的同学，想必对上面这张图片不会生疏：

1. Sidecar 模式

和传统 RPC 框架相比，Service Mesh 的翻新之处在于引入了 Sidecar 模式：

引入 Sidecar 之后，服务间通信由 Sidecar 接管，而 Sidecar 由管制立体对立管制，从而实现了服务间通信能力的下沉，使得利用得以大幅简化。

咱们再来疾速回顾一下 Service Mesh 的基本思路：

• 引入 Sidecar 之前：业务逻辑和非业务逻辑混合在一个过程内，利用既有业务逻辑，也有各种非业务的性能（体现为各种客户端 SDK）。
• 引入 Sidecar 之后：客户端 SDK 的性能剥离，业务过程专一于业务逻辑，而 SDK 中的大部分性能被拆解为独立过程，以 Sidecar 的模式运行。

通过引入 Sidecar 模式，Service Mesh 胜利实现了 关注点拆散 和 独立保护 两大指标。

1. Service Mesh 的发展趋势

以 Istio 我的项目为例，我总结了最近一两年来 Service Mesh 的发展趋势（留神这些内容不是本文的重点，请疾速浏览，简略理解即可）：

1）协定反对

Istio 中通信协定的反对次要在 HTTP 和 gRPC，各家厂商在提供更多协定反对，包含 Dubbo、Thrift、Redis。也有一些社区力量在做补充，如赵化冰同学的 Aeraki 我的项目。

2）虚拟机反对

虚拟机的反对最近成为 Istio 的重要关注点：

• Istio 0.2：Mesh Expansion
• Istio 1.1：ServiceEntry
• Istio 1.6：WorkloadEntry
• Istio 1.8：WorkloadGroup 和智能 DNS 代理
• Istio 1.9：虚拟机集成

3）易用性

• Istio 1.5：管制立体单体化，合并多个组件为 istiod（这是 Istio 开源以来最大的一次架构调整之一）。
• Istio 1.7：主推 Operator 装置形式，加强 istioctl 工具，反对在 Sidecar 启动之后再启动利用容器。
• Istio 1.8：改善降级和装置, 引入 istioctl bug-report

4）可观测性

Istio 1.8：正式移除 Mixer，在 Envoy 基于 wasm 从新实现 Mixer 性能（Istio 最大的架构调整之一）Istio 1.9：近程获取和加载 wasm 模块。

5）内部集成

和非 service mesh 体系的互相拜访，实现利用在两个体系之间的平滑迁徙。

• Istio 曾打算通过 MCP 协定提供对立的解决方案。
• Istio 1.7：MCP 协定被废除，改为 mcp over xds。
• Istio 1.9：Kubernetes Service API 反对 (alpha)，对外裸露服务。

从下面列出的内容，能够看到 Istio 在最近一两年间还是在十分致力地欠缺本身，尽管过程有些波折和往返（比方顽固不化的保持 Mixer 到最初服从全社区的召唤彻底废除了 Mixer，开始反对虚拟机起初实质性放弃再到最近从新器重，引入 Galley 再废除 Galley，引入 MCP 再变相放弃 MCP），但整体上说 Istio 还是在朝 Product Ready 的大方向在致力。

备注：当然，社区对 Istio 的演进速度以及 Product Ready 的理论状态还是很不称心的，以至于呈现了这个梗：Make Istio Product Ready (Again, and Again…)。

1. Service Mesh 回顾总结

咱们后面疾速回顾了 Service Mesh 的定义、Sidecar 模式的原理，以及粗略列举了一下最近一两年间 Service Mesh 的发展趋势，次要是为了告知大家这样一个信息：

尽管 Service Mesh 蓬勃发展，但外围元素始终未变。

从 2016 年 Linkerd 的 CEO William Morgon 给出 Service Mesh 的定义，到 2021 年 Istio 都公布到了 1.9 版本，整整六年期间，Service Mesh 有了很多的变动，但以下三个外围元素始终未变：

• 定位：Service Mesh 的定位始终是提供 服务间通信 的基础设施层，范畴包含 HTTP 和 RPC——反对 HTTP1.1/REST，反对 HTTP2/gRPC，反对 TCP 协定。也有一些小的尝试如对 Redis、Kafka 的反对。
• 部署：Service Mesh 反对 Kubernetes 和虚拟机，但都是采纳 Sidecar 模式部署，没有采纳其余形式如 Node 部署、中心化部署。
• 原理：Service Mesh 的工作原理是 原协定转发，原则上不扭转协定内容（通常只是 header 有些小改变）。为了达到零侵入的指标，还引入了 iptables 等流量劫持技术。

演进：云原生分布式应用运行时

在疾速实现 Service Mesh 的回顾之后，咱们开始本文第二局部的内容：当 Sidecar 模式进一步推广，上述三个外围元素发生变化时，Sidecar 模式将会如何演进？

1. 实际：更多 Mesh 状态

我之前在蚂蚁金服的中间件团队做 Service Mesh 相干的内容，可能很多敌人是从那个时候开始意识我。过后蚂蚁不仅仅做了 Service Mesh，还将 Service Mesh 的 Sidecar 模式推广到其余的中间件畛域，陆陆续续摸索了更多的 mesh 状态：

这个图片摘录自我在 2019 年 10 月的上海 QCon 上做的主题演讲 “ 诗和远方：蚂蚁金服 Service Mesh 深度实际 ”，过后咱们分享了包含音讯 Mesh、数据库 Mesh 等在内的多种 mesh 状态。

1. 实践升华：Multi-Runtime 理念的提出

最近有越来越多的我的项目开始引入 Sidecar 模式，Sidecar 模式也逐步被大家认可和承受。就在 2020 年，Bilgin Ibryam 提出了 Multi-Runtime 的理念，对基于 Sidecar 模式的各种产品状态进行了实际总结和实践升华。

首先咱们介绍一下 Bilgin Ibryam 同学，他是《Kubernetes Patterns》一书的作者，Apache Camel 我的项目的 committer，目前工作于 Red Hat。

2020 年初，Bilgin Ibryam 发表文章 “Multi-Runtime Microservices Architecture”，正式提出了多运行时微服务架构（别名 Mecha/ 机甲，十分帅气的名字）。在这篇文章中，Bilgin Ibryam 首先总结了分布式应用存在的四大类需要，作为 Multi-Runtime 的实践出发点：

这四大类需要中，生命周期治理类的需要次要是通过 PaaS 平台如 kubernetes 来满足，而 Service Mesh 提供的次要是网络中的点对点通信，对于其余通信模式典型如 pub-sub 的音讯通信模式并没有笼罩到，此外状态类和绑定类的需要大多都和 Service Mesh 关系不大。

Multi-Runtime 的实践推导大体是这样的——基于上述四大类需要，如果效仿 Service Mesh，从传统中间件模式开始，那么大体会有上面两个步骤：

• 步骤一：将利用须要的分布式能力外移到各种 runtime，此时会呈现数量泛滥的各种 Sidecar 或者 proxy，如下面中列出来的 Istio、Knative、Cloudstate、Camel、Dapr 等。
• 步骤二：这些 runtime 会逐步整合，只保留大量甚至只有一两个 runtime。这种提供多种分布式能力的 runtime 也被称为 Mecha。

步骤二实现后，每个微服务就会由至多一个 Mecha Runtime 和利用 Runtime 独特组成，也就是每个微服务都会有多个（至多两个）runtime，这也就是 Multi-Runtime / Mecha 名字的由来。

1. Multi-Runtime 和云原生分布式应用

将 Multi-Runtime / Mecha 的理念引入到云原生分布式应用的形式：

• 能力：Mecha 是通用的，高度可配置的，可重用的组件，提供分布式原语作为现成的能力。
• 部署：Mecha 能够与单个 Micrologic 组件一起部署（Sidecar 模式），也能够部署为多个共享（如 Node 模式）。
• 协定：Mecha 不对 Micrologic 运行时做任何假如。它与应用凋谢协定和格局（如 HTTP/gRPC，JSON，Protobuf，CloudEvents）的多语言微服务甚至单体一起应用。
• 配置：Mecha 以简略的文本格式（例如 YAML，JSON）申明式地配置，批示要启用的性能以及如何将其绑定到 Micrologic 端点。
• 整合：与其依附多个代理来实现不同的目标（例如网络代理，缓存代理，绑定代理），不如应用一个 Mecha 提供所有这些能力。

1. Multi-Runtime 的特点和差别

尽管同为 Sidecar 模式，然而和 Service Mesh 相比，Multi-Runtime 有本身的特点：

• 提供能力的形式和范畴：Multi-Runtime 提供的是分布式能力，体现为利用须要的各种分布式原语，并不局限于单纯的服务间点对点通信的网络代理.
• Runtime 部署的形式：Multi-Runtime 的部署模型，不局限于 Sidecar 模式，Node 模式在某些场景下（如 Edge/IoT，Serverless FaaS）可能会是更好的抉择。
• 和 App 的交互方式：Multi-Runtime 和利用之间的交互是凋谢而有 API 规范的，Runtime 和 Micrologic 之间的“协定”体现在 API 上，而不是原生的 TCP 通信协定。另外 Multi-Runtime 不要求无侵入，还会提供各种语言的 SDK 以简化开发。

Multi-Runtime 和 Service Mesh 的差别总结如下图所示：

1. Multi-Runtime 的实质

至此我介绍了 Multi-Runtime 架构的由来，置信读者对 Multi-Runtime 的特点以及和 Service Mesh 的差别曾经有所理解。为了加深大家的了解，我来进一步分享一下我集体对 Multi-Runtime 的感悟：

Multi-Runtime 的实质是面向云原生利用的分布式能力形象层。

何为“分布式能力形象层”?

如上图所示，左侧是分布式应用存在的四大类需要：生命周期、网络、状态、绑定。从需要上说 Multi-Runtime 要为分布式应用提供这四大类需要下所列出的各种具体的分布式能力。以 Sidecar 模式为利用提供这些能力容易了解，但关键在于 Multi-Runtime 提供这些能力的形式。和 Service Mesh 采纳原协定转发不同，Multi-Runtime 的形式是：

• 将能力形象为 API：很多分布式能力没有相似 HTTP 这种业界通用的协定，因而 Multi-Runtime 的实现形式是将这些能力形象为和通信协定无关的 API，只用于形容利用对分布式能力的需要和用意，尽量避免和某个实现绑定。
• 为每种能力提供多种实现：Multi-Runtime 中的能力个别都提供有多种实现，包含开源产品和私有云商业产品。
• 开发时：这里咱们引入一个“面对能力编程”的概念，相似于编程语言中的“不要面对实现编程，要面向接口编程”。Multi-Runtime 中提倡面向“能力（Capability）”编程，即利用开发者面向的应该是曾经形象好的分布式能力原语，而不是底层提供这些能力的具体实现。
• 运行时：通过配置在运行时抉择具体实现，不影响形象层 API 的定义，也不影响遵循“面对能力编程”准则而开发实现的利用。

备注：分布式能力的通用规范 API，将会是 Multi-Runtime 成败的要害，Dapr 的 API 在设计和实际中也遇到很大的挑战。对于这个话题，我稍后将独自写文章来论述和剖析。

介绍：分布式应用运行时 Dapr

在疾速回顾 Service Mesh 和具体介绍 multi-runtime 架构之后，咱们曾经为理解 Dapr 奠定了良好的根底。当初终于能够开始本文的正式聂荣，让咱们一起来理解 Dapr 我的项目。

1. 什么是 Dapr？

Dapr 是一个开源我的项目，由微软发动，上面是来自 Dapr 官方网站的权威介绍：

Dapr is a portable, event-> driven runtime that makes it easy for any developer to build resilient, stateless and stateful applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks. Dapr 是一个可移植的、事件驱动的运行时，它使任何开发者都能轻松地构建运行在云和边缘的弹性、无状态和有状态的应用程序，并拥抱语言和开发者框架的多样性。

参考并对照 Service Mesh 的定义，咱们对上述 Dapr 定义的剖析如下：

• 定位：Dapr 将本身定义为运行时（runtime），而不是 Service Mesh 中的 proxy。
• 性能：Dapr 为利用提供各种分布式能力，以简化利用的开发。下面定义中提及的关键点有弹性、反对有状态和无状态、事件驱动。
• 多语言：对多语言的反对是 Sidecar 模型的人造劣势，Dapr 也不例外，思考到 Dapr 为利用提交的分布式能力的数量，这可能比 Service Mesh 只提供服务间通信能力对利用的价值更高。而且因为 Dapr 语言 SDK 的存在，Dapr 能够十分不便的和各编程语言的支流开发框架集成，如 Java 下和 Spring 框架集成。
• 可移植性：Dapr 实用的场景包含各种云（私有云，公有云，混合云）和边缘网络，Multi-Runtime 架构的几个要害个性如 ” 面向能力编程 ”、规范 API、可运行时配置实现等为 Dapr 带来了绝佳的跨云跨平台的可移植性。

咱们将在前面的介绍中具体开展 Dapr 的这些个性。在开始之前，这里有一个小小的花絮——“Dapr”我的项目名字的由来：

1. Dapr Sidecar 的性能和架构

和 Service Mesh 相似，Dapr 同样基于 Sidecar 模式，但提供的性能和应用场景要比 Service Mesh 的简单多，如下图所示：

Dapr 的 Sidecar，除了能够和 Service Mesh 一样反对服务间通信（目前反对 HTTP1.1/REST 协定和 gRPC 协定外，还能够反对到更多的性能，如 state（状态治理）、pub-sub（音讯通信），resource binding（资源绑定，包含输出和输入）。

每个性能都有多种实现，在上图中我简略摘录了这几个能力的常见实现，能够看到实现中既有开源产品，也有私有云的商业产品。留神这只是目前 Dapr 实现中的一小部分，目前各种实现（在 Dapr 中被称为组件，咱们上面会介绍）曾经有超过 70 个，而且还在一直的减少中。

在 Dapr 的架构中，有三个次要组成部分：API、Building Blocks 和 Components，如下图所示：

• Dapr API：Dapr 提供两种 API，HTTP1.1/REST 和 HTTP2/gRPC，两者在性能上是对等的。
• Dapr Building Blocks：翻译为构建块，这是 Dapr 对外提供能力的根本单元，每个构建块对外提供一种分布式能力。
• Dapr components：组件层，这是 Dapr 的能力实现层，每个组件都会实现特定构建块的能力。

为了帮忙大家了解 Dapr 的架构，咱们回顾一下后面重点论述的 Multi-Runtime 的实质：

Multi-Runtime 的实质是面向云原生利用的分布式能力形象层。

联合 Multi-Runtime 理念，咱们再来了解 Dapr Runtime 的架构：

• Dapr Building Blocks 提供“能力”。
• Dapr API 提供对分布式能力的“形象”，对外裸露 Building Block 的能力。
• Dapr Components 是 Building Block 能力的具体“实现”。

1. Dapr 的愿景和现有能力

下图来自 Dapr 官网，比较完善地概括了 Dapr 的能力和档次架构：

• 居中蓝色的是 Dapr Runtime：这里列出了 Dapr 目前曾经提供的构建块。
• Dapr Runtime 对外通过近程调用提供能力，目前有 HTTP API 和 gRPC API。
• 因为 Sidecar 模式的人造劣势，Dapr 反对各种编程语言，而且 Dapr 官网为支流语言（典型如 Java、golang、c++、nodejs、.net、python）提供了 SDK。这些 SDK 封装了通过 HTTP API 或者 gRPC API 和 Dapr Runtime 进行交互的能力。
• 最下方是能够反对 Dapr 的云平台或者边缘网络，因为每个能力都能够由不同的组件来实现，因而实践上只有 Dapr 的反对做的足够欠缺，就能够实现在任何平台上，总是能找到基于开源产品或者基于云厂商商业化产品的可用组件。

联合以上几点，Dapr 提出了这样一个愿景：

Any language, any framework, anywhere

即：能够应用任意编程语言开发，能够和任意框架集成，能够部署在任意平台。下图是 Dapr 目前已有的构建块和他们提供的能力的简略形容：

1. Dapr 的管制立体

和 Service Mesh 的架构相似，Dapr 也有管制立体的概念：

Dapr 的管制立体组件有：

• Dapr Actor Placement
• Dapr Sidecar Injector
• Dapr Sentry
• Dapr Operator

比拟有意思的是：Istio 为了简化运维，曾经将微服务架构的管制立体进行了合并，管制立体回归到传统的单体模式。而 Dapr 的管制立体目前还是微服务架构，不晓得将来会不会效仿 Istio。

备注：出于管制篇幅的思考，本文不对 Dapr 的构建块和管制立体进行具体开展，稍后预计会另有独自文章做具体介绍，对 Dapr 有趣味的同学能够关注。

1. Dapr 的倒退历程和阿里巴巴的参加

Dapr 是一个十分新的开源我的项目，倒退至今也才大概一年半的工夫，不过社区关注度还不错（次要是国外），在 GitHub 上目前有靠近 12000 颗星（类比：Envoy 16000，Istio 26000，Linkerd 7000）。Dapr 我的项目的次要里程碑是：

• 2019 年 10 月：微软在 GitHub 上开源了 Dapr，公布 0.1.0 版本。
• 2021 年 2 月：Dapr v1.0 版本公布。

阿里巴巴深度参加 Dapr 我的项目，不仅仅以终端用户的身份成为 Dapr 的早起采纳者，也通过全面参加 Dapr 的开源开发和代码奉献成为目前 Dapr 我的项目中的次要奉献公司之一，仅次于微软：

• 2020 年中：阿里巴巴开始参加 Dapr 我的项目，在外部试用性能并进行代码开发。
• 2020 年底：阿里巴巴外部小规模试点 Dapr，目前曾经十几个利用在应用 Dapr。

备注：对于 Dapr 在阿里巴巴的实际，请参阅咱们刚刚发表在 Dapr 官网博客上的文章 “How Alibaba is using Dapr”。

目前咱们曾经有两位 Dapr Committer 和一位 Dapr Maintainer，在 2021 年预计咱们会在 Dapr 我的项目上有更多的投入，包含更多的开源代码奉献和落地实际，事必躬亲的推动 Dapr 我的项目的倒退。欢送更多的国内贡献者和国内公司一起退出到 Dapr 社区。

1. Dapr 疾速体验

在 Dapr 的官网文档中提供了 Dapr 装置和 quickstudy 的内容，能够帮忙大家疾速的装置和体验 Dapr 的能力和应用形式。

为了更加快捷和不便的体验 Dapr，咱们通过 阿里云知口头手实验室 提供了一个超级简略的 Dapr 入门教程，只有大概十分钟就能够疾速体验 Dapr 的开发、部署过程：_https://start.aliyun.com/course?id=gImrX5Aj_。

有趣味的同学能够理论体验一下。

瞻望：利用和中间件的将来状态

在本文的最初局部，咱们瞻望一下利用和两头的将来状态。

1. 云原生的时代背景

首先要申明的是，咱们论述的所有这些内容，都是基于一个大的前提：云原生。

上面这张图片，摘录自我在 2019 年 10 月 QCon 大会上的演讲 “ 诗和远方：蚂蚁金服 Service Mesh 深度实际 ” :

过后（2019 年）咱们刚实现了 Kubernetes 和 Service Mesh 的摸索和大规模落地，并开始 Serverless 的新摸索，我在文中做了一个云原生落地总结和是否驳回 Service Mesh 的倡议，大体能够概括为（间接征引原文）：

• 有一点咱们是十分明确的：Mesh 化是云原生落地的关键步骤。
• 如果云原生是你的诗和远方，那么 Service Mesh 就是必由之路。
• Kubernetes / Service Mesh / Serverless 是当下云原生落地实际的三驾马车，相辅相成，井水不犯河水。

两年之后的明天，回顾过后对云原生倒退策略大方向的判断，感触良多。下面这张图片我稍加调整，减少了 Multi-Runtime/ 容器 / 多云 / 混合云的内容，批改如下图：

和 2019 年相比，云原生的理念失去了更宽泛的认可和驳回：多云、混合云成为将来云平台的支流方向；Service Mesh 有了更多的落地实际，有更多的公司应用 Service Mesh；Serverless 同样在过来两年间疾速倒退。

云原生的历史大潮还在进行中，而在云原生背景下，利用和中间件将何去何从？

1. 利用的冀望就是中间件的方向

让咱们畅想云原生背景下处于最现实状态的业务利用，就当是个甘甜的梦吧：

• 利用能够应用任意青睐而适宜的语言编写，能够疾速开发和疾速迭代。
• 利用须要的能力都能够通过规范的 API 提供，无需关怀底层具体实现。
• 利用能够部署到任意的云端，不论是私有云、公有云还是混合云，没有平台和厂商限度，无需代码革新。
• 利用能够依据流量弹性伸缩，顶住波峰的压力，也能在闲暇时开释资源。
• ……

我集体的对云原生利用将来状态的认识是：Serverless 会是云上利用的现实状态和支流倒退方向；而多语言反对、跨云的可移植性和利用轻量化将会是云原生利用的三个外围诉求。

利用对云原生的冀望，就是中间件后退的方向！

过来几年间，中间件在云原生的美妙指标推动下摸索着后退，将来几年也必将还是如此。Service Mesh 摸索了 Sidecar 模式，Dapr 将 Sidecar 模式推广到更大的畛域：

• 欠缺的多语言反对和利用轻量化的需要推动中间件将更多的能力从利用中分离出来。
• Sidecar 模式会推广到更大的畛域，越来越多的中间件产品会 开始 Mesh 化，整合到 Runtime。
• 对厂商锁定的人造讨厌和躲避，会加剧对可移植性的谋求，从而进一步促使为下沉到 Runtime 的中分布式能力提供规范而业界通用的 API。
• API 的标准化和社区认可，将成为 Runtime 遍及的最大挑战，但同时也将推动各种中间件产品改良本身实现，实现中间件产品和社区规范 API 之间的磨合与欠缺。

在云原生需要推动下，多语言反对、跨云的可移植性和利用轻量化，预计将成为将来几年间中间件产品的突破点和重点倒退方向，如下图所示：

在目前的云原生畛域，Dapr 我的项目是一个十分引人注目的新生力量。Dapr 是探路者，开启 Multi-Runtime 理念的全新摸索，而这必然是一个艰巨的过程。十分期待有更多的集体和公司，和咱们一起退出 Dapr 社区，一起摸索，独特成长！

备注：对于 Dapr API 标准化的话题，以及 Dapr 在定义 API 和实现 API 遇到的挑战，在现场曾有一段热烈的探讨，我将稍后整顿出独自的文章，联合 state API 的深度实际和新的 configuration API 的设计过程，深刻开展，敬请关注。

序幕

在这篇文章的最初，让咱们用这么一段话来总结全文：

Dapr 在 Service Mesh 的根底上进一步扩大 Sidecar 模式的应用场景，一方面提供人造的多语言解决方案，满足云原生下利用对分布式能力的需要，帮忙利用轻量化和 Serverless 化，另一方面提供面向利用的分布式能力形象层和规范 API，为多云、混合云部署提供绝佳的可移植性，防止厂商锁定。

Dapr 将引领云原生时代利用和中间件的将来。

附录：参考资料

本文相干的参考资料如下：

• Dapr 官网 和 Dapr 官网文档：局部 Dapr 介绍内容和图片摘录自 dapr 官方网站。
• Multi-Runtime Microservices Architecture: multi-runtime 介绍的内容和图片局部征引自 Bilgin Ibryam 的这篇文章

作者简介

敖小剑，资深码农，微服务专家，Service Mesh 布道师，Dapr maintainer。专一于基础架构，Cloud Native 拥护者，麻利实践者，坚守开发一线打磨匠艺的架构师。目前就任阿里云，在云原生利用平台负责 Dapr 开发。

原文链接
本文为阿里云原创内容，未经容许不得转载。