为什么服务网格应逐渐消失

随着对服务网格的兴趣日益浓厚，许多应用程序开发和交付专家首次与之接触时，使他们想知道它们与API网关有何不同。服务网格是他们自己的产品类别吗？还是它们是更广泛的API管理的一部分？这些问题没有抓住重点：服务网格需要逐渐淡入开发平台的后台。要了解原因，首先必须了解Kubernetes所发生的悄悄变革。

传统操作系统管理计算机的资源，并为程序员提供更高级别的抽象，以使其与复杂的基础硬件进行交互。他们开始解决手工编码与硬件的直接交互的挑战。

Kubernetes管理计算机集群的资源，并为程序员提供更高级别的抽象，以使其与复杂的基础硬件和不稳定，不安全的网络进行交互。它开始解决与集群硬件进行手动编码直接交互的挑战。尽管按操作系统标准是原始的，但随着它的成熟，它将使诸如Linux和Windows之类的旧操作系统变得越来越不相关。

服务网格是用于分布式计算的现代动态链接器。在传统编程中，包括另一个模块在内涉及将库导入到集成开发环境（IDE）中。部署后，操作系统的动态链接器会在运行时将程序与库连接。它还处理发现库，验证调用库的安全性以及建立与它的连接。使用微服务架构，您的“库”就是到另一个微服务的网络跳转。查找该“库”并建立安全连接是服务网格的工作。

正如开发和运营团队不必考虑一个动态链接器一样，少了一个人的关心和提要，现代的团队就不必关心和提要一个复杂的服务网格。我们今天看到的服务网格成为一流基础架构的情况是向前迈出的重要一步，但是它们存在一个问题：它们太明显了。

安装典型的服务网格需要几个手动步骤。基础架构团队必须与AppDev团队协调，以确保连接配置与编码内容兼容。许多服务网格过于复杂，无法大规模扩展，需要强大的运营支持人才来配置和保持健康。您甚至可能需要了解服务网格的内部体系结构，以便在出现问题时进行调试。这必须改变。

想象一下开发人员的经验，其中导入JAR或DLL库需要服务网格所需要的所有安装，配置和操作支持。如果还需要了解操作系统动态链接器的内部体系结构以诊断运行时问题怎么办？我听到你在回答，“那太疯狂了！”

将此与链接到库的真实体验进行对比：您可以从IDE中引用该库，然后进行构建和部署。做完了那应该是服务网格的黄金标准。

显然，这是无法实现的。网络调用比内存库链接更复杂。关键是，服务网格对DevOps团队应尽可能不可见。即使它不可能永远达到100％，它也应该朝着那个金标准努力。

想象一下一个云原生开发环境，使开发人员能够在构建时链接微服务。然后，在构建过程中，将这些连接的配置推送到Kubernetes中。然后，Kubernetes负责其余的工作，而服务网格只是您很少考虑的Kubernetes发行版的实现细节。

那些相信服务网格仅仅是关于连通性的供应商会忽略这一点。微服务（通常是云）的基本价值在于，在无服务器上运行的较小的可部署单元具有更大的敏捷性和可伸缩性，但数十年来我们一直需要的编程结构并未消失。云技术的许多进步填补了我们从整体式迁移到云原生时失去的结构。使微服务开发人员的体验与传统软件开发更加类似的供应商，而又不牺牲微服务的利益，将获得成功的产品。

总而言之，服务网格应该是平台功能，而不是产品类别，这应尽可能远离DevOps团队。