最近公告那Dapr已经达到了它的第一个生产准备发布，我们终于看到了一个可行的回应Istio，也许其他服务网格行业来自微软。如果您不熟悉，Dapr是一个旨在解决现代分布式应用程序挑战的编码框架。您可能会问，“但这不是服务网格的用途吗?”是的，除了服务网格焦点错误．他们关注网络基础设施问题;Dapr专注于开发人员构建微服务所需的东西。这种转变可能是行业解决分布式架构问题所需要的。

分布式架构的问题

当你的应用程序从一个庞然大物升级到微服务时，你牺牲了调用堆栈的稳定性，换来了网络的混乱和不安全。手工编写所有需要处理的事情，但不具有可伸缩性:这很麻烦，而且容易出现人为错误。服务网格已经成为解决这个问题的一种手段，但它们受到两个问题的限制:

  1. 许多供应商从网络运营的角度来看待这个问题，但其实这个问题是软件开发和架构的问题。把它看作纯粹的网络问题，就像把动态库链接看作纯粹的磁盘I/O问题一样。动态库链接需要解决一个开发问题，而不仅仅是从磁盘加载DLL或JAR文件;同样，分布式体系结构不仅仅是一个网络问题。
  2. 服务网格可能很复杂，尤其是Istio。为了支持服务网格，开发人员需要将其外包给I&O团队，或者他们自己需要成为I&O专家来支持网格。前者破坏了微服务的一个关键目的:自治团队可以快速移动，对其他团队的依赖最小。后者破坏了网格的目的:将开发人员从基础设施中解放出来，只关注业务逻辑。

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

Dapr Vs.服务网格

下面是我放在一起的一个图表，以给出重叠的概念。分布式跟踪跨越了这条线，因为在网络层之上使Dapr可以做更多的事情。服务网格只能跟踪HTTP连接;通过事件消息代理的事务对其跟踪是不可见的。由于位于网络层之上，Dapr可以通过两个HTTP服务调用进行跟踪而且事件消息代理。

Dapr包括状态管理、秘密管理、事件绑定和触发器、参与者以及发布和订阅。业务mesh包括内容过滤、流量分流和高级流量路由。两者都包含服务发现、mTLS、度量、重试、负载平衡和分布式跟踪，尽管分布式跟踪在Dapr中更强。Dapr的功能令人兴奋。开发人员为什么要关心服务网格特有的特性?

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

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