Dapr 在阿里云原生的实践

1

什么是Service Mesh？

从 2010 年的时候，SOA 架构就已经在中大型互联网公司中开始流行，阿里也在2012 年开源了 Dubbo 。而之后微服务架构开始流行，大量互联网和传统企业都投身到微服务的建设中。在国内逐渐形成了Dubbo 和 Spring Cloud 两大微服务阵营。在2016 年的时候，微服务领域一个更具有前沿性，更加符合容器和 Kubernetes 的微服务方案正在孕育，这个技术被称为 Service Mesh。时至今日，Service Mesh 理念已经得到了大范围普及，很多公司都在 Service Mesh 领域有了落地。

Service Mesh 定义

Service Mesh 是一个基础设施层，主要围绕服务间通信来进行。现在的云原生应用的服务拓扑结构非常复杂，Service Mesh 可以在这种复杂拓扑结构中实现可靠的请求传送。Service Mesh 是以 Sidecar 的方式运行，应用旁边会运行一个独立的 Service Mesh 进程，Service Mesh 负责远程服务的通信。军用三轮摩托车和 Service Mesh 非常相像，军用三轮摩托车上一个士兵负责开车，一个士兵负责对人发起射击。

Service Mesh 解决的痛点

传统的微服务架构大都以 RPC 通信框架为基础，在 RPC SDK 中提供了服务注册/发现，服务路由，负载均衡，全链路跟踪等能力。应用业务逻辑和 RPC SDK 在同一个进程中，这种方式给传统微服务架构带了很多挑战：中间件能力相关代码侵入到了业务代码中，耦合性很高；推动 RPC SDK 的升级成本非常高，进而也导致了 SDK 版本分化非常严重。同时这种方式对应用开发者的要求比较高，需要有丰富的服务治理的运维能力，有中间件的背景知识，使用中间件的门槛偏高。

通过 Service Mesh 方式将一些 RPC 的能力进行下沉，这样可以很好的实现关注点分离、职责边界的明确。随着容器和 Kubernetes 技术的发展，Service Mesh 已经成为云原生的基础设施。

Istio 介绍

在 Service Mesh 领域中， Istio 毫无疑问是当中的王者。Istio 由控制面和数据面构成，在 ServiceMesh 中，不同的 Service 之间，通过 Proxy Sidecar 进行通信。Istio 最核心功能是流量管理，通过数据面和控制面协调完成。Istio 是由 Google 联合IBM，Lyft 一起发起的，是 CNCF 生态版图 Service Mesh 领域的最纯正血统，有望成为Service Mesh事实标准。

Istio 的数据面默认使用 Envoy，Envoy 是社区里默认的最佳数据面。Istio 数据面和控制面的交互协议是 xDS。

Service Mesh 小结

最后，对 Service Mesh 做下小结：

• Service Mesh 定位就是提供服务间通信的基础设施，社区里主要支持 RPC 和http 。
• 采用 Sidecar 方式部署，支持部署在 Kubernetes 和虚拟机之上。

• Service Mesh 采用原协议转发，所以 Service Mesh 也被称为网络代理。正是由于这种方式方式，所以可以做到对应用的零侵入。

2

什么是Dapr？

Service Mesh 遇到的挑战

用户在云上部署业务的形态主要有普通应用类型和FaaS类型。Faas 场景下，比较吸引用户的是成本和研发效率，成本主要通过按需分配和极致的弹性效率来达成。而应用开发者期望通过 FaaS 提供多语言的编程环境，提升研发效率，包括启动时间、发布时间、开发的效率。

Service Mesh 的实现，本质是原协议转发，原协议转发可以给应用带来零侵入的优势。但是原协议转发也带来了一些问题，应用侧中间件SDK还需要去实现序列化和编解码工作，所以在多语言实现方面还有一定成本；随着开源技术的不断发展，使用的技术也在不断迭代，如果想从 Spring Cloud 迁移到 Dubbo ，要么应用开发者需要切换依赖的 SDK，如果想借助Service Mesh来达到这个效果，Service Mesh 需要进行协议转换，成本较高。

