服务网格只是另一种形式的虚拟化

当我在2000年初开始使用VMware ESX时，我知道这是一个非常酷的技术; 而且不仅是我，每个人都知道它有一些特别之处。

但是，我还没有完全掌握这门技术的全部价值，在那一点上，我只看到了面前的“服务器整合”。

当vMotion出现时，我们意识到物理已经改变了我们的服务器，我们不再依赖于运行服务器的硬件。无名硬件抽象允许我们做我们以前无法做的事情。比如修复硬件问题或修补它没有停机时间，通过在我们需要时部署VM并更好地监控基础设施的健康状况，甚至自我修复，可以更好，更快地扩展。我们从未见过一个令人兴奋的新的敏捷世界。

由于上述与自动化的结合，管理服务器的工作量已经降低，管理服务器组的人员也更少。

这跟你问的服务网格有什么关系？

最近我开始专注于服务网格，主要是Istio，在实验室中测试它，学习技术并再次感受到魔力。虽然这项技术很酷，但我试图理解的商业价值不仅仅是分布式，负载平衡，可观察性等等热门话题。但是，在某些时候，我意识到我看错了。

从网络运营角度看：服务网格其实是一种虚拟化形式

我认为Service mesh与虚拟化有很多相同之处。

在单体的应用程序世界中，编译应用程序或服务的许多不同代码片段都在一小组服务器上运行，因此在代码中编写有关该组件如何与应用程序的其他部分交互的决策。

这意味着，对于区分应用程序所服务的业务的每一段有意义的代码，需要有很多非差异化的代码。(banq注：中间件功能)

这些功能包括诸如服务器和客户端通信，服务查找，错误检测和响应，遥测，安全性之类的事情。

随着微服务（以及为此目的使用容器）的兴起，每个容器现在运行一段差异化代码（每个微服务都和其他服务器上微服务不同，有自己的负载平衡等），监控和解决问题带来了新的挑战。

服务网和Istio做的是将非差异化工作外包给Envoy的sidecars，其中每个k8s pod现在都有一个代理，负责与其他代理和网外通信。（Envoy可以使用超过k8s的pod，它甚至可以与VM或Pivotal PAS AI一起使用！）

现在我们已经抽象出了非差异化代码（banq：其实是新的中间件功能）。与通过虚拟机管理程序虚拟化硬件并添加控制面板所获得的效果类似，我们通过添加Istio形式的控制面板获得代理操作。

下面这张图说明不同抽象层。

即时更改平台功能而不是更改我们的代码，这样可以节省开发人员花费的大量精力，能够实现动态更改策略而不更改任何代码，可以应用安全性和身份验证交易，能更好地了解应用程序运行状况。自我修复现在变成了现实。

服务网格是非差异化代码（中间件）的虚拟化

Docker等容器是对OS的虚拟化

VM是对硬件设备的虚拟化。