死生之地不可不察：论 API 标准化对 Dapr 的重要性

最新推荐文章于 2024-06-17 14:37:56 发布

人工智

最新推荐文章于 2024-06-17 14:37:56 发布

阅读量264

点赞数

分类专栏：日常编程记录云原生文章标签： java 大数据数据库

原文链接：https://www.infoq.cn/article/wjkNGoGaaHyKs7xIyTSB

版权

记录同时被 3 个专栏收录

106 篇文章 4 订阅

订阅专栏

日常编程

87 篇文章 4 订阅

订阅专栏

云原生

13 篇文章 1 订阅

订阅专栏

Dapr 作为新兴的云原生项目，以"应用运行时"之名围绕云原生应用的各种分布式需求，致力于打造一个通用而可移植的抽象能力层。这个愿景有着令人兴奋而向往的美好前景，然而事情往往没这么简单，API 的标准化之路异常的艰辛而痛苦，Dapr 的分布式能力抽象在实践中会遇到各种挑战和困扰。

快速回顾：什么是 Dapr？

Dapr 的全称是 “Distributed Application Runtime”，即 “分布式应用运行时”，是一个由微软发起的开源项目，目前已经进入 CNCF 孵化器。

我们首先来对 Dapr 进行一个简单的介绍。首先来看 ServiceMesh，和传统 RPC 框架相比，ServiceMesh 的创新之处在于引入了 Sidecar 模式：

而 ServiceMesh 只解决了服务间通讯的需求，而现实中的分布式应用存在更多的需求，Multi-Runtime 理论将这些需求归结为四大类：

在 ServiceMesh 初步成功并且 Sidecar 模式被云原生社区普遍接受之后，各企业效仿 ServiceMesh 将应用需要的其他分布式能力外移到各种 Runtime，这逐渐演变成了一个趋势。这些 Runtime 会逐渐整合，最后和应用 Runtime 共同组成微服务，形成所谓的 “Multi-Runtime” 架构，又称 Mecha：

Dapr 项目是目前业界第一个 Multi-Runtime / Mecha 实践项目，下图来自 Dapr 官方，比较完善的概括了 Dapr 的能力和层次架构：

本质差异：Dapr vs ServiceMesh

在快速回顾完 Dapr 之后，我们来正式展开本文的内容。首先需要回答这样一个问题：Dapr 和 ServiceMesh 有什么区别？

这个问题也是大多数读者在了解 Dapr 之后最常问到的一个问题，原因是 Dapr 和 ServiceMesh 在架构上实在太像了，都是以 Sidecar 模式为核心。

Dapr 的基本思路也是和 ServiceMesh 保持一致：通过引入 sidecar 来实现 关注点分离 + 独立维护。

Dapr 和 ServiceMesh 最明显的不同之处是 Dapr 的场景比 ServiceMesh 要复杂:

ServiceMesh 关注于服务间通讯，即下图中虚线部分；而 Dapr 除了服务间通讯之外，还适用于诸多其他的场景，如状态存储、消息的发布订阅、资源绑定、配置等。

下图是 Dapr 目前已有的构建块，以及对他们所提供的能力的简单描述（其中 Service Invocation 对应 ServiceMesh 的服务间通讯能力）：

功能的差异是很直白的，容易理解。但是，如果只是功能上的差异，那么问题来了：如果 ServiceMesh 也提供同样的能力，是不是就和 Dapr 一样了？

我们来看 Envoy 的功能，Envoy 原生支持 HTTP1.1/REST 和 HTTP2 / gRPC 协议，社区增加了对 Dubbo、Thrift 等 RPC 协议的支持，而 Envoy 也在提供对 Kafka、Redis 等原生协议的支持，未来 Envoy 提供更多原生协议支持也是可以预期的。那是不是意味着随着功能的增加，以 Envoy、Istio 为代表的 ServiceMesh 就和 Dapr 一样了呢？

答案当然是否定的—— Dapr 和 ServiceMesh 的本质差异在于其工作模式。ServiceMesh 的工作模式是原协议转发：