Service Mesh 更加聚焦于服务间的通讯，而对其他形态的 Mesh 的支持上非常少。比如 Envoy， 除了在 RPC 领域比较成功外，在 Redis、消息等领域的尝试都未见成效。蚂蚁的 Mosn 中支持了 RPC 和消息的集成。整体多 Mesh 形态的需求是存在的，但是各个 Mesh 产品各自发展，缺少抽象和标准。如此多形态的 Mesh ，是共用一个进程吗？如果是共用一个进程，那么是共用一个端口吗？许多问题都没有答案。而控制面方面，从功能角度来看的话，大都围绕流量来展开。看过 xDS 协议里的内容，核心是围绕发现服务和路由来展开。其他类型的分布式能力，在 Service Mesh的控制面中基本没有涉及，更谈不上抽象各种类似 xDS 的协议去支持这些分布式能力。

因为成本和研发效率等原因，FaaS 受到了越来越多客户的选择，FaaS 对多语言和编程 API 的友好性上有了更多诉求，那么 Service Mesh 在这两块还是不能给客户带来额外的的价值。

分布式应用的需求

Bilgin Ibryam 是 Kubernetes Patterns 的作者，是 RedHat 的首席中间件架构师，在 Apache 社区里非常活跃。他发表了一篇文章对当前分布式的一些困难和问题进行了抽象，将分布式应用需求分成了 4 个大种类：生命周期、网络、状态、绑定。每种类型下面还有一些子能力，如 Point-to-Point， pub/sub， Caching 等比较经典的中间件能力。应用对分布式能力有如此多的需求，而 Service Mesh 显然不能满足应用的当前的需求。Biligin Ibryam 还在文章中提出了 Multiple Runtime 的理念来解决Service Mesh 的困境。

Multiple Runtime 理念推导

在传统的中间件模式下，应用和分布式能力是在一个进程中，以 SDK 方式进行集成。随着各种基础设施下沉，各种分布式能力从应用中移到了应用外。如 K8s 负责了生命周期相关的需求，Istio、Knative 等都负责一些分布式能力。如果将这些能力都移动到独立的 Runtime 中，那么这种情况无论从运维层面还是资源层面来看，都是没办法接受的。所以这时候肯定需要将部分 Runtime 进行整合，最理想的方式肯定是整合成一个。这种方式被定义成 Mecha ，中文意思是机甲的意思，就像日本动漫里主人公变身穿上机甲，机甲的每个部件就像一个分布式能力，机甲里的人对应的是主应用，也叫 Micrologic Runtime 。 这两个 Runtime 可以是一对一的 Sidecar 方式，这种非常适合传统的应用；也可以是多对一的 Node 模式，适合边缘场景或者网管模式下。

那么对于将各种分布式能力进行整合的 Mecha Runtime 这一目标本身问题不大，那么怎么整合呢？对 Mecha 有什么要求呢？

1. Mecha 的组件能力是抽象的，任何一个开源产品可以快速进行扩展和集成。
2. Mecha 需要有一定的可配置能力，可以通过 yaml/json 进行配置和激活。这些文件格式最好能和主流的云原生方式对齐。
3. Mecha 提供标准的 API ，和主应用之间的交互的网络通信基于此 API 来完成，不再是原协议转发，这样对于组件扩展和 SDK 的维护都能带来极大的便利性。
4. 分布式能力中的生命周期，可以将部分能力交接过底层的基础设施，比如 K8s。当然有些复杂的场景，可能需要 K8s、APP、Mecha Runtime 一起来完成。
   
   

既然最理想只剩下一个 Runtime , 那么为什么还叫 Multiple Runtime 呢？因为应用本身其实也是一个 Runtime ，再加上 Mecha Runtime ，所以至少是两个 Runtime 。

Dapr 介绍

