Dapr | 云原生的抽象与实现

引言

Dapr 是微软主导的云原生开源项目，2019年10月首次发布，到今年2月正式发布 V1.0 版本。在不到一年半的时间内，github star 数达到了 1.2 万，超过同期的 kubernetes、istio、knative 等，发展势头迅猛，业界关注度非常高。

Dapr 这个词是是 「Distributed Application runtime」的首字母缩写，非常精炼的解释了 dapr 是什么：dapr 是一个为应用提供分布式能力的运行时。

什么是 Runtime

Runtime 是一个抽象的概念，字面意思是程序运行的时候。一般是指用来支持程序运行的实现。描述的是程序正常执行需要的支持：库、命令和环境等。

常见的 runtime 为程序提供的支持：

• 语言 runtime（C/Goang…）：操作系统交互，垃圾回收，并发控制等
• Java runtime: 虚拟机
• 容器运行时：namespace，cgroup 等

容器运行时，就是容器运行起来需要的一系列程序和环境。比如如何使用 namespace 实现资源隔离，如何使用 cgroup 实现资源限制，这些都是容器运行时需要提供的实现。

特征：

• runtime 是在程序之外，不由程序编写者提供
• runtime 的生命周期通常和程序生命周期关联

我们写 java 程序的不需要写 java 虚拟机；构建一个容器，通常不需要去写 runc 的代码。

什么是 Distributed Application Runtime

Dapr 所提供的「分布式应用运行时」，是应用程序运行所需分布式能力的实现，这些能力涵盖服务通信、数据持久化、外部 binding，pub-sub 等等。比如服务调用需要有容错重试机制，比如一个数据持久化操作希望使用乐观锁，比如发布消息是要求有投递保证。

长期以来，这些功能的适配都是集成在业务代码里的。dapr 创新之处是将这些功能，从原来 application runtime 中拆分出来，作为一个独立的 runtime。dapr runtime 也满足上面说到的 runtime 的特征。

了解 service mesh 的同学可能会看出，这和 service mesh 使用的 sidecar 模式很类似，这是一种让系统解耦、让开发人员关注点分离的方式。 但我们也很好奇，dapr 和 service mesh 有什么关联，这些越来越多的 sidecar 模型到底有什么区别？（knative 也用到了 sidecar 模式）。因此，在深入 dapr 之前，我们先了解一个重要的理论背景：Multi runtime。

Multi Runtime

Multi runtime 是由 Red Hat首席架构师 Bilgin Ibryam 提出的，实际上 multi runtime 和 dapr 并没有直接的关系，multi runtime 的提出是在 dapr 开源之后。作者的文章重点对当今分布式应用的需求做了归类，并且分析了当前流行的云原生项目是如何满足这些分布式需求，包括 kubernetes，istio，dapr 等，最后，作者对分布式应用和中间件的未来发展，做了推导和预测，这就是 multi runtime。

分布式应用的需求:

• 生命周期：包括部署，健康检查，水平扩展，配置管理等，目前这些需求的最佳实践，都陆续在 kubernetes 上有了落地。
• 网络：网络方面的需求 是 service Mesh 的主战场，比如 istio 可以满足这里绝大部分需求，除了 pub/sub。
• 状态：包括数据的读写，状态其实是非常难以管理的，涉及幂等，缓存，数据流等等。
• 绑定：主要是指和系统外部资源的交互。

左边的这些需求，在传统软件时代，是耦合在应用代码里的，但现如今，有越来越多的分布式能力从应用中剥离，而剥离的方式也在逐渐变化，从最早期，这些能力从业务代码剥离到依赖库中，然后有一些特性剥离到平台层（kubernetes）。 而如今会有更多的非业务能力，剥离到 sidecar 中。

作者预测：理论上每个微服务可以有多个 runtime: 一个业务运行时，和多个分布式能力运行时，但最理想的情况是，或者最可能出现的情况是：在业务之外的运行时合并为一个，通过高度模块化、标准化和可配置的方式，给业务提供所有分布式能力。

原文：Multi-runtime Microservices Architecture

Dapr

Dapr 是什么

dapr is a portable，eve