死生之地不可不察：论API标准化对Dapr的重要性

作者|敖小剑
Dapr作为新兴的云原生项目，以"应用运行时"之名围绕云原生应用的各种分布式需求，致力于打造一个通用而可移植的抽象能力层。这个愿景有着令人兴奋而向往的美好前景，然而事情往往没这么简单， API的标准化之路异常的艰辛而痛苦， Dapr的分布式能力抽象在实践中会遇到各种挑战和困扰。
快速回顾：什么是Dapr？
Dapr的全称是"DistributedApplicationRuntime" ，即"分布式应用运行时" ，是一个由微软发起的开源项目，目前已经进入CNCF孵化器。
我们首先来对Dapr进行一个简单的介绍。首先来看ServiceMesh ，和传统RPC框架相比， ServiceMesh的创新之处在于引入了Sidecar模式：

文章图片
而ServiceMesh只解决了服务间通讯的需求，而现实中的分布式应用存在更多的需求， Multi-Runtime理论将这些需求归结为四大类：

文章图片
在ServiceMesh初步成功并且Sidecar模式被云原生社区普遍接受之后，各企业效仿ServiceMesh将应用需要的其他分布式能力外移到各种Runtime ，这逐渐演变成了一个趋势。这些Runtime会逐渐整合，最后和应用Runtime共同组成微服务，形成所谓的"Multi-Runtime"架构，又称Mecha：

文章图片
Dapr项目是目前业界第一个Multi-Runtime/Mecha实践项目，下图来自Dapr官方，比较完善的概括了Dapr的能力和层次架构：

文章图片
本质差异：DaprvsServiceMesh
在快速回顾完Dapr之后，我们来正式展开本文的内容。首先需要回答这样一个问题：Dapr和ServiceMesh有什么区别？
这个问题也是大多数读者在了解Dapr之后最常问到的一个问题，原因是Dapr和ServiceMesh在架构上实在太像了，都是以Sidecar模式为核心。

文章图片
Dapr的基本思路也是和ServiceMesh保持一致：通过引入sidecar来实现关注点分离+独立维护。

文章图片
Dapr和ServiceMesh最明显的不同之处是Dapr的场景比ServiceMesh要复杂:
ServiceMesh关注于服务间通讯，即下图中虚线部分；而Dapr除了服务间通讯之外，还适用于诸多其他的场景，如状态存储、消息的发布订阅、资源绑定、配置等。

文章图片
下图是Dapr目前已有的构建块，以及对他们所提供的能力的简单描述（其中ServiceInvocation对应ServiceMesh的服务间通讯能力）：

文章图片
功能的差异是很直白的，容易理解。但是，如果只是功能上的差异，那么问题来了：如果ServiceMesh也提供同样的能力，是不是就和Dapr一样了？
我们来看Envoy的功能， Envoy原生支持HTTP1.1/REST和HTTP2/gRPC协议，社区增加了对Dubbo、Thrift等RPC协议的支持，而Envoy也在提供对Kafka、Redis等原生协议的支持，未来Envoy提供更多原生协议支持也是可以预期的。那是不是意味着随着功能的增加，以Envoy、Istio为代表的ServiceMesh就和Dapr一样了呢？
答案当然是否定的——Dapr和ServiceMesh的本质差异在于其工作模式。 ServiceMesh的工作模式是原协议转发：

文章图片