如何评价微软的微服务构建框架 Dapr ？
跟时下主流的Serverless/FaaS框架相比呢？
最近 dapr 1.0 正式release，已经达到了生产就绪所需的稳定性和企业准备。
在这个时间节点再来看待Dapr的价值和未来。
Dapr 是一个可移植的，事件驱动的运行时，可以使任何开发人员都可以轻松构建在云和边缘上运行并包含多种语言和开发人员框架的弹性，无状态和有状态的应用程序。
Dapr 本身是一种 Sidecar 模式（虽然Dapr也提供了SDK，但是个人认为这并不是Dapr以后的发展方向）。Sidecar 模式的意义在于， 解耦了基础设施和核心业务。
我曾经回答过关于Service Mesh的的一个问题。以Istio为首的Service Mesh 解决方案也是一种Sidecar 模式，只不过Service Mesh 侧重于网络。而Dapr侧重于业务逻辑。
如何看待Service Mesh的前景？
新一代的微服务框架ServiceMesh（Istio, nginmesh, Linkerd等）的适用场景有哪些，如何看待他的前景？
首先需要明白，现在承载我们应用工作负载的形式已经从”物理机“过渡到”容器“了。
”物理机“，不仅仅包含物理机，而且包含缺乏高度自动化和弹性的VM。
”容器“，除了容器，还包括创建（包括初始化）和销毁高度自动化，具备极强弹性的VM。比如公有云提供的VM。
这里我们需要明白：基础设施的功能（服务发现，负载均衡，熔断限流，路由等）与 业务代码的集成需要在低成本前提下保证相同的生命周期。
在物理机时代，基础设施功能添加到业务代码的最佳方式无疑是SDK。
而容器时代，基础设施的功能添加到业务代码的最佳方式变成了Sidecar。
Sidecar 模式， 解耦了基础设施和核心业务。
而 Service Mesh 正是在容器时代，通过Sidecar模式，提供的微服务解决方案。
Service Mesh 通常是通过为每个服务实例提供一个称为sidecar的代理实例来实现的。Sidecar处理服务间通信，可观察性和与安全有关的问题--实际上，任何可以从单个服务中抽象出来的东西。
这样，开发人员可以专注处理服务中应用程序代码的开发，支持和维护。基础架构团队可以专注维护基础设施功能。
所以我们可以这么说：时代选择了Service Mesh。以 Istio 为代表的 Service Mesh 是我们在容器时代采用微服务架构的最佳实践。
=================================================================================================================
作者：网易数帆
链接：https://www.zhihu.com/question/265060457/answer/837838179
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
作为处理服务与服务之间的通信的专用基础设施层，Service Mesh：
- 微服务化诉求下，是解决传统微服务框架短板的杀手锏；
- 中台建设诉求下，是统一异构业务、实现能力复用的曙光。
传统微服务框架存在的挑战：
- 大型企业或多或少都有统一技术栈的需求，即便都是 Java 业务，所采用的技术栈也有 Dubbo、Spring Cloud 以及自研RPC框架之分。
- 有的老的业务采用 .Net、C++ 或者其他语言，需要和新的 Java 业务整合，难度很大。
- 从架构上看，中台是一种基础设施的下沉，而微服务框架也是一种不彻底的下沉，因为它还是在业务开发代码里面的。
- 这种对业务的侵入性，也造成了服务框架升级的困难。
Service Mesh 之所以被看好，主要有4个原因：
- 它是一个独立的进程，和业务是解耦的，对业务代码无侵入；
- 具备跨语言特性，Dubbo 和 Spring Cloud 其实都是 Java 技术栈，而 Service Mesh 具备整合一些 C++、Golang 之类的异构语言应用的能力，因为它没有进入到进程内；
- 它提供了丰富的微服务服务治理功能；
- 它可以解决中台架构下微服务化存在的问题。
Service Mesh 在业界有一些原生的开源方案，但这些方案还存在一些问题：
- 到目前为止，社区版本还有一些性能方面的问题；
- 它的稳定性和产品化还有待验证，真实落地的产品和企业还是非常少的；
- 它有一定技术门槛，企业如果直接使用开源版本的话成本还是比较高的，概念非常多，而且还需要懂容器、Kubernetes 和一些服务治理相关的东西。
网易轻舟微服务团队很早就认识到了 Service Mesh 架构的先进性，并开始探索 Service Mesh 在网易业务场景中的应用，例如轻舟团队与严选团队合作，基于轻舟实现了严选第二代 Service Mesh 的重大升级。
=================================================================================================================
大家可以自行阅读，加深对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的结合。
大致如下：
作者：iyacontrol
链接：https://www.zhihu.com/question/351298264/answer/1737380230
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。