Service Mesh并非新出现的功能。一直以来，Web应用程序需要自己管理复杂的服务间通信，从过去十多年间应用程序的演化就可以看到Service Mesh的影子。
2000年左右的中型Web应用一般使用了三层模型：应用逻辑层、Web服务逻辑层和存储逻辑层。层与层之间的交互虽然也不算简单，但复杂性是很有限的，毕竟一个请求最多只需要两个跳转。虽然这里不存在“网格”，但仍然存在跳转通信逻辑。
随着规模的增长，这种架构就显得力不从心了。像Google、Netflix、Twitter这样的公司面临着大规模流量的挑战，他们实现了一种高效的解决方案，也就是云原生应用的前身：应用层被拆分为多个服务（也叫作微服务），这个时候层就变成了一种拓扑结构。这样的系统需要一个通用的通信层，以一个“富客户端”包的形式存在，如Twitter的Finagle、Netflix的Hystrix和Google的Stubby。
一般来说，像Finagle、Stubby和Hystrix这样的包就是最初的Service Mesh。云原生模型在原先的微服务模型中加入了两个额外的元素：容器（比如Docker）和编排层（如Kubernetes）。容器提供了资源隔离和依赖管理，编排层对底层的硬件进行抽象池化。