张亚龙 译 分布式实验室

对于大多数人来说，Service Mesh仍然是一个相当新的概念，所以此时已经开始谈及其历史可能会有一点好笑。 但就目前而言，Linkerd已经在全球各地公司的生产环境运行超过18个月，这在云原生应用中是一个很漫长的时间， 我们可以追溯其概念到2010年初创的网络公司。 所以肯定有历史需要探索和理解。
然而，在深入讨论之前，我们立足当下一段时间：什么是Service Mesh？为什么它突然成为热门话题了？
Service Mesh是一个软件基础设施层，用于控制和监控微服务应用中的内部服务到服务的流量。它通常采用与应用程序代码一起部署的网络代理的“data plane”的形式，以及与这些代理交互的“control plane”。在这个模型中，开发人员（“service owners”）不知道Service Mesh的存在，而操作员（“platform engineers”）获得了一套新的工具，以确保可靠性，安全性和可见性。
为什么Service Mesh突然变得如此有趣？ 简言之，对于许多公司来说，像Docker和Kubernetes这样的工具已经“解决部署”问题——至少在第一次接近的情况下。 但他们还没有解决运行时的问题。 这也正是Service Mesh引入的原因。
“解决部署”是什么意思？ 使用像Docker和Kubernetes这样的东西可以大大降低部署的运营负担。 使用这些工具，部署100个应用程序或服务不再是部署单个应用程序的100倍。 这是一个巨大的进步，对于许多公司来说，这会大大降低采用微服务的成本。 这可能不仅仅是因为Docker和Kubernetes在所有正确的级别提供了强大的抽象，而且是因为它们在整个组织中对打包和部署的模式进行了标准化。
但是，一旦这些应用程序是正在运行状态——然后呢？ 毕竟，部署并不是生产的最后一步；该应用程序仍然需要运行。 所以问题就变成了：我们能否像Docker和Kubernetes标准化部署操作一样来标准化我们的应用程序的运行时操作呢？
为了解答这个问题，我们转向Service Mesh。 就其核心而言，Service Mesh提供统一的全局方法来控制和测量应用程序或服务之间的所有请求流量（数据中心的说法是“东-西”流量）。 对于采用微服务的公司，这种请求流量在运行时行为中起着至关重要的作用。 由于服务通过响应传入请求和发出传出请求来工作，因此请求流成为应用程序在运行时的行为的关键决定因素。 因此，标准化这种流量的管理成为标准化应用运行时的工具。
通过提供API来分析和操作这种流量，Service Mesh为整个组织的运行时操作提供了一种标准化机制——包括确保可靠性、安全性和可视性的方法。 就像任何良好的基础设施层一样，Service Mesh（理想情况下）独立于服务的构建方式工作。

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

快速进入现代云原生世界。 当然，这些库仍然存在。 但是考虑到进程外代理提供的操作便利性，使用库的吸引力明显下降——尤其是在容器和协调器出现可能导致部署复杂性急剧下降的情况下。
代理避开了库的许多缺点。 例如，当一个库发生变化时，这些变化必须在每个服务中进行部署，这个过程往往需要进行复杂的组织。 相反，代理可以无需重新编译和重新部署每个应用程序升级。 同样，代理允许多语言系统，其中应用程序由服务组成，用不同的语言编写——这对库而言过于昂贵。
也许对于大型组织来说，最重要的是在代理服务器实现Service Mesh而不是在库中，它将提供运行时操作所必需功能的责任，并由这些功能的最终用户掌握——平台工程团队。提供者和消费者的这种一致允许这些团队拥有自己的命运，并将dev和ops之间的复杂依赖关系解耦。
这些因素都促成了Service Mesh的兴起，这是一种为运行时操作带来健全的手段。通过部署一个分布式代理的“网”，可以维护作为底层基础设施的一部分，而不是应用程序本身，并且通过提供集中的API来分析和操作这种流量，Service Mesh为运行时操作提供了标准化的机制， 组织——包括确保可靠性，安全性和可视性的方法。

那么，Service Mesh的下一步是什么？在这一点上，我们已经花了18个月的时间来帮助组织采用Linkerd，我们已经了解到运行关键任务的本地云应用程序中哪些是正确的，哪些是错误的。在下一篇文章中，我将探讨一些具体的例子，并描述是什么导致了一个全新的Service Mesh项目Conduit的开发，该项目专门针对Kubernetes。
原文链接：https://thenewstack.io/history-service-mesh/