随着云原生技术的发展进入快车道，Service Mesh架构在国内各大公司的布道下已经作为公认的下一代服务治理平台，当Mesh化技术在如火如荼的进行实践落地的时候，业界内又逐渐喊出了“将Mesh进行到底”的口号，现在已经面世的几款优秀的Servcie Mesh产品主流定位大多是通讯层的透明代理，在网络层面解决问题，“将Mesh进行到底”却不仅仅局限于此。随着Dapr的发布，新一代Service Mesh架构的发展方向逐渐开始走进大家的视野。
为铺垫后续，简单介绍Service Mesh背景
如果用一句话来形容什么是Service Mesh，Buoyant公司的CEO William Morgan是这样解释的：“Service Mesh是通过在平台层而不是应用层中增加应用程序的可观察性、安全性和可靠性功能的工具“。
随着微服务架构的普及，现代应用程序通常被设计成微服务的分布式集合，每个服务执行一些离散的业务功能，多数以SDK的模式与业务代码集成，但随着架构的逐渐深化，该模式的缺点也逐渐暴露，比如每次SDK升级都必须重新编译和重新部署每个应用程序，对于不同语言的应用程序都必须开发一套与之相匹配的SDK库，在此背景下，Service Mesh架构应运而生。
Service Mesh天生具备业务隔离和多语言支持的特点，Service Mesh通常由可扩展的网络代理实现，这些代理部署在应用程序代码旁边（称之为边车），这些代理处理应用之间的通信，代理部分称为Service Mesh的数据平面，而通常会存在控制平面控制所有的数据平面，所有边车联系在一起，就是Service Mesh。
Dapr于2019年在微软问世，并于2019年发布1.0里程碑版本，同年加入CNCF孵化器，Dapr在云原生社区中热度也很高，成立了Dapr Sig，吸引了大量developer和contributor；
Cloud Native Computing Foundation，云原生计算基金会（以下简称CNCF）是一个开源软件基金会，它致力于云原生（Cloud Native）技术的普及和可持续发展。云原生技术是通过一系列的软件、规范和标准帮助企业和组织。
Multi-Runtime（运行时）架构是一种未来架构趋势，Dapr便是基于此架构，从需求出发，分布式应用的主要需求包括以下四大类：
- 生命周期：主要是弹性伸缩和异常快速恢复的诉求
- 网络：可靠的网络、可靠的路由的需求
- 状态：对于服务编排、服务调度、状态管理等需求
- 绑定：与外部系统、中间件的通讯的需求
Service Mesh架构将网络层抽出为独立的边车进程，而参考Service Mesh架构，Multi-Runtime架构则是把各种边车提供的能力统一抽象成若干个Runtime，这样应用从面向基础组件开发就演变成了面向各种分布式能力开发。
Service Mesh的发展为我们指明了一个发展方向：将SDK中的分布式能力外移到独立的Sidecar中。但是我们可以想象一下，在未来是否可以将我们现在集成的中间件能力也外移到独立的Sidecar中呢？比如说将数据库Mesh化、将消息中间件Mesh化、将缓存Mesh化，将除了业务代码程序的SDK全部都Mesh化。
我们可以将这些独立出来的Mesh化模块统称为提供不同功能的“运行时”组件。
过多的“运行时”组件出现之后，应用程序在运行时就会依赖一个或多个这样的Mesh化模块。虽然做到了将SDK移出了应用程序，但是这种多依赖的结果显然不是我们所期望的形式。
Dapr的出现将这些提供不同分布式能力以及中间件能力的“运行时”模块进行了整合，开发人员可以按照自己的需求，通过yaml文件的方式，将提供不同的组件整合到Dapr的构建块（Building Block）中。应用程序可以通过Dapr提供的标准API，访问构建块来获得并使用这些能力。
Dapr的这种模式极大的提升了Service Mesh体系中Sidecar的灵活性，并对各种不同的Mesh进行了统一的整合。可以说Dapr的这种模式是未来Service Mesh未来发展的一种新方向。
虽然Dapr 和Service Mesh在架构上都是使用的Sidecar模式，并且在功能上也存在一些重叠部分，但是不能将 Dapr 简单的定义为Service Mesh。 通过上面的讲解，我们可以明白，Service Mesh主要专注于服务调用和网络问题，而Dapr 是为了给应用服务提供更多的分布式能力而诞生的，两者的关注点在本质上就不一样。
Service Mesh主要以基础设施为中心：
（1）Service Mesh更加聚焦于网络问题的处理，通过拦截网络流量，可以使应用程序无感知的部署在包含Service Mesh的环境中。
（2）并且Service Mesh主要由系统操作员进行管理和部署，使Service Mesh更像是一种特殊的“基础设施”。开发人员无需考虑一些其他的细节，因为Service Mesh已经将网络概念扁平化。
（3）Service Mesh通过按照原协议转发的方式来进行流量拦截，可以给业务系统带来零侵入的体验。
与Service Mesh不同，Dapr是以开发人员为中心：
（1）当开发人员在代码中需要使某种分布式能力时，开发人员需要明确调用Dapr API。Dapr为开发者提供了标准的分布式API，这种API带来了多语言的、面向能力的、统一的编程体验。
（2）Dapr提供了应用级别的构建块（Building Block）和70多种分布式能力的抽象集成，使得开发人员更容易将应用程序构建为弹性的微服务。
（3） Dapr通过采用多语言SDK+标准API+各种分布式能力的方式为应用程序提供服务。
Dapr与Service Mesh虽然有异同点，具体选择哪种技术还是要取决于具体的需求。可以只选择两者中的某一种，也可以两者全部使用，同时使用它们是没有任何限制的。
Dapr为开发者提供了标准的API，这种API带来了支持多语言的、面向能力的、统一的编程体验。
Dapr目前仍处于不断迭代升级的状态，虽然社区的关注度很高，但是在将面向能力的API标准化并能持续发展的方向上Dapr还需要继续努力，在我们的调研实践中，我们总结了以下几个方面的期望和诉求：
（一）易用性
-
控制平面的建设，在目前的Dapr社区发展上来看，Dapr仅支持在每个Dapr实例上进行配置，维护成本较高，参考业界Istio、Linkerd等开源框架建设控制平面，对所有配置进行统一纳管，统一下发。
-
异地多活的解决方案，目前Dapr仅支持但k8s集群或虚拟机部署，暂时不能感知多集群、多机房环境，异地多活的解决方案目前处于缺失状态，我们期望Dapr社区能提出解决方案，这也是Dapr成熟落地不可或缺的一步。
（二）可靠性
- 逃生模式，其实对于所有Service Mesh架构的组件都有类似的需求，当Dapr处于异常情况下，如何尽快恢复业务应该也是落地Dapr必须考虑的问题之一。
（三）可扩展性
- 目前Dapr已经对接业界大多数开源中间件和支持常见的Rpc协议，但很多公司都存在自研Rpc协议或自研中间件的情况，我们期望Dapr能提供一套成熟的插件式开发框架，满足各类用户的个性化需求。
在如今这个云原生技术蓬勃发展的时代，以Service Mesh和Dapr为代表的将分布式能力持续下沉的技术还将会继续向前演进。k8s、Serverless等云原生技术的发展，相信也会带动越来越多的公司进行云原生技术的转型，也会有更多的优秀产品在生产上进行落地。
拥抱云原生，我们需要一同努力探索。