前面的 Multiple Runtime 介绍地比较抽象，可以来从 Dapr 来重新理解下 Multiple Runtime 。Dapr 是 Multiple Runtime 的一个很好的践行者，所以 Dapr 肯定和应用共存的，要么是 Sidecar 模式，要么是 Node 模式。Dapr 这个词其实是不是造出来的，而是 Distributed Application Runtime 的首字母拼接而成，Dapr 这个图标可以看出来是一个帽子，这个帽子其实是一个服务生的帽子，表示的含义是要为应用做好服务。

Dapr 是由微软开源的，阿里巴巴深度参与合作。当前的 Dapr 已经发布 1.1 版本，现在已经接近生产的能力。

既然 Dapr 是 Multiple 的最佳实践者，那么 Dapr 的运行机制也是基于 Mulitple Runtime 的理念来构建的。Dapr 对分布式能力进行了抽象，定义了一套分布式能力的 API，而且这些 API 是基于 Http 和 gRPC 来构建的，这种抽象和能力在 Dapr 中被称为 Building Block；Dapr 为了支持开源产品和商业化等不同类型的产品对 Dapr中的分布式能力进行扩展，内部拥有一套 SPI 扩展机制，这种 SPI 机制叫 Components 。应用开发者在使用 Dapr 之后，只需要针对各种分布式能力的 API 来进行编程，而无需过多关注具体的实现，而 Dapr 中根据 Yaml 文件可以自由激活对应的组件。

Dapr 特性

应用开发者使用各种多语言的 Dapr SDK 就可以直接拥有各种分布式能力。当然开发者也可以自己基于 HTTP 和 gRPC 来完成调用。Dapr 可以运行在大部分环境里，包括你自己电脑的环境，或者任何 Kubernetes 环境下，或者边缘计算场景，或者阿里云、AWS、GCP 等云厂商。

Dapr 社区里已经集成了 70+ 的 components 实现，应用开发者可以快速进行选择和使用。相似能力的组件的替换，可以通过 Dapr 里完成，应用侧可以做到无感知。

Dapr 核心模块

我们从 Dapr 产品模块纬度来解析下，看为什么 Dapr 是 Mulitiple Runtime 的一个很好实践。

Component 机制确保了可以快速扩展能力的实现，现在社区已经有的 Components实现已经有 70 个以上，不只包含开源产品，还包含云上的商业化产品。

Building Block 表示的的分布式能力，现在只支持 7 个，后续需要更多的分布式能力能够进来。BuildingBlock 现在支持了 HTTP 和 gRPC 这两种开放，而且普及度已经非常高的协议。而 Dapr 中 Building Block 下具体那些 Components  会被激活，需要依赖 YAML 文件来进行。正因为 Dapr 中采用了 HTTP、gRPC 的方式暴露能力，所以在应用侧想要支持多语言的标准的API编程界面就变得更为容易了。

Dapr 核心：Component & Building Block

Dapr Component 是 Dapr 插件扩展的核心，是 Dapr 的 SPI 。现在支持的 Components 有 Bindings 、Pub/Sub、Middleware、ServiceDiscovery、Secret Stores、State。扩展点里有些是功能纬度的如Bindings，pub/sub,state 等，有些是横向的如 Middleware。假设你想实现Redis的Dapr集成，你只需要去实现 Dapr 的State Component。Dapr Building Block是Dapr提供出来的能力，支持 gRPC 和 HTTP 方式。现在支持的能力有 Service Invocation，State，Pub/Sub 等。

一个 Building Block 由 1 个或多个 Component 组成，Binding的Building Block 包含 Bindings 和 Middleware 两个 Component 。

Dapr 整体架构

