• 原文地址：Why the Service Mesh Should Fade Out of Sight
  • 原文作者：David Mooter
  • 译文出自：翻译方案
  • 本文永久链接：github.com/xitu/gold-m…
  • 译者：nettee
  • 校对者：PassionPenguin、1autodidact

为什么 Service Mesh 应该淡出人们的视界

image.png

Service Mesh 越来越受到人们的重视，而很多软件开发与交付的专家在初次接触到 Service Mesh 的时分，会搞不清楚它与 API 网关的差异。Service Mesh 究竟是自成一类产品，仍是归于广义的 API 管理的一部分？这些问题并没有捉住要点，因为 Service Mesh 需求逐步淡入成为后端开发渠道的一部分。

要理解为什么这么说，咱们首要需求理解正悄然发生在 Kubernetes 上的变革。简略来说，Kubernetes 将成为一个支撑分布式应用的分布式操作系统：

  • 传统的操作系统管理核算机的资源，为程序员供给更高等级的笼统，使其能够与杂乱的底层硬件进行交互。操作系统的出现是为了处理人工编码直接与硬件进行交互所遇到的困难。
  • Kubernetes 管理核算机集群的资源，为程序员供给更高等级的笼统，使其能够与杂乱的底层硬件以及不稳定、不安全的网络进行交互。Kubernetes 的出现是为了处理人工编码直接与硬件集群进行交互所遇到的挑战。虽然按操作系统的规范来看，Kubernetes 还很原始，但随着它逐步成熟，它将会使传统的操作系统（如 Linux 和 Windows）越来越无关紧要。

Service Mesh == 云的动态链接器

Service Mesh 是用于分布式核算的现代动态链接器。在传统的编程中，引进另一个模块需求在你的集成开发环境（IDE）中导入一个库。在布置时，操作系统的动态链接器会在运行时将你的程序与库进行衔接。动态链接器还会担任寻觅调用库、验证调用库的安全性，以及建立与调用库的链接。在微服务架构中，你的“库”是到另一个微服务的网络跳转，而找到那个“库”并与之建立安全衔接则是 Service Mesh 的工作。

正如开发和运维团队完全不用考虑动态链接器相同（这几乎不怎么需求照看），现代的分布式团队也不应该去照看一个杂乱的 Service Mesh。今天咱们看到 Service Mesh 成为第一类的根底架构，这已经是很大的前进了。不过这存在一个问题：Service Mesh 仍是太显眼了。

装置 Service Mesh 一般需求几个手艺步骤。根底架构团队有必要与应用开发团队协作，来确保衔接的装备和编码的内容相兼容。许多 Service Mesh 太过杂乱，无法大规模扩展，需求专业的运维支撑人员进行装备才能确保它们正常工作。当 Service Mesh 犯错的时分，你可能甚至要理解它的内部架构才能进行调试。

这种局面有必要改动。

全部都与开发者体会有关

想象一下，Service Mesh 的装置、装备、运维都需求导入一个 JAR 或许 DLL 库，这个过程中的开发者体会如何？如果在传统软件开发中，确诊线上问题有必要理解操作系统的动态链接器的内部架构，那又会是怎样的情景？我想你必定会说：“那也太痛苦了！”

对比一下链接到库的实在体会：你从你的IDE中引证库，构建，然后布置。这样就完成了。这也应该成为 Service Mesh 的黄金规范。

当然，这样的方针是几乎无法达成的。网络调用比内存中的库链接要杂乱得多。不过，问题的关键在于，Service Mesh 应该尽可能地对开发运维团队不可见。它应该极力到达这一黄金规范，即便它永久不可能 100% 到达这个方针。

想象一个云原生的开发环境，让开发者能在构建阶段链接微服务。构建阶段的其间一步会将这些衔接的装备推送到 Kubernetes 中。Kubernetes 会担任其余的工作，其间 Service Mesh 只是 Kubernetes 发行版的一个完成细节，而你几乎不需求考虑这个细节。

那些认为 Service Mesh 只是用于衔接的供应商没有捉住要点。微服务（以及整个云）的价值是小型可布置单元的灵活性和可扩展性更高，但是几十年来咱们一向需求的编程结构并未消失。云技能的许多前进正在填补咱们从单片机迁移到云原生时失去的构造。如果能让微服务开发者的体会更挨近传统软件开发，同时又不牺牲微服务优势的厂商，将具有取胜的产品。

Service Mesh 应当成为一个渠道特性，而不是一个产品类别。它应该尽可能地淡出开发运维团队的视界。

如果发现译文存在错误或其他需求改进的地方，欢迎到 翻译方案 对译文进行修正并 PR，也可获得相应奖励积分。文章开头的 本文永久链接 即为本文在 GitHub 上的 MarkDown 链接。

翻译方案 是一个翻译优质互联网技能文章的社区，文章来历为 上的英文共享文章。内容掩盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等范畴，想要查看更多优质译文请持续重视 翻译方案、官方微博、知乎专栏。