什么是多运行时架构？( 三 ) _架构

文章插图
图片
（来源：Dapr）
其中有一些 Blocks 的能力由 Dapr 自己就能实现，有一些则需要由实际的基础设施或中间件来实现。选取几个典型举例说明：

Service-to-service Invocation：提供服务间调用的能力，其中也隐含了服务的注册与发现。该 Block 的能力由 Dapr 直接实现。
State management：提供状态管理能力，最简单的就是存取状态。该 Block 需要其他基础设施通过 Component 的形式实现，例如定义一个 redis Component 。
Publish and subscribe：提供消息发布和订阅的能力，这是非常典型的一种分布式能力。也需要通过基础设施来实现，如定义一个 Kafka Component 。

Dapr 的限制与挑战
Dapr 期望通过定义一个能容纳所有需求的分布式能力抽象层，来彻底解放业务逻辑。从归一化的角度看，不得不说这是一种大胆而富有野心的尝试，理想条件下的确能非常优雅地解决问题。但现实总是充斥着各种跳脱出理想的情况， Dapr 在推广的过程中遇到了很多限制与挑战。
与 Service Mesh 整合
作为面向开发侧提供的能力抽象层， Dapr 在网络能力上包含了 mTLS、Observability 与 Resiliency（即超时重试熔断等），但并没有包含诸如负载均衡、动态切换、金丝雀发布等运维侧的流量管理能力。

文章插图
图片
（来源：Dapr）
因此对于不断走向成熟的业务系统，可能既要 Service Mesh 在运维侧的流量管理能力，又要 Dapr 在开发侧的分布式抽象能力，不管谁先谁后，都将面临一个问题：怎样搭配使用它们才是正确的？某些场景下可以做适配，如：

对于 distributed tracing 的能力，如果采用 Service Mesh 来实现，则需要考虑将原本 Dapr 直连的中间件也加入 mesh 网络，否则会 trace 不到。但从 distributed tracing 本身功能角度讲，更应该使用 Dapr 。
mTLS 应该只在 Dapr 或者 Service Mesh 中开启，而不应该都开启。

但 Dapr 与 Service Mesh 配合使用中难以避免的是开销的问题，包括资源开销和性能开销。
每个应用 Pod 携带两种 sidecar ，再加上 Dapr 和 Service Mesh 自己的控制面应用（高可用方案主备或多副本），这些资源开销是无法忽略，甚至是非常可观的。
而由于 Service Mesh 网络代理的流量劫持，网络调用需要先经过 Dapr sidecar ，再经过网络代理 sidecar ，被代理两次，也会造成一定的性能开销。
下表是汇总的 Dapr 官方标注的 daprd 资源与性能消耗数据，以及 Istio v1.16（最新版未找到）官方标注的 envoy 资源与性能消耗数据：

文章插图
简单计算一下就会发现，当拥有 1000 个业务实例时， dapr + istio 的 Sidecar 进程可能会消耗 800+ vCPU 和 60+ GiB 内存。
随着分布式能力抽象层的不断扩展，到底哪些属于开发侧，哪些属于运维侧，也许不会像现在这样泾渭分明了。因此已经有对 Multi-Runtime 与 Service Mesh 能力边界越来越模糊的讨论。
Sidecarless？
从上一节的表格我们发现，资源消耗以及性能的问题其实不只是 Dapr 下的场景，实际上它是 sidecar 模式自有的限制，因此在 Service Mesh 领域的讨论中，已经有提出 Sidecarless 的概念了，即通过 DaemonSet 而不是 Sidecar 的形式来部署网络代理。

文章插图
图片
对于网络代理的 Sidecarless 化，支持方认为它能带来高性能、低资源消耗的优点，而反对方则认为它会导致安全性与隔离性差、故障的爆炸半径过大等缺点。
那么， Mecha 是否也可能会走向 Sidecarless 呢？
与网络代理的 Sidecarless 类似，如果将 Mecha 做成 Daemonset ，其优劣势也差不多。而 Daemonset 形式的 Mecha ，由于只启动一次，可能会在 Serverless 的场景下大幅缩短 Serverless 函数的执行时间。对此 Dapr 项目也有相关的讨论。