Service Mesh的诞生历程是什么？

Service Mesh起源始于2010年左右应用架构三层模型的兴起——一种简单的架构，曾一度为网络上的绝大多数应用提供动力。在这个模型中，请求流量扮演一个角色（有两跳！），但它本质上是非常专业化的。应用程序流量首先由“Web层”处理，然后与“应用层”进行对话，然后与“数据库层”进行对话。Web层中的Web服务器旨在处理大量传入请求非常迅速地将它们交给相对缓慢的应用程序服务器。（Apache，NGINX和其他流行的Web服务器都具有用于处理这种情况的非常复杂的逻辑）。同样，应用层使用数据库库与缓存进行通信。这些库通常以针对此用例进行优化的方式处理缓存、负载平衡、路由、流量控制等。 到目前为止运行良好，但是这种模式在重负载下开始崩溃——特别是在应用层，随着时间的推移可能会变得相当大。谷歌、Facebook、Netflix和Twitter等早期的网络规模公司学会了将整体拆分成许多独立运行的组件，从而促成了微服务的兴起。引入微服务的同时，也引入了东-西的流向。在这个世界上，沟通不再是专门制定的，而是在每一项服务之间都存在。当它出错时，该网站就宕机了。 这些公司都以类似的方式回应：他们写了“胖客户端”库来处理请求流量。这些例如谷歌的Stubby，Netflix的Hysterix，Twitter的Finagle的库——为所有服务提供了统一的运行时操作方式。开发人员或服务所有者可以使用这些库向其他服务发出请求，并且在这些库下，这些库可以执行负载平衡、路由、断路、遥测。通过在应用程序中的每个服务中提供统一的行为，可见性和控制点，这些库形成了表面上是第一个Service Mesh的东西——并没有花哨的名称。