作者 | 敖小剑
起源 | 阿里巴巴云原生公众号

Dapr 是 2019 年 10 月微软开源的可移植、事件驱动分布式运行时，它使开发人员可能轻松地构建运行在云平台和边缘的弹性而微服务化的无状态和有状态的应用程序，从而升高基于微服务架构构建古代云原生利用的准入门槛。

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

拉到文末能够理解 Dapr 入门教程体验形式

为什么阿里会抉择 Dapr？

在阿里巴巴，Java 应用十分宽泛，不仅仅业务利用大量应用 Java，大量中间件和根底能力的服务器端也是应用 Java 开发。在过来十几年间，咱们围绕 Java 建设了十分齐备的生态体系，经验过各种残酷的考验。

而随着业务状态的日渐丰盛，多语言 的需要在一直的减少，如 nodejs / golang / c / c++ / rust 等。特地是在微服务风行之后，依据理论状况而抉择应用不同的编程语言开发微服务成为趋势。但效仿 Java，为每一种编程语言都打造一套性能齐备的生态体系在老本上是不事实的。因而，须要一个老本可控的计划来解决多语言问题，让微服务开发能真正的实现“语言自在”。

随着云的采纳，业务利用的状态也开始朝云原生方向倒退，越来越多的业务利用（尤其是前台业务）开始拥抱 FaaS 和 Serverless  作为利用托管和资源调度的解决方案。而在 FaaS 和 Serverless 场景下，须要更轻量化的解决方案以满足疾速启动和伸缩的需要 —— 传统类库模式下因为须要集成大量的 SDK，业务利用变得十分的臃肿。而在 Function 状态下更加的不协调，以 nodejs 为例：几百行的 nodejs Function 代码仍然须要依赖多达几十兆的 node module。同时 FaaS 和 Serverless 也对多语言的反对提供了更高的要求。因而，在 FaaS 和 Serverless 这种新型状态下有必要提供有别于传统类库形式的、更轻量化的、反对多语言的解决方案。

显然，Servicemesh 提倡的 Sidecar 模式是解决上述问题的绝佳计划。在过来几年间，随着 Servicemesh 的倒退和采纳，Sidecar 模式曾经失去充沛验证：Sidecar 模式十分合乎云原生的理念，特地是在多语言反对和利用轻量化方面具备人造劣势。

咱们十分认可 Bilgin Ibryam 在 ”Multi-Runtime Microservices Architecture” 一文中提出的 Multiple Runtime / Mecha Runtime 的理念，尤其是他对分布式应用需要的剖析，很合乎咱们的理论状况：

而 Dapr 是第一个实际 Multiple Runtime 理念的开源我的项目，咱们从这个我的项目公布开始就亲密关注它，因为 Dapr 能够很好的解决咱们面临的问题：Sidecar 模式人造提供了对多语言的反对，各种客户端 SDK 被 Dapr Runtime 代替之后利用也得以轻量化。

此外，从长期策略的角度思考，咱们在 2020 年提出了 ” 三位一体 ” 的理念，行将“自研技术”、“开源我的项目”、“商业产品”造成对立的技术体系，最大化技术的价值。而以后的理论状况是三者有齐全不同的产品和技术计划，导致当咱们须要将某个产品在阿里外部、私有云、客户公有云等不同的平台上进行迁徙时，或者是跨多个平台部署时，就会遇到十分大的挑战。Dapr 面向能力编程的理念，强调可移植性和可扩展性的规范 API，平台中立、无供应商锁定的设计，深深的吸引了咱们。

“在阿里云，咱们置信 Dapr 将引领微服务的倒退。通过采纳 Dapr，咱们的客户当初能够以更快的速度来构建可移植和强壮的分布式系统。”

—— 阿里云资深技术专家 李响

在 2020 年年中，咱们开始基于 Dapr 我的项目进行了外部小规模的试点，在理论的落地过程中摸索和验证 Dapr 的理念。咱们也积极参与到 Dapr 开源我的项目的建设中，提交了大量的改良倡议和代码。

上面咱们将以 Dapr 在阿里的理论落地场景来具体阐明 Dapr 是如何帮忙咱们解决上述问题的。

Dapr 在阿里的实际

1. 详情

目前 Dapr 在阿里巴巴外部还处于试验阶段。

咱们的首要工作是为外部的中间件开发 Dapr 组件，使业务应用程序能够与这些中间件和实现它们的 Java 语言 / Java Client SDK 解耦。而后通过小规模的业务利用落地，在各种场景下的对 Dapr 进行验证，在验证实现之后打算持续部署较大规模的业务利用。

截止到 2021 年 3 月，Dapr 在阿里外部落地的场景次要集中在 2 个方面：多语言反对和云间迁徙。

2. 多语言反对

1）Faas / Serverless 场景

背景：在阿里的电商零碎中，存在大量流动和导购需要。

这些需要的特点是 ” 短平快 ”：须要疾速开发、疾速迭代、生命周期绝对比拟短。因而这类需要非常适合通过采纳 FaaS 的形式来落地。

