如何评价微软的微服务构建框架Dapr？

最近 dapr 1.0 正式release，已经达到了生产就绪所需的稳定性和企业准备。

在这个时间节点再来看待Dapr的价值和未来。

Dapr 是一个可移植的，事件驱动的运行时，可以使任何开发人员都可以轻松构建在云和边缘上运行并包含多种语言和开发人员框架的弹性，无状态和有状态的应用程序。

Dapr 本身是一种 Sidecar 模式（虽然Dapr也提供了SDK，但是个人认为这并不是Dapr以后的发展方向）。Sidecar 模式的意义在于， 解耦了基础设施和核心业务。

我曾经回答过关于Service Mesh的的一个问题。以Istio为首的Service Mesh 解决方案也是一种Sidecar 模式，只不过Service Mesh 侧重于网络。而Dapr侧重于业务逻辑。

大家可以自行阅读，加深对Sidecar 模式的理解。

简单来看，Dapr的意义在于：

• 对于小公司，甚至没有基础架构和中间件团队的公司，Dapr 提供了开箱即用的基础设施功能，可以让小公司轻松构建弹性，分布式应用。
• 对于中等单位，具备一定的基础架构能力，在使用Dapr的过程中，可能Dapr并不能完全满足需求，那么也可以在Dapr框架体系下，花费较小的成本进行自定义扩展。
• 对于大公司，Dapr 提供了一种思路。相信基础架构团队会越来越倾向于通过交付Sidecar的形式来提供基础设施。

长远来看，Dapr背后的架构模式是符合未来架构趋势（多运行时架构）和云原生发展趋势的。

通过该图，我们可以清晰看到Dapr的重要性。其中Envoy部分正是代表了Service Mesh。

此外，虽然Dapr支持vm部署，但是kubernetes无疑是最佳的宿主。

Dapr 和 Service Mesh 存在一些交叉的部分。

所以个人觉得，Dapr 和 Service Mesh 解决方案结合，是接下来一个非常重要的方向。

于2021年3月5日补：

最近有人给Envoy社区提交了一个proposal -- 继Lua和Wasm之后，增加Golang作为Envoy 第三种L7 network 扩展方式。

Golang 扩展相比lua，拥有更丰富的生态和各种SDK，相比Wasm，有着更低的内存拷贝和更好的性能。

如果这个proposal一旦被接受，那么这意味着，Dapr的 Golang SDK 可以作为Envoy的filter，完美解决Envoy（Service Mesh）和 Dapr的结合。

大致如下：

今天谈下对为微软开源的Dapr框架的初步理解，实际上对于Dapr去年就经常看到相关的新闻和技术材料，但是由于是微软发布的开源产品一直没有引起我重视，最近又经常看到Dapr这个微服务框架，才仔细去学习了相关的资料。

微软Dapr框架概述

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 实现资源限制，这些都是容器运行时需要提供的实现。

什么是 Distributed Application Runtime

Dapr 所提供的「分布式应用运行时」，是应用程序运行所需分布式能力的实现，这些能力涵盖服务通信、数据持久化、外部 binding，pub-sub 等等。比如服务调用需要有容错重试机制，比如一个数据持久化操作希望使用乐观锁，比如发布消息是要求有投递保证。

长期以来，这些功能的适配都是集成在业务代码里的。dapr 创新之处是将这些功能，从原来 application runtime 中拆分出来，作为一个独立的 runtime。dapr runtime 也满足上面说到的 runtime 的特征。

简单总结就是：

Dapr是一种可移植的，事件驱动的分布式运行时，企业开发者通过它可快速地构建弹性的、有状态或无状态的微服务应用，这些应用可运行在云或边缘，并支持语言与框架的多样性。同时开发人员只需要关注业务功能和逻辑的实现，而对于应用本身的底层高可用性，可靠性和弹性伸缩能力并不需要去关注，而由云原生平台来解决。

Dapr本身是跨语言, 跨框架, 跨环境的。Dapr是平台无关的，这意味着你可以在本地、任何Kubernetes集群以及其他集成Dapr的托管环境中运行，这可以让你的微服务应用运行在云或边缘节点上。使用Dapr，你可以使用任何语言、任何框架构建你的微服务应用，并将它运行在任何环境中。

Dapr架构

Dapr 的设计是典型的分层架构，其核心理念，是利用抽象层来实现应用关注点的分离，用以降低分布式应用的复杂性。在 dapr 的架构中，核心的三个组成部分：

• API
• Building Blocks
• Components

对于这个图，我不准备引用官方文档的一些说明，从Dapr的分层架构上，可以简单地理解为北向接口和能力开放，内部业务组件和逻辑实现，南向底层能力适配三个方面的内容。

对于最上层的API层是最容易理解的，即将内部组件能力发布为API接口服务，既可以是Http Rest API接口，也可以是Rpc接口，而且可以做到灵活发布给前端应用使用。

对于Building Blocks，除了架构图里面谈到的状态管理，资源绑定，发布订阅，可观测性等能力外，更加重点是是和能力绑定在一起的核心业务组件和功能实现。也就是Building Blocks仅仅是核心组件逻辑实现附属的Sidecar能力。核心组件能力如何实现呢？你仍然可以按照传统的编程语言来实现你的核心业务规则和逻辑。

对于Components层，实际是一个关键，核心就是提供和底层云原生基础设施，和边缘端的对接和适配能力。这个能力从最早期的云原生基础设施资源层，进一步抽象到当前主流的PaaS技术服务层，或者理解为前面谈到的Runtime运行时能力对接，典型的就是数据库，中间件，消息，缓存等各种能力对接。

开发模式和API调用

上图实际是对Dapr开发机制的一个关键说明。

