云效峰会 —— Dapr 在阿里云云原生的实践

简介：云效峰会 —— Dapr 在阿里云云原生的实践
作者：曹胜利，时间：2021-08-24
内容简要：
一、Service Mesh 快速回顾
二、分布式运行时 Dapr 介绍
三、阿里在 Dapr 上的探索
四、分布式运行时 Dapr 未来展望

一、Service Mesh 快速回顾

（一）Service Mesh 介绍

2016 年开始，Service Mesh 的理念和一些产品逐渐问世，至今为止已经有许多公司开始实施 Service Mesh 并取得了一些进展。

• Service Mesh 是一个基础设施层，用于处理服务间的通信。对于现在的云原生微服务架构，Dapr 可以帮它屏蔽掉底层的具体技术，提供可靠的请求传送。
• Service Mesh 是通过Sidecar的方式提供服务，Service Mesh 的进程和应用进程分属于两个进程，就像军用三轮摩托车有两个人，一个人负责行驶，另外一个人负责往外扫射敌人，Servier Mesh的角色其实和扫射的角色是非常相近的。

传统中间件的分布式能力的 SDK 和应用是部署在一起的，但这种方式带来很多问题，

1. 业务代码和中间件的代码进行了耦合。
2. 中间件 SDK 的升级非常困难，进而导致了版本的分化非常严重。
3. 一位新员工如果进入到一个公司的时候，熟悉中间件的成本比较高。

所以Service Mesh可以将这些底层的基础能力进行下沉，下沉到独立的Sidecar中，可以给应用带来关注点的分离，应用只需要关注自己的业务逻辑，而无需关注具体的中间件能力。

（二）Istio 介绍

Istio 毫无疑问是 Service Mesh 的强者，是由 Google IBM 和 Lyft 共同发起创立的，它主要的核心功能是提供流量的管理。

Service A 如果想访问 Service B，它需要经过旁边的 Proxy Sidecar，然后将请求发送给远端的 Proxy Sidecar，然后远端的 Proxy Sidecar 再将请求发送给 Service B。

Istio 其实是由数据面和控制面来实现的，数据面现在的社区最强者是 Envoy。

（三）Service Mesh 小结

接下来我对Service Mesh做一个小结。

Service Mesh 的定位是提供服务间的通讯基础设施，主要支持了 Http/RPC，而且 Service Mesh 是通过原协议转发的方式对应用提供服务，所以对应用的侵入几乎为零。

二、分布式运行时 Dapr 介绍

（一）Service Mesh 遇到的挑战

接下来介绍 Dapr，随着云技术和云原生技术的发展，云能给业务开发者提供的服务除了应用之外，还有 FaaS 场景下的一些服务，你只需要提供一个函数或者一个 JAR 包，就可以在FaaS 场景下进行部署。

FaaS 场景下能够给用户带来的好处是成本节约，通过极致的弹性和按需的收费方式来实现。Servier Mesh 是通过原协议转发的形式进行实现，但是如果要去实现一个多语言的 SDK，它还是需要实现序列化和协议的分装，所以说在多云实现这一块还是具有一定的成本。

同时随着开源技术的不断发展，技术在不断地引进，假设你们公司如果开始使用了 Spring Cloud，现在希望将这个技术切换到 gRPC 上，这时候就有两种方法能够实现。

1. 第一种是将应用从依赖 Spring Cloud 切换到 gRPC 上，同时业务代码层面也需要做一些变更。
2. 另一种方式应用层无需做任何改变，通过 Servier Mesh协议转换的方式来完成，Service Mesh 接收到 Spring Cloud 流量之后转换成 gRPC，然后向外发送请求。

随着 Service Mesh 的发展，现在越来越多的 Mesh 开始出现，像 Motion 中的 Mesh 不仅支持RPC，还支持了消息。同时，蚂蚁还有 DB Mesh，是通过 C++ 实现的，所以多 Mesh 的趋势是很明显的。

但这么多Mesh是怎么共存的？是多进程的方式进行共存，还是单进程多端口的方式，协议又是怎么存在的？同时，像 Istio 这种 Service Mesh 对微服务调用之外的支持非常有限，像 XDS 主要是去支持服务发现、路由规则等等。

