Intro
Dapr 官方团队已于最近（2021.1.17）正式发布Dapr v1.0，Dapr已正式生产可用，可以部署到自托管环境或 Kubernetes 集群。对于绝大多数开发者来说，想必对Dapr只是有所耳闻，而具体是什么（What），可以解决什么样的问题（Why&How），有怎样的应用场景（Where），并不知悉。本文就尝试简要梳理下Dapr，并尝试回答以上问题。
What's Dapr
Distributed Application Runtime. An event-driven, portable runtime for building microservices on cloud and edge.
分布式应用运行时。一个事件驱动、可移植的运行时用于在云上和边缘计算上构建微服务。
以上是Dapr官方GitHub仓库上对Dapr的简介。文字虽短，口气却很大，因为其除了涵盖了当前所有的技术热点：分布式、云、微服务，还自我标榜为：
分布式应用运行时
。分布式应用我们或多或少有些了解，运行时也听到不少，比如常见的语言运行时：Java 运行时，.NET 运行时，Go 运行时等等，那运行时又是什么东西？简要来说：运行时是程序运行依赖的执行环境。以.NET 程序运行时CLR为例，它为.NET应用程序提供了一个托管的代码执行环境负责应用程序在整个执行期间的内存管理、线程管理、安全管理、远程管理、即时编译等。
那分布式应用运行时，就是提供分布式应用运行所依赖的的执行环境。那运行分布式应用需要哪些环境依赖呢？回答这个问题，我们要先思考开发分布式应用的挑战是什么？明确了挑战，那就找到了答案。
从单机到分布式，是追求更快和更高的性能，但也带来了更多的不确定性。比如，不确定计算机何时异常，不确定磁盘何时损坏，不确定网络通信的延迟，也不确定消息是否被正常消费。这些不确定性构成了分布式应用的挑战，简而言之：
面对这些挑战，业界提出了诸多的分布式理论、协议，如CAP定理，BASE理论，一致性协议2PC/3PC/ZAB，来保证系统的正常运行。虽然问题貌似是有了解决方案，但是应用的复杂度升高了。应用除了需要实现业务需求，还要兼顾非业务需求，集成诸如服务发现、负载均衡、失效转移、动态扩容、数据分片、调用链路监控等分布式系统的核心功能，对应用有很强的
侵入性
，这就是以Spring Cloud为代表的微服务框架的常见做法。
那如何解决侵入性的问题呢？这个问题随着容器编排技术的成熟有了新的解法。Kubernetes可以不侵入应用层，在容器层解决问题，比如K8S Service就具有服务发现、负载均衡的能力，HPA具有动态扩容的能力。随着K8S的快速发展，云原生的概念，也就越来越深入人心，那如何利用好K8S提供的基座能力，将更多的分布式能力下沉，让应用开发回归业务呢？
其中Service Mesh提出的Sidecar模式，就很好的解决了微服务架构中网络通信的问题
。Sidecar主要就是用来处理诸如服务发现、负载均衡、请求熔断等一系列非业务需求，应用在部署时动态插入Sidecar，服务间的通信通过Sidecar进行代理，以完成对服务间网络通信的接管。
到这里，微服务开发在Service Mesh的帮助下，已经渐渐回归业务本身，让更多的开发者看到了一丝曙光。It's enough? 来看下Bilgin Ibryam在Multi-Runtime Microservices Architecture文章中提及的分布式应用的四大需求：
分布式应用的四大需求
从上图可以看出，除了网络（Networking）外，生命周期（Lifecycle）、状态（State）、捆绑（Binding）也是分布式应用要解决的问题之一。网络问题可以借由Service Mesh 比如Istio予以解决。那其他三个该如何解决呢？又要应用自行开发集成吗？显然不符合应用回归业务本身的诉求。这时，Dapr登场了，Dapr提出的分布式应用运行时就是实现了以上四个需求并将其下沉作为分布式应用的运行环境。
简而言之：
Dapr将分布式能力进行封装下沉作为运行时以简化分布式应用开发的技术复杂度。
How Dapr Works
那Dapr如何简化分布式应用的开发呢？下面我们来看一看Dapr的主要特性。
其中Dapr的核心构建块（Building Block）就是用来提供各种不同的分布式能力，我们来分别看一看。
1. Service-to-service invocation（服务调用）
提到跨服务方法调用，这个大家肯定会想，这简单啊，不就是服务暴露API就好了嘛。是，但不完全是。比如nodeapp暴露了一个API：
http://10.0.0.2:8000/neworder
，按照传统的方式，直接HTTP POST这个API访问就得了，但在Dapr中，其提供了服务间方法调用的接口规范，需要按照
POST/GET/PUT/DELETE http://localhost:
/v1.0/invoke/
/method/
的格式进行访问。那假设pythonapp需要访问nodeapp的方法，就需要POST一个请求到
http://localhost:3500/v1.0/invoke/nodeapp/method/neworder
。你可能会想为何多此一举呢？此举的意义何在呢？目的很简单，就是为了实现对服务间网络通信的控制以完成诸如服务发现、流量控制、重试熔断、安全访问等，而这相关的网络控制功能就是集成在Dapr的Sidecar中，以对应用透明的方式集成进来的。整体的服务调用流程如下图所示：
PS：如果对Istio熟悉的同学需要注意，二者虽然都是通过Sidecar的模式进行网络控制，但二者是有有区别的。Dapr是以API的方式，而Istio是以代理的方式（不改变HTTP请求URI)。
2. State management（状态管理）
在进行微服务开发时，绕不开的话题就是服务间的状态共享、并发一致性问题。对于状态共享，你可能会说，各个服务连接到同一个Redis实例就OK了。是，但不得不考虑潜在的更新冲突的问题。Dapr 以更友好的HTTP API的方式进行状态的存储和读取，同时支持通过ETags进行并发控制，并支持通过选项设置并发和一致性行为。
存储：
POST http://localhost:
/v1.0/state/
读取：
GET http://localhost:
/v1.0/state/
/
删除：
DELETE http://localhost:
/v1.0/state/
/
以下是保存状态的举例：
