2周前 (04-25)  相关技术 |   抢沙发  11 
文章评分 0 次,平均分 0.0
[收起] 文章目录

随着最近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与Service Mesh服务网格的区别

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

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

 

除特别注明外,本站所有文章均为老K的Java博客原创,转载请注明出处来自https://javakk.com/1854.html

关于

发表评论

表情 格式

暂无评论

登录

忘记密码 ?

切换登录

注册