引言
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,event-driven runtime that makes it easy for any de