既开发人员重点是开发业务功能和逻辑实现，而且整体应用的开发以及从资源层抽象到服务层，既开发人员直接对接的是服务和运行时，而不是自己去安装和配置资源。

你原来需要数据库能力，原来思路是你自己去找到资源并安装配置数据库，而新架构模式下思路是你直接使用数据库服务，在底层数据库资源和功能开发之间通过Components来进行适配，这个适配不仅仅是从资源层到服务层的抽象，更加重要的是可以扩展云原生下多云服务适配能力。

对于API接口的开发和暴露，同样对于组件来讲暴露Rest API接口或RPC，而对于前端应用开发既可以调用标准的Http Rest API接口，也可以在前端应用中下发一个轻量的SDK包作为Sidecar适配，彻底实现前端和后端之间的解耦。

Dapr和ServiceMesh，ServerLess的融合

对于Dapr，个人更加倾向于将其理解为ServiceMesh和ServerLess能力的融合。

Dapr和ServiceMesh在微服务治理里面都是通过Sidecar边车模式来实现。但是可以看到对于ServiceMesh更多是偏微服务治理方面的能力，包括了注册发现，限流熔断，安全，负载均衡等能力，这种能力可以理解为各个微服务之间的横向交付能力。

但是对于Dapr来讲，不仅仅是提供微服务间的横向交付能力，还提供微服务本身在纵向仅资源，服务，接口，前端应用分层后的纵向交互能力。即Dapr提供了完整的分布式运行时能力，这个能力提供既提供了南向对于底层云端资源，边缘端能力的集成和适配；同时又提供标准的API层能力接口和开放，实现和前端功能的集成适配。

再来看下ServerLess无服务器架构。

对于BaaS层后端即服务能力，实际和Dapr架构里面的Components组件层完全对应，即将底层的资源层能力抽象为运行时的服务层能力。

但是对于ServerLess的无服务器架构，BaaS层更多的是类似数据库，消息，缓存，存储，日志等各种技术服务能力。因此常规的云原生平台提供的ServerLess并不适合开发企业级的复杂应用，其核心原因就是共性的领域层业务服务能力无法提供。

那么如何来解决这个问题？

简单来讲就是ServerLess的架构思路，仍然需要和微服务架构进一步融合。既借鉴ServerLess的资源重新，分层解耦的核心架构思路，同时又借鉴传统的微服务架构框架，基于传统方法来开发能够提供核心业务服务能力的业务组件。

这个业务组件你完全可以采用传统的开发语言，开发方式进行开发。但是开发完成后仍然需要融合到整个云原生和微服务架构体系里面去。也正是整个原因，我们完全可以理解为Dapr是微服务，服务网关，无服务器化三者核心思想的一个融合，这也正是整个云原生下微服务框架发展的趋势。

大家可以参考下图进行理解：

简单来讲就是开发人员只需要关心BaaS层业务组件微服务的开发，其它和底层资源和技术服务的集成和适配，API接口的能力开放，微服务组件之间的交互，微服务本身的服务治理和可观测性问题全部由Dapr框架来完成。

Dapr框架实际是融合了ServiceMesh服务网关和ServerLess无服务器化两者的核心思想，真正实现了让开发人员从技术基础设施和底层资源逻辑，服务治理管控中脱离出来。

Dapr符合云原生和微服务发展演进趋势

在我前面谈云原生和DevOps的文章中谈到，希望基于DevOps持续集成和交付能力来构建一个多云适配的能力平台。即你在私有云环境中开发完成的应用，能够灵活的朝不同的公有云服务商进行交付，也能够灵活的在多个公有云之间进行迁移。

当我在谈这个问题的时候，实际重点仍然是基于公有云服务的资源层虚拟机或者基于公有云提供的标准Kurbernetes API接口层对接容器能力。

但是对于核心的PaaS层数据库，消息中间件，缓存，日志等各种技术服务能力并无法支撑。也就是说如果你用的阿里云的RocketMQ消息中间件，你如何迁移到华为云？或者即使你用的阿里云的Mysql数据库即服务能力？你如何保证一定可以平滑迁移到华为云的Mysql数据库服务上面去？

因此，这种和公有云的适配不是简单的资源层包括容器层的适配，更加重要的是各种技术服务能力的适配，这些技术服务能力可以理解为ServerLess无服务器架构中的BaaS层能力。

这种适配在哪里做？

按Dapr的思路，我们可以在Components组件层来完成这种适配工作。

当开发人员在开发新的应用的时候，只需要使用Dapr架构框架下的数据库，消息等API接口能力，同时又确保你开发的应用能够平滑的向云端的云原生架构进行快速交付。也不会被某个单一的云服务商强制绑定。

包括我在前面谈ServerLess架构演进的时候也谈到，简单的BaaS+FaaS无法支撑复杂的企业级应用开发，对于企业级应核心仍然是业务BaaS层的开发，并将能力通过API接口方式暴露给前端应用。

但是业务BaaS层业务组件和服务的开发同样需要使用类似消息，缓存等各种技术BaaS层服务能力，技术BaaS+业务BaaS才构成完成的底层服务层能力提供。

因此我们需要找到一种方式或架构框架，同时满足对业务BaaS微服务的开发定制，从资源到服务层能力的抽象和适配，通过边车模式实现的微服务治理管控，基于API接口服务实现的前后端分层和能力解耦。

而对于Dapr框架本身具备上述大部分能力，这也是我们将Dapr架构和框架实现思路是后续云原生和微服务架构发现的关键趋势的原因。当然你也可以不使用Dapr框架，那么你自己在进行类似SpringCLoud微服务框架，Istio服务治理，ServerLess架构融合的时候，也需要基于上述的关键思路展开。