最后，FaaS 用户越来越多，FaaS 落地的话有一些强诉求，业务开发者希望能够提供多语言、更加友好的编程 API，但是这一块 Service Mesh 其实是有缺陷的。

（二）、分布式应用的需求

此时，社区里面有一个厉害的人出现了——Bilgin Ibryam。

Bilgin Ibryam 是 RedHat 中间件首席架构师，也是 Apache Commit，在 Apache 社区里面非常活跃，他提出了一个理论，将分布式的能力进行了抽象，抽象成了4大种类，包括生命周期、网络、状态和绑定。

（三）、Multiple Runtime 理念

同时，Bilgin Ibryam 还提出了一个理念，叫Multiple Runtime，那么这个理念是怎么推导出来的？

传统的中间件各种分布式能力都在 SDK 里面，然后和应用部署在同一个进程里面。

随着云原生和基础设施的下沉发展，各种基础能力进行了下沉，出现了各种各样的 Sidecar，包括 Dapr、Istio 等。

这么多 Sidecar 出现了之后，Sidecar 之间怎么共存，它们都是以独立的进程方式运行，就会给运维和资源消耗带来很大的问题，所以说我们希望有某种机制能够将 Sidecar 进行合并成几种，当然最理想的情况下当然是合并成一种这时候。

它的理论里面有一个概念叫 Mecha，Mecha 在日本动漫里面就是机甲的意思，男主人公如果在变身的时候，他会穿上机甲，然后就自动带上了分布式的能力。那么通过 Mecha 来实现各种 Sidecar 进行合并的这种方式，对 Mecha 有什么要求？

1. Mecha需要能够有一种机制，能够将各种开源的或者商业化的产品能够集成到的Dapr体系中，能够支持插件的扩展机制。
2. 提供可配置的能力，最好是通过 Yaml 或 Json 这种在 K8s 里面比较通用的配置方式。
3. Mecha 能够提供分布式API能力，这种 API 最好是 HDP 或 GRPC 的形式，因为这两种形式是开放的，而且已经得到了大众的认可。

当然，生命周期相关的管理可以交给 K8s 来完成，而不用 Multiple Runtime 本身去关注。

（四）Dapr 介绍

接下来我们来介绍一下 Dapr，是 Multiple Runtime 的实践者，名称由来是 Distributed Application Runtime 的首字母，它是由微软发起的，然后阿里巴巴现在深度参与合作的一个开源项目。

Dapr 当前的版本是 1.1，在今年（2021年） 2 月份的时候发布了 1.0 版本，现在的社区的 Star 数已经到达 13.1k。

Dapr 有哪些核心的机制呢？

1. Dapr 提供了面向分布式能力的 API，而且这些API通过 HTTP 和 GRPC 的方式进行暴露。
2. Dapr 内部有一套自己的 SPI 扩展机制，无论是开源或商业化产品都能够很方便地集成进来。

这个机制在 Dapr 里面叫做 Component，也叫做组件。应用开发者只需要基于 Dapr 的多语言的 SDK，并且面向能力的方式对 Dapr 进行编程，而底层的具体实现则由 Dapr 的 Yaml 文件的方式进行激活，应用无需感知到是由哪种实现来完成的。

（五）Dapr 特性

Dapr 里面有两个关键的特性，第一个是 “Any Languag，Anywhere” ，就是应用开发者可以基于 Dapr 的多语言的 SDK 就开始面向 Dapr 编程。

同时，Dapr 可以部署在任何环境里，包括本地的环境，边缘计算的场景，拥有 K8s 的环境，或者说任何商业化的云产品开发厂商中，同时 Dapr 提供了可插拔/可替换的组件，现在社区里面已经有超过 70 个组件。

（六）Dapr 架构

那么我们来从Dapr模块的角度来看一下，为什么说Dapr满足Multiple Runtime的理念。

在整个架构最下面的部分里，它提供了 Component 的机制，包括了 Component 能力的抽象以及多达70多种的 Component 实现，再往上一层是 Building Block（构建块）就是前面讲到的面向分布式能力的那些能力，同时这些能力可以通过 GRPC 或者 API 的方式进行暴露。

（七）Dapr – Components & Building Block

