最近 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的结合。
大致如下：