Dapr 和 Istio 一样，也有数据面和控制面。控制面有 Actor Placement，Sidecar Injector， Sentry， OPerator。Actor Placement 主要为 Actor 服务，Sentry 做安全和证书相关的工作，Sidecar Injector 主要负责 Dapr Sidecar 的注入。Dapr 里激活某个组件实现是通过 YAML 文件来完成的，YAML 文件可以通过两种方式来指定：一种是本地指定运行时参数，另外一种是通过控制平面 Operator 来完成，将组件激活的文件以 K8s CRD 方式存储并下发到 Dapr的Sidecar 中。控制面的 2 个核心组件都依赖于 K8s 来运行。现在的 Dapr Dashboard 功能还很弱，短期还不到增强的方向，现在各个组件的集成之后，各个组件的运维还需要在原来的控制台里完成，Dapr 控制平面不参与具体组件实现的运维。

Dapr 标准运行形式是和应用在同一个 Pod 中，但分属于两个容器。Dapr 的其他内容，前面已经做了足够的介绍，这里不做介绍了。

Dapr 微软落地场景

Dapr 经历了 2 年左右的发展，在微软内部的落地情况是怎么样的呢？

Dapr 的 github 上有两个项目：workflows 和  Azure Functions Dapr extensions。Azure Logic App 是微软的一个基于云上的自动工作流平台。而 Workflows，就是整合了 Azure Logic App 和 Dapr。Azure Logic App 中有几个关键的概念，Trigger 和 Connector 和 Dapr 非常契合。Trigger 可以使用 Dapr 的 Input Binding 来完成，依赖 Dapr 的 Input Binding 的大量组件实现，可以扩大流量入口的类型。而 Connector 和 Dapr 的 Output Binding 或者 Service Invocation 的能力非常匹配，可以快速访问外部资源。Azure Functions Dapr extensions 则是基于Azure Function extension 做的 Dapr 支持，可以让 Azure Function 快速使用上Dapr 的各种 Building Block 的能力，同时能给函数开发者带来多语言的相对简单一致的编程体验。

Azure API Management Service和上面提到的两个落地场景的角度不太一致，它是前提是应用之间已经通过Dapr Sidecar方式进行访问，应用的提供的服务通过Dapr来进行暴露。这时候如果非K8s的应用或者跨集群的应用想要访问当前集群的服务，就需要一个网关，这个网关可以直接暴露Dapr的能力，在网关中会增加一些安全和权限的控制。当前支持3种Building Block：Service Invocation、pub/sub、resource Bindings。

Dapr 小结

Dapr 提供的面向能力的 API ，能够给开发者带来支持多语言的一致的编程体验，同时这些 API 的SDK相对比较轻量级。这些特性非常适合 FaaS 场景。而随着 Dapr 集成生态的不断完善，开发者面向能力编程的优势将进一步扩大，通过 Dapr 可以更加方便地将 Dapr 组件的实现进行替换，而无需开发者做代码的调整。当然原来的组件和新的组件实现，必须是相同类型的分布式能力。

和 Service Mesh 差异点：

提供能力：Service Mesh 专注服务调用；Dapr 提供的分布式能力范围更广，覆盖多种分布式原语。

工作原理：Service Mesh 采用原协议转发做到零侵入；Dapr 采用多语言SDK + 标准API + 各种分布式能力。

面向领域：Service  Mesh 对传统微服务的无侵入升级支持很友好；Dapr 对面向应用的开发者提供了更加友好的编程体验。

3

阿里在 Dapr 上的探索

阿里在 Dapr 的发展路线

2019 年 10 月，微软开源了 Dapr，发布了 0.1.0 的版本。这时候，阿里和微软正好因为 OAM 已经展开一些合作，了解到了 Dapr 这个项目，所以就开始对其进行评估。在 2020 年初的时候，阿里和微软在阿里巴巴线下做了一轮 Dapr 的沟通，了解到了微软对 Dapr 的看法、投入，以及后续的发展计划。此时阿里已经认定 Dapr 这个项目具有较大的价值。一直到 2020 年中，才开始围绕 Dapr 开始投入工作。到 10 月份，Dapr 在函数计算场景下开始线上灰度部分功能，到今天为止，函数计算相关的 Dapr 的所有功能的灰度已经基本完成，开始开放公测。到 2021 年 2 月份，终于发布了 1.0 版本。

