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

ServiceMesh的Sidecar接收到是App发出的原生协议的请求，然后转发给另一端的Sidecar进而转发给目标App；或者，对于Redis/Kafka等的支持是Sidecar将原协议转发给Redis/Kafka服务器。在这个过程中， ServiceMesh的Sidecar原则上不修改协议，只做转发（"Forwarding"）， Sidecar扮演的是代理（"Proxy"）的角色。
而Dapr的工作模式是能力抽象：

文章图片
DaprSidecar接收到是App发出的遵从标准API的请求，这些标准API对能力进行了抽象；对于服务间通讯的场景， DaprSidecar会将请求转发给另一端的DaprSidecar；对于服务间通讯之外的能力的支持则需要将标准API转换为底层组件对应的原生协议。在这个过程中， DaprSidecar原则上对应用只暴露抽象之后的分布式能力，屏蔽了底层具体的实现和通讯协议，不做"转发"而是提供"能力" ， DaprSidecar扮演的是运行时("Runtime")的角色。
工作模式不同的背后，反映出Dapr和ServiceMesh在设计目标上的差异：
ServiceMesh的主要设计目标是低侵入，采用原协议转发的方式可以尽可能的降低对应用的侵入，为了达到无侵入的目标甚至采用了流量劫持的方式。
Dapr的主要设计目标是可移植性，即在跨云跨平台的前提下实现无厂商绑定，采用的方式是在将分布式能力抽象为标准API ，并在各种开源项目和云平台上提供这套标准API的不同实现，从而达到在不同平台上运行的目标，这即Dapr愿景中的"anywhere" 。
总结一下Dapr和ServiceMesh的差异以及适用场景：ServiceMesh强调对应用无侵入，支持原协议转发和流量劫持，不仅仅适用于新应用，相比Dapr也更加适用于老应用。而Dapr提供"标准API"、"语言SDK"和"Runtime" ，需要应用进行适配（这意味着老应用需要进行改造），侵入性比较大。因此Dapr更适合新应用开发（所谓GreenField），对于现有的老应用（所谓BrownField）则需要付出较高的改造代价。但在付出这些代价之后， Dapr就可以提供跨云跨平台的可移植性，这是Dapr的核心价值之一。
因此，在决策是否该采用Dapr时，可移植性是一个非常关键的考虑因素。
死生之地：API标准化的价值
在上一篇文章Daprv1.0展望：从ServiceMesh到云原生中，我曾经指出：Dapr的本质是面向云原生应用的分布式能力抽象层：

文章图片
可移植性是Dapr的重要目标和核心价值。 Dapr的愿景， "anylanguage,anyframework,anywhere" ，这里的anywhere包括公有云、私有云、混合云和边缘网络。
而Dapr可移植性的基石在于标准API+可拔插可替换的组件，下面这张来自Dapr官方网站的图片非常形象的展示了Dapr的这一特性：

文章图片
从架构设计的角度看， Dapr的精髓在于：通过抽象/隔离/可替换，解耦能力和实现，从而实现可移植性。

文章图片
在传统的应用开发方式中，应用需要面向具体的实现编程，即当应用需要使用到某个能力时，就需要找到能提供该能力的底层组件，如上图中的Redis/Consul/Memcached/Zookeeper都可以提供分布式状态的存储能力。应用在选择具体组件之后，就需要针对该组件进行编程开发，典型如引入该组件的客户端SDK ，然后基于这些SDK实现需要的分布式能力，如缓存、状态、锁、消息通讯等具体功能。
而在Dapr中， Dapr倡导"面向能力编程"：DaprAPI提供了对分布式能力的抽象，并提取为标准API；Dapr的Runtime隔离应用和底层组件的具体实现;而这些组件都是可替换的，可以在运行时才进行绑定。