那么现在在 Dapr 社区里面已经支持的 Components 包括 Bindings，Pub/sub，Middleware， Service discovery 等。

这些能力有纵向的功能层面的能力，像 Bindings，Pub/sub，也有一些横向的能力，像Middleware，Dapr 支持的 Building Block 有以下几种，包括 Service Invocation，State， Pub/Sub，Bindings 等 7 种，一个 Building Block 由一个或者多个的 Component 组成，像一个 Bindings 的 Building Block 可以由一个 Component 和 Middleware 共同组成，如果一个开发者想实现 Redis 和 Dapr 的集成，该开发者可以去实现 State Component，把 Redis 集成进去就可以做到。

（八）Dapr 整体架构

Dapr 和普通的 Istio 其实是一样的，它也包含了数据平面和控制平面，但是它的控制平面和Istio比还是比较偏弱，它没有基于流量的管控，它更多的是拼运维层面，包括 Actor Placement，Sidecar Injector，Sentry，Operator。

• Actor Placement 主要是解决了 Actor 的服务选址问题。
• Sentry 主要解决 CA 证书等安全方面的问题。
• Sidecar Injector 主要负责 Dapr Sidecar 的注入。

Dapr 支持 Yaml 方式进行配置，它支持的方式有两种：

1. 一种是在本地的目录下面放入Yaml文件，然后通过环境变量的方式进行激活。
2. 还有一种方式是运维者在 Dapr 的 Operator 中写入 Yaml 文件，然后 Yaml 文件会写入到K8s 的 CRD 文件中，Dapr Sidecar 需要去感知到 CRD 的文件格式。

（九）Dapr 微软落地场景

Dapr经历两年多的发展，在微软内部也有一些落地场景。

其中，workerflows 和 Azure Functions Dapr extensions 这两个产品都是在 GitHub 上，Workflows 整合了 Azure Logic Apps 和 Dapr 的一个产品，Azure Logic Apps 是里面有几个关键的概念，叫做 Trigger、Functions 和 Connector。

其中，Trigger 可以使用 Dapr 的 Input Binding 来完成，而 Connector 可以使用 Dapr 的Service Invocation 或者 Output Binding 完成。Azure Logic Apps 和 Dapr 集成之后可以全部接收 Dapr 已经集成的70个组件，能够扩大自己的服务范围。

Azure Functions Dapr extensions 这个产品其实和上面讲到 workerflow 比较相近，它里面也有两个比较接近的概念：Trigger 和 Connector。

Azure API Management Service 是微软提供的 API 管理的一个服务，它和 Dapr 集成有两种方式。

1. 一种方式是当前的API Management Service已经完成了协议转发，然后通过Dapr做服务调用，将流量转发到下面的APP里面去，主要可以运用Dapr Service Invocation的能力。
2. 还有一种是API Management Service里面不做任何的协议转换，而将协议转换交给Dapr来做，由Dapr来完成协议的封装和转发。

（十）Dapr 小结

Dapr 提供了标准的 API，能够给开发者带来支持多语言、面向能力的统一编程体验，这种能力非常适合函数计算场景。而随着 Dapr 整个生态的不断发展，越来越多的开源和商业化产品集成到 Dapr 的生态中，可以利用 Dapr 组件的可插拔能力，将底层具体的组件实现给屏蔽掉，给业务开发者带来不一样的编程体验。

接下来介绍一下 Service Mesh 和 Dapr 的一些差异点：

• Service Mesh 它主要专注于服务调用， Dapr 天生就是为了服务更多的分布式能力而诞生的，它提供了70多种分布式能力的集成，而且将来会覆盖更多的分布式场景。
• Service Mesh 当前是采用原协议转发的方式进行，可以给应用带来零侵入的体验，Dapr 采用了多语言 SDK 加标准 API 加各种分布式能力的方式提供服务。

三、阿里在 Dapr 上的探索

（一）Dapr 的发展路线（阿里巴巴内部参与时间点）

接下来介绍阿里在Dapr上的一些探索和实践。

首先看一下 Dapr 和阿里的渊源，在 2019 年 10 月份的时候，微软开源了 Dapr，那时候版本是 0.1.0。彼时阿里巴巴刚好和微软有一个项目合作，从侧面了解到了 Dapr 项目的存在，经过内部一定时间的评估之后，2020 年初阿里巴巴和微软进行了一次线下的沟通。