ServiceMesh 的 Sidecar 接收到是 App 发出的原生协议的请求，然后转发给另一端的 Sidecar 进而转发给目标 App；或者，对于 Redis/Kafka 等的支持是 Sidecar 将原协议转发给 Redis/Kafka 服务器。在这个过程中，ServiceMesh 的 Sidecar 原则上不修改协议，只做转发（“Forwarding”），Sidecar 扮演的是代理（“Proxy”）的角色；

而 Dapr 的工作模式是能力抽象：

Dapr Sidecar 接收到是 App 发出的遵从标准 API 的请求，这些标准 API 对能力进行了抽象；对于服务间通讯的场景，Dapr Sidecar 会将请求转发给另一端的 Dapr Sidecar；对于服务间通讯之外的能力的支持则需要将标准 API 转换为底层组件对应的原生协议。在这个过程中，Dapr Sidecar 原则上对应用只暴露抽象之后的分布式能力，屏蔽了底层具体的实现和通讯协议，不做"转发"而是提供"能力"，Dapr Sidecar 扮演的是运行时 (“Runtime”) 的角色。

工作模式不同的背后，反映出 Dapr 和 ServiceMesh 在设计目标上的差异

ServiceMesh 的主要设计目标是 低侵入，采用原协议转发的方式可以尽可能的降低对应用的侵入，为了达到无侵入的目标甚至采用了流量劫持的方式。
Dapr 的主要设计目标是 可移植性，即在跨云跨平台的前提下实现无厂商绑定，采用的方式是在将分布式能力抽象为标准 API，并在各种开源项目和云平台上提供这套标准 API 的不同实现，从而达到在不同平台上运行的目标，这即 Dapr 愿景中的 “anywhere”。

总结一下 Dapr 和 ServiceMesh 的差异以及适用场景：ServiceMesh 强调对应用无侵入，支持原协议转发和流量劫持，不仅仅适用于新应用，相比 Dapr 也更加适用于老应用。而 Dapr 提供 “标准 API”、“语言 SDK” 和 “Runtime”，需要应用进行适配（这意味着老应用需要进行改造），侵入性比较大。因此 Dapr 更适合新应用开发（所谓 Green Field），对于现有的老应用（所谓 Brown Field）则需要付出较高的改造代价。但在付出这些代价之后，Dapr 就可以提供跨云跨平台的可移植性，这是 Dapr 的核心价值之一。

因此，在决策是否该采用 Dapr 时，可移植性是一个非常关键的考虑因素。

死生之地：API 标准化的价值

在上一篇文章 Dapr v1.0 展望：从 ServiceMesh 到云原生中，我曾经指出：Dapr 的本质是面向云原生应用的 分布式能力抽象层：

而现实是残酷的：特性越是高级，就越难于让所有组件都支持。

以 Dapr State API 为例，如上图所示从做向右的各种特性，组件的支持程度越来越差：

基本操作：这些是基本的 KV 语义，CURD 操作，而且是每次操作单个 key。所有组件都支持，支持度 =100%。
批量操作：在基本操作的基础上增加对多个 key 同时操作的支持，部分组件不能原生支持，但是 Dapr 可以在单个的基本操作上模拟出批量操作来进行弥补，因此也可以视为都支持，支持度~=100%。
过期时间：可选特性，设置过期时间可以让 key 在该时间之后自动被清理，有部分组件原生支持这个特性，但也有部分组件无法支持。这是一个可选特性，Dapr 的设计是通过在请求中提供名为 TtlInSeconds 的 metadata 来指定。
并发支持：乐观锁机制，要求组件为每个 key 提供一个 etag 字段（或者称为 version），每次修改时都要比对 etag，修改后要更新 etag。这个特性也是只有部分组件支持，需要在组件支持特性中明确指出是否支持。
数据一致性：容许在请求中提供参数指定操作对数据一致性的要求，可以是强一致性或最终一致性，组件如果支持就可以依照这个参数的指示进行操作。这个特性同样只有部分组件支持。
事务：提供对多个写操作的原子性支持，只有部分组件支持（按照前面列出来的组件支持情况，大概是 40%），需要在组件支持特性中明确指出是否支持。

但实际上，在 API 定义和标准化的过程中，我们不得不面对这样一个残酷的现实：API 定义全部特性和所有组件都完美支持 无法同时满足！

这导致在定义 Dapr API 时不得不面对这么一个痛苦的抉择：向左？还是向右？