首先是无处不在、适用于一切的应用，然后是微服务（以及支持它们的容器技术）。 下一个有助于通过应用程序提供卓越用户体验的创新是什么？ 服务网格。
微服务方法依赖于小型、单一用途的组件，这些组件用于形成更大、更复杂的应用。 您可以为任何事物创建微服务，而且由于每个微服务都专注于单一功能，因此开发速度相对较快。 然而，您想要的功能越多，协调微服务组件就越复杂。
传统应用（有时称为整体应用）开发速度较慢，但它们具有优势。 由于许多单独的功能由单个程序执行，因此组件之间的协调通常内置于系统中。 只有一个代码源，这使得传统应用程序更容易排除故障和调试。
服务网格是一个透明的基础设施层，有助于促进微服务之间的通信。 这使得使用微服务构建的应用程序具有与传统应用程序相同的优势——例如弹性、可观察性和安全性。
从整体式架构到微服务的转变主要源于应用团队对更敏捷、更快执行的需求。 将大型应用分解成许多小元素，使得各个团队能够各司其职。 当他们必须关注整体的各个方面时，这让他们能够以更快的速度进行迭代。
然而，这种速度和灵活性是有代价的：复杂性增加。 微服务简化了开发，但也带来了新的挑战，特别是在保护和协调多个临时组件方面。 服务网格是开发人员在支持微服务的应用扩展时减轻复杂性的一种方法。
在最近的播客中， Aspen Mesh联合创始人兼首席技术官 Andrew Jenkins 这样说道：“在服务网格环境中，最大的变化不是应用程序开发人员需要做什么，而是他们不应该做的所有事情。” 例如，服务网格的安全组件提供身份验证并管理一个应用是否信任另一个应用程序。 当请求失败时，平台操作员可以使用工具来定义微服务是否重试或退出。
在这个新的环境中，开发人员可以专注于将请求传递到服务网格层。 平台运营商可以使用观察微服务之间所有通信的工具，为应用程序开发人员提供全新的数据和指标。 “在服务网格中，您只需在一个地方修复该故障，然后它可以在所有地方得到修复。 同样的一致性故事一次又一次出现，”詹金斯说。
将服务网格视为一个强大的新工具箱。 有关于安全、交易处理、加密、推荐引擎、分布式跟踪等的工具……不胜枚举。 但如果您不知道如何使用它们，那么强大的工具也无济于事。 服务网格的成功早期采用者需要强大的云架构实践和经验丰富的为开发人员定义基础设施服务的平台团队。
许多组织在没有服务网格的情况下成功运行了Kubernetes和其他容器技术。 标准 Kubernetes 实现很好地解决了内置部署问题。 然而，在规模扩大后，Kubernetes应用会出现一些尚未得到很好解决的运行时问题，例如加密、断路和动态流量路由等。 NGINX和其他容器入口解决方案等解决方案通过提供在网络流量进入应用时捕获、塑造、控制和可视化网络流量的方法填补了这一空白。 但是，当开发人员开始触及这些工具所能提供的功能的极限时，服务网格有望为容器化微服务的功能提供更高层次的可见性。
目前，服务网格仍然处于前沿。 对于已经完全致力于 Kubernetes 或计划使用 Kubernetes 进行开发的组织来说，尽早实现服务网格要比在以后实施更容易。 如果您正在扩展 Kubernetes，并且希望最大限度地减少管理开销，那么您需要一个服务网格。
对于具有复杂安全需求或严重依赖微服务衍生应用的组织，服务网格可以加速部署和维护，加强安全性并帮助优化资源消耗。 服务网格环境提高了可见性，提供了可用于优化应用的微观和宏观层面的数据。
服务网格是微服务和容器技术的下一个发展阶段。 只要采用正确的策略，它就可以成为一种强大的工具。