在沟通过程中，微软介绍了 Dapr 以及一些规划和想法，以及内部落地的情况，然后我们认定Dapr 在云原生场景下有一定的发展前景。2020 年年中，阿里巴巴开始投入 Dapr 项目，主要是解决函数计算对外流量的问题。到了 2020 年 10 月份，在函数计算场景下，我们试点了RPC 这一中间件的能力，到年底的时候我们试点了 Catch、消息、Config 等能力，到 2021 年2 月份的时候，Dapr 发布了 1.0 版本。

（二）阿里云函数计算

前面提到过函数计算能给业务带来的价值，主要能够大幅降低成本，而从开发者角度来看，函数计算能够给开发者带来更好的研发体验和研发效率。

所以，Dapr 在这一块能够提供的最大价值是提供多语言、面向能力的统一编程界面，而且期望通过 Dapr 之后，函数的部署或启动能够更加快速，使函数能够更加轻量。

函数计算整体架构比较复杂，但是和开发者相关的主要有两块：

1. 函数计算网关 Function Compute Gateway。
2. 函数的 Runtime 运行时。

Gateway 这方面主要有两个功能：

1. 流量的转发。
2. 根据流量的 QPS，根据函数实例的 CPU 和内存消耗情况提供弹性。

当前的 Dapr 实例和函数的实例其实是部署在同一个 Pod 下面的两个容器里面，类似于Service Mesh 的标准形式进行部署。

整个流量流转的形式是这样的，当有流量流进来的时候，它会先进入 Gateway，然后 Gateway 经过一定的判断，看是否需要做弹性的扩缩容，同时它会将流量转发到某个函数的实例中，函数实例在执行它的函数代码过程中，会调用 Dapr 多语言 SDK，然后向 Dapr 发起一次 RPC 的请求，通过 Dapr Sidecar 向外发送 BaaS 化的服务请求。

之前的这种方式我们是在同一个 Pod 下面部署了两个容器的方式，这种方式和传统的 Service Mesh Sidecar 的方式相同，但是函数计算场景下对资源消耗要求更加高，将 Dapr 部署到一个独立容器中的这种方式资源消耗过高，所以我们需要将函数和 Dapr 两个进程部署到同一个容器中，然后 Dapr Sidecar 由 Extension 模块进行管理。

在函数计算场景下，最小的实例数可以缩容到0，但是应用开发者为了能够在有流量进来的时候能够快速提供服务，往往会申请一些预留实例，主要是为了解决突发的流量。但是当预留的实例没有流量的时候，函数计算期望能够将资源的消耗降下来，所以函数计算里面提供了一种机制，当某个预留实例很久没有流量的时候，它会让实例进入休眠的状态。

前面讲到了 Dapr 和函数计算的实例是部署在同一个容器的两个进程，那么Dapr当然也需要去进入休眠状态，所以说 Dapr 还需要感知到函数计算进入休眠的状态，然后 Dapr 也进入休眠。

（三）阿里云函数计算：Dapr 方案优化

阿里集团的某些 SaaS 业务随着业务的发展，除了给集团提供服务外，还需要对外进行售卖。但是售卖的过程中客户会提一些诉求，他希望这些 SaaS 的系统能够部署在专有云或者混合云的场景下，而且底层依赖的技术希望是开源的，或者说某些没有厂商绑定的云产品上，所以它的本质是期望将阿里内部的 RPC、Cache、消息、Config 这些东西都切换到 Redis、RocketMq 和 Nacos 上，这种切换可以通过 Dapr 的灵活组件插拔形式来完成。

在集团里面的时候，它声明了内部的 Yaml 文件，当它部署到专有云或混合云场景下的时候，通过指定开源产品的 Yaml 文件，通过指定不同的 Yaml 文件来激活不同的组件。但是这时候应用开发者如果想切到 Dapr 这个体系里面来，它又需要面向 Dapr 的 JAVA SDK 进行编程，但这种方式的成本非常高，它如果有10应用，10个应用都需要切换到 Dapr 的 JAVA SDK 里面来，所以我们给它提供了一种适配的方案，应用还是依赖 JAR包、RPC、Cache、Message 和 Config，然后底层实现里面将它适配到 Dapr 的 JAVA SDK 里面来，这样应用开发者只需要升级 SDK 的版本，而无需做代码的调整。