Faas 对多语言反对有强烈的诉求，必定不会局限于 Java。而阿里外部大部分利用都是 Java 体系，对多语言的反对比拟弱，尤其是新兴语言（如 Dart）或者小众语言（如 Rust）。

而从需要上说，采纳 FaaS 的利用也同样须要和外部运行的服务以及各种中间件 / 基础设施进行通信，因而 FaaS 平台迫切的须要解决多语言反对问题。

通过 Dapr，咱们很好的解决了 FaaS 的多语言问题，从而使得客户通过 FaaS 实现了开发效率的大幅晋升。

2）多语言利用的接入

背景：阿里收买有大量的公司。

这些收买的公司有大量的利用，而这些利用中很多不是 Java 体系，在接入阿里的技术体系时，对多语言反对有明确的需要。

另外，因为业务翻新的须要，有些利用对 nodejs 和 golang 有强烈诉求，还有一些利用则须要应用到 Dart 和 C++。

但目前这些语言的生态系统并没有像 Java 那么欠缺，尤其局部中间件和基础设施曾经倒退的十分成熟，进入保护状态，不太可能在当初从新开发所有语言的客户端：老本上代价很高，工夫上也来不及。

通过 Dapr，咱们能够为这些利用提供多语言解决方案。

3）简单的 Java 遗留零碎

背景：基于 Java ClassLoader 机制而设计的简单零碎。

为了解决类抵触问题，断绝不同的业务模块，阿里针对  Java 零碎设计了基于 ClassLoader 机制的简单零碎，这些零碎的设计往往非常复杂，利用也十分臃肿。

此外，局部业务团队为了能和现有的中间件进行互通，自行保护了一套多语言的中间件 SDK，而这些 SDK 原本应该由中间件团队保护并放弃同步更新。这也带来了稳定性方面的隐患和危险。

咱们冀望将这些遗留的零碎迁徙到 Dapr 中，对立实现中间件 SDK 的保护和更新。比拟非凡的是这里存在一个需要：最好能让业务开发团队尽量不做代码层面的调整，以缩小迁徙时对业务利用的冲击。

所以针对 Java 遗留零碎，在迁往 Dapr 时，咱们额定设计了一个 Java 适配层：将原来的 Java 调用适配到 Dapr 的客户端 API 上。

以上三种多语言的落地实际场景，如下图所示：

3. 云间迁徙

背景：业务利用对外输入时有跨平台需要。

阿里的局部业务，如钉钉文档，本来是提供给阿里外部和内部用户间接应用的，此时钉钉文档只须要部署在阿里外部的业务集群里，间接拜访阿里外部的生态体系。

然而随着 SaaS 业务的倒退，以及局部信息安全敏感的用户对于数据安全的强烈诉求，须要将钉钉文档部署到用户 VPC 下或者私有云下。

为此，咱们须要将钉钉文档的零碎从阿里外部迁徙到私有云上进行部署，而钉钉文档应用的底层技术须要从阿里外部的技术体系迁徙到应用开源技术或阿里云的商业化产品上。

借助 Dapr 的规范 API 和可扩大的组建模型，咱们采取的策略是让用户不须要批改任何代码，间接通过 Dapr Runtime 屏蔽底层应用的中间件：部署在不同平台时，通过激活 Dapr 中的不同的 Component 来提供统一的能力。

以音讯通信威力，当利用须要拜访音讯零碎时：

• 在阿里外部：通过 Rocketmq.yaml 激活 Rocketmq 组件。
• 在私有云上：通过 Kafka.yaml 激活 kafka 组件。

通过 Dapr 的可移植性，下层的钉钉文档利用当初能够和底层的基础设施（如音讯零碎）解耦，从而实现在不同的云平台之间平滑迁徙：

最终帮忙咱们的业务团队实现了他们的 业务指标：使 Dingtalk 在任何中央部署成为可能。

阿里的 Dapr 将来布局

将来咱们将持续通过利用试点的形式对 Dapr 进行验证，包含：

• 实用场景
• 性能
• 稳定性
• 可移植性

同时咱们将持续开发 Dapr 的组件，以集成更多的中间件和基础设施，包含外部产品和阿里云上反对的商业产品。其中对阿里云商业产品的集成代码，咱们将在验证通过之后奉献给 Dapr 我的项目，从而为 Dapr 提供阿里云反对。这些我的项目预计将包含：

• Apache Dubbo 的 RPC 反对
• Apache RocketMQ 的消息传递反对
• Nacos 的动静配置反对
• 阿里云 RDS 的 MySQL 反对
• 阿里云缓存服务的 Redis 反对

作为 Multiple Runtime 架构的先驱者和 Dapr 我的项目的晚期采纳者，咱们将持续和 Dapr 社区单干，在落地的过程中致力欠缺 Dapr 的性能、性能、稳定性等要害指标，和社区一起联手打造云原生时代的DistributedAPplicationRuntime！