阿里云函数计算集成 Dapr

除了极致弹性等运维侧的好处之外，函数计算区别于中台应用的地方还在于，函数计算更加关注能够给开发者带来更好的研发体验，提升整体的研发效率。而 Dapr 能够给函数计算的价值就是提供多语言的统一的面向能力的编程界面，而开发者无需关注具体的产品。像 Java 语言如果要使用阿里云上的 OSS 服务，需要引入 maven 依赖，同时需要写一些 OSS 代码，而通过 Dapr 你只需要调用 Dapr SDK 的 Binding 方法即可以做到，方便编程的同时，整个可运行包也无需引入多余的依赖包，而是可控的。

函数计算英文名是 Function Compute，简称为 FC。FC 的架构包含的系统比较多，和开发者相关的主要包括 Function Compute Gateway和函数运行的环境。FC Gateway主要负责承接流量，同时会根据承接的流量的大小，当前的 CPU、内存使用情况，对当前函数实例进行扩缩容。函数计算运行时环境部署在一个 Pod 中，函数实例在主容器中，dapr 则是在 sidecar 容器中。当有外部流量访问函数计算的服务时，流量会先走到 Gateway ，Gateway 会根据访问的内容将流量转发到提供当前服务的函数实例中，函数实例接收到请求之后如果需要访问外部资源，就可以通过Dapr 的多语言 SDK 来发起调用。这时候 SDK 会向 Dapr实例发起gRPC请求，而在dapr 实例中回根据请求的类型和 body 体，选择对应的能力和组件实现，进而向外部资源发起调用。

在 Service Mesh 场景下，Mesh 以 Sidecar 形式存在，和应用部署在同一个 Pod 的两个容器里，可以很好满足 Service Mesh 的需求。但是在函数计算场景下，Dapr作为独立容器方式运行过于消耗资源，而且多个函数实例本身部署在一个 Pod 中以便节省资源开支和秒级弹性。所以在函数计算场景下，需要将函数实例和Dapr进程部署在同一个容器下，但是以两个进程方式存在。

函数计算场景下，可以设置预留实例数，表示当前函数最小实例数。如果有预留的实例，但是这些实例长久没有流量访问需要进入暂停/休眠状态，这种方式和 AWS 的方式是一致的。进入休眠状态的函数，实例内的进程或者线程需要停止运行。函数运行时中增加了 Extension 结构，来支持 Dapr 生命周期的调度。当函数实例进入休眠状态时，extension 通知 Dapr 进入休眠状态；当函数实例恢复运行之后，extension 通知 Dapr 重新恢复之前运行的状态。Dapr 内部的组件实现需要能支持这种方式的生命周期管理，以 Dubbo 为例，Dubbo 的注册中心 nacos 需要定时往 Nacos server 发送心跳保持了解，同时 Dapr 集成的Dubbo Consumer也需要往Dubbo Provider 发送心跳。当进入暂态之后，心跳都需要退出；当恢复运行之后，整个运行状态需要恢复。

上面讲到的函数计算和 Dapr 结合的点，都是基于对外的流量，那么流入的流量呢？消息的流量是否可以直接流入到 Dapr ，而无需经过 Gateway 呢？要做到这一点，还需要在 Dapr Sidecar 将一些性能数据及时上报给 Gateway ，方便 Gateway 可以做到资源的弹性。

SasS 业务上云

随着阿里内部孵化的SaaS业务越来越多，SaaS业务对外服务的诉求非常强烈。而SaaS业务对多云部署的诉求非常强烈，客户期望SaaS业务能部署在阿里云公有云或者华为专有云上。而且客户期望底层依赖的技术是开源的或者标准的云厂商的商业化产品。

以阿里一个SaaS业务上云来说明，左侧是阿里内部原来的系统，右侧是改造之后的系统，改造的目标是将依赖的阿里内部的系统切换成开源软件，Ali RPC切换到Dubbo，而阿里内部的Cache，Message，Config分别切换到Redis、RocketMq和Nacos。期望通过Dapr来实现最小代价的切换。