通过这种方式之后，无论是云上和云下的代码是统一的，不用做任何调整。

（四）SaaS 业务上云

钉钉文档是 SaaS 场景里一个经典的例子，通过中间件团队给它提供的能力，将底层具体的中间件能力进行屏蔽。但是钉钉又想往前再走一步，它期望能将自己的业务组件也集成到 Dapr 的 Component 组件当中。

（五）Dapr 快速入门教程 （阿里云知行实验室）

• Dapr 入门教程 ：https://start.aliyun.com/course?spm=a2ck6.17690074.0.0.503c2e7dMmYFPM&id=gImrX5Aj

感兴趣的同学可以参考入门教程，阿里云咨询实验室里有一些教程。

四、分布式运行时 Dapr 未来展望

（一）基础设施下沉

最后我们来介绍一下 Dapr 的未来的一个展望，软件架构的发展历史极其精彩，回顾阿里巴巴系统架构引进的历史，能了解到国内甚至全球软件架构的发展历史。

淘宝最开始成立的时候是单体应用，最开始的时候是 PHP，然后后面切换成 JAVA。

随着业务的发展，系统首先对硬件进行了升级，是以 Scale Up 的方式完成的，但很快发现这种升级方式遇到了各种各样的问题，所以在 2008 年的时候开始引入了微服务的解决方案。但是 SOA 的解决方案是分布式的，对于稳定性、可观测性等方面有较高的要求，所以在阿里内部又引入了熔断、隔离、全链路监控等高可用的方案。

接下来面临的问题是怎么在机房 IDC 层面能让业务达到 99.99% 以上的可用的 SLA，此时就有了异地多活的解决方案。而随着云原生技术的发展，阿里巴巴拥抱和引导云原生技术发展的决心非常大，开始积极拥抱云原生技术，以 K8s 为基础，积极开展云原生技术相关的升级。

在这个历史中，我们可以发现软件架构的诉求越来越多，需求永无止境，原先底层的基础设施无法完成，只能交给应用层来完成的工作，逐渐在K8s和容器引入之后得到了解决，重新将分布式和微服务相关的能力进行了下沉。

而且，我们相信未来的趋势也是会以 Service Mesh、Dapr 为代表的分布式能力下沉的方式继续往前演进，逐渐释放云和云原生技术的发展红利，未来的应用开发者应该期望能够面向语言无关的、不和具体云厂商和技术进行绑定的开发体验，同时能够享受到云技术带来的红利，做到极致弹性带来的成本优势。

从当前角度出发，如何才能完成这个目标？

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

• Multiple Runtime 能够真正地落地，就像前面讲到了 Dapr 能够真正落地，并且能够持续进行发展。
• 以 Dapr 为代表的面向分布式能力的API能够成为一个行业的标准，而且这个标准能够持续地发展，最好是能够成为一个工业的标准。
• K8s 和 Serverless 的持续发展，能够给云原生技术带来更多的发展红利。

（三）Dapr 社区方向

最后我们来看一下Dapr社区发展的几个方向。

• 推动 API 标准化，同时能够集成更多的分布式能力。
• 更多 Component 集成，Dapr 目前已经集成了 70 多种，期望将来能够集成更多的component，同时这些能力的功能上能够更加完整。
• 希望更多公司能够接受 Multiple Runtime 的理念，积极打磨自己的产品，然后在生产里落地。
• 最后一点是希望 Dapr 能够进入 CNCF，成为 Multiple Runtime 的事实标准。

文章转载地址：https://developer.aliyun.com/article/788126#slide-19

【说明】该文章属于转载，作者（曹胜利）在写作该文章之时（时间：2021-08-24），Dapr 还属于比较早期的一个发展情况，上面文章中提到的一些想法和功能点，目前（2022 年 4 月 11日）发布的正式版 Dapr v1.7.0 版本大部分功能已经实现，并且 Dapr 已经加入 CNCF。
Dapr joins CNCF as an incubating project | Wednesday, November 03, 2021