Dapr与Service Mesh服务网格的区别

随着最近Dapr发布的第一个产品版本的发布，我们终于看到了对Istio的一个可行的回应，也许还有来自微软的其他服务网格行业。如果您不熟悉，Dapr是一个旨在解决现代分布式应用程序挑战的编码框架。您可能会问，“但这不就是service mesh服务网格的用途吗？“是的，只是服务网格的焦点不对。他们关注的是网络基础设施问题；Dapr关注的是开发人员构建微服务所需的内容。这种转变可能是业界解决分布式体系结构问题所需要的。

分布式体系结构问题

当你的应用程序从一个单一的现代化到微型服务时，你用调用栈的稳定性来换取网络的混乱和不安全。手工编码所有需要处理的事情都无法扩展：这很麻烦，而且容易出现人为错误。服务网格作为解决这个问题的一种手段已经兴起，但它们受到两个问题的限制：

许多供应商从网络运营的角度来看待这个问题，但问题是软件开发和体系结构的问题。将其视为纯粹的网络问题就像将动态库链接视为纯粹的磁盘I/O问题一样。动态库链接需要解决的开发问题远不止从磁盘加载DLL或JAR文件；同样，分布式体系结构也不仅仅是一个网络问题。

服务网格service mesh可能很复杂，尤其是Istio。为了支持服务网格，开发人员需要将其外包给I&O团队，或者他们需要成为I&O专家来支持网格。前者挫败了微服务的一个关键目的：自主的团队，他们可以在对其他团队依赖最小的情况下快速行动。后者挫败了mesh的目的：将开发人员从基础设施中解放出来，只关注业务逻辑。

Dapr遵循服务网格的sidecar模型，但其抽象存在于七层网络栈之上的应用程序代码层。尽管上述混沌网络是分布式开发人员最关心的问题，但它并不是分布式体系结构的唯一问题。其他问题包括管理状态、在微服务之间发布消息以及通过事件绑定触发事件。服务网格由于存在于网络层，无法解决这些问题。因为它位于应用程序代码层，Dapr通过抽象出那些编码模式所需的基础结构关注点来解决这些问题。除了加速交付，它还应该增加云的可移植性。需要从Amazon Web服务迁移到Azure吗？将状态管理的YAML配置从DynamoDB更改为CosmosDB。现在，在没有任何代码更改的情况下，您的微服务将其状态保持在CosmosDB中。

Dapr与Service Mesh的区别

下面是一个图表，我放在一起给一个重叠的想法。分布式跟踪跨越了这条线，因为位于网络层之上使Dapr能够做更多的事情。服务网格只能跟踪HTTP连接；流经事件消息代理的事务对其跟踪是不可见的。位于网络层之上使Dapr能够跟踪HTTP服务调用和事件消息代理。

作为一名开发人员，我发现蓝色盒子里的东西比绿色盒子里的东西更令人兴奋。为什么我要关心底部的东西是唯一的服务网格？

Dapr在我看来是对将业务逻辑转换到底层基础设施的复杂性的正确回应。我们可能最终找到了一个正确的服务网格，讽刺的是，它不是一个服务网格。服务mesh供应商会在网络层上与Dapr竞争吗？或者他们会停止试图解决基础设施层的开发问题，转而专注于成为下一代虚拟网络吗？服务网格供应商需要做出决定。