Dapr简介

Dapr是什么？

直接看下面这张图：

上图一共有3层，从上往下：

• Application Code：应用程序，就是你写的业务系统应用；这里体现了Dapr支持多语言；Application Code通过HTTP/gRPC协议和Dapr通信；

• Dapr：Dapr运行时，可以看出Dapr提供了服务间调用、状态管理（key/value管理）、发布订阅（MQ）等能力

• Any cloud or edge infrastructur：服务提供者，且是多云的。

来个例子吧：

上图使用了Dapr的state management能力，由Redis提供真正的状态存储服务。

• Order Processor：即业务系统应用，通过HTTP发起一个请求，要存储一个key为527的数据；

• Dapr：收到上面的请求，再转发给Redis；

• Redis：存储key/value

看了上面的图，你是不是会想：那我为啥不直接用Redis？接着往下看

Dapr能解决什么问题？

为什么不直接使用Redis？

如上面的Redis的例子，如果应用系统（上面是Order Processor）直接使用Redis，那应用系统就强依赖Redis了，如果应用系统要换成其它缓存数据库，如Memcached等，就需要改造应用系统的代码。

但如何使用了Dapr，应用系统通过通用的HTTP/gRPC协议和Dapr交互，再由Dapr和Redis交互。通过加入中间的Dapr，实现了应用系统和Redis的解耦；如果后续由Redis替换为Memcached，只需要修改Dapr的配置，应用系统无需改造。

Dapr的优势

• 应用系统与具体服务解耦：通过轻量级SDK、通用HTTP/gRPC协议、与服务无关的API，实现应用系统与具体服务的解耦；

• 易维护：Dapr通过Sidecar机制，将Dapr进程和应用系统进程隔离，Dapr对应用系统是透明的，Dapr的升级也是对应用系统无感的；

• 天然支持多语言：由于SDK是轻量级的，即只提供HTTP/gRPC协议的API接口，所以很方便通过多语言实现；

• 多云支持：应用系统与具体服务解耦后，服务的具体实现只由Dapr关心，应用系统在云环境之间迁移时，无需关心具体云之间的差异；

Dapr特性

Component

即组件，Dapr官方提供了很多内置的组件，如下图：

例如State Stores状态存储类，最简单就是key/value存储。实现的方式有Redis、Cassandra等

Building Blocks