既然想用Dapr来完成这个使命，那么最简单粗暴的方法肯定是让应用依赖Dapr的SDK，但是这种方式改造成本太高，所以我们在保持原来API不变的情况下，将底层实现适配到Dapr SDK。通过这种方式，应用就可以直接使用原来的API访问Dapr，只需要升级对应的依赖JAR包版本。改造之后，开发者还是面向原来的SDK进行编程，但是底层已经被替换成了Dapr的面向能力编程，所以在迁移过程中，应用可以使用一套代码，而无需为每个云环境或者不同技术维护不同的分支。集团内部用Dapr Sidecar的时候，会使用rpc.yaml、cache.yaml、msg.yaml、config.yaml来激活组件实现，而在公有云上回通过dubbo.yaml、redis.yaml、rocketmq.yaml、nacos.yaml文件来激活适合阿里云环境的组件实现。这种通过不同yaml文件激活不同组件来屏蔽组件实现的方式给SaaS业务多云部署形态带来了极大的便利。

钉钉是Dapr的重要合作伙伴和推动者，和云原生团队合作推进Dapr在钉钉落地。通过将一些中间件能力下沉到Dapr Sidecar之后，屏蔽了底层相似能力的中间件实现。但是钉钉还有自己的业务痛点，钉钉通用的业务组件是强业务绑定，需要具体的业务进行一些定制，这样同时导致了复用度很低，所以钉钉期望通过将部分业务组件能力下沉到Dapr。这样可以让不同业务有相同的编程体验，而组件维护者只需要维护好Components实现。

4

Dapr展望

基础设施下沉成为软件发展趋势

软件架构的发展历史及其精彩。回顾阿里巴巴系统架构演进的历史，能让人了解国内甚至全球的软件架构的发展历史。淘宝最开始成立的时候，是单体应用；随着业务规模的发展，系统首先对硬件进行升级这种Scale Up的方式；但是很快发现这种方式遇到了各种各样的问题，所以在2008年开始引入了微服务的解决方案；SOA的解决方案是分布式的，对于稳定性，可观测性等方面，需要引入熔断、隔离、全链路监控等高可用方案；接下来面临的问题是怎么在机房、IDC层面来让业务达到99.99%以上可用的SLA，这时候就有了同城双机房、异地多活等解决方案。而随着云技术的不断发展，阿里巴巴拥抱和引导云原生技术的发展，积极拥抱云原生技术，以K8s为基础，积极开展云原生技术的升级。

从这个历史中，我们可以发现，软件架构新的诉求越来越多，原先底层基础设施无法完成只能交给应用侧富SDK去完成，在K8s和容器逐渐成为标准之后，重新将微服务和一些分布式能力还给基础设施。未来的趋势是以Service Mesh和Dapr为代表的分布式能力下沉，释放云和云原生技术发展的红利。

云原生场景下的应用开发者的诉求

未来的应用开发者，应该期望能够面向能力，无言无关，不和具体云厂商和技术绑定的开发体验，同时通过云技术的红利能够做到极致的弹性带来的成本优势。我相信这个理想还是有可能实现的一天的，从当前的角度出发，怎么样才能完成这个目标呢？

1. Multiple Runtime理念能够真正落地，并且能够持续发展；
2. 以Dapr为例，期望能将Dapr面向分布式能力的API推动成为一个行业标准，并且这个标准是需要持续发展的；
3. K8s和Serverless技术的持续发展，未来可以将弹性做到极致。

Dapr 社区方向

最后来看下Dapr的社区发展：

1.推动 API 标准化，集成更多分布式能力；
2.更多Component集成，Dapr 生态完善；
3.更多公司落地，拓展产品边界和打磨 Dapr 产品， 达到生产可用；
4.进入 CNCF， 成员云原生的 Multiple Runtime 的事实标准。