应用场景

负载均衡

服务网格提供的一个关键功能就是负载均衡。我们通常认为负载均衡是网络功能，因为它提供按规则的数据包路由转发，从而防止任何单台服务器或网络链接的流量过载。借用 Twain Taylor 的描述，服务网格就是在应用级别上做了类似的事情，我们可以将它理解为应用程序层的软件定义网络。

本质上，服务网格的一个主要工作是对分布在基础设施中的各种微服务的实例，进行健康状态的持续跟踪。它可能会轮询这些实例的请求处理状态，或者跟踪服务请求响应较慢的实例，然后将后续请求发送给其他的实例。类似于网络路由，它还会关注消息到达目的地消耗时间过长的请求，并调整后续路由来补偿。这些用时过长可能是由于底层硬件的问题，或者仅仅是由于服务被请求过载或处理能力不足造成的。但重要的是，服务网格可以找到相同服务的其他实例来接替请求处理，从而最有效地利用整个应用程序的处理能力。

每个微服务都将提供一个应用程序编程接口（API），用于与其他服务的通信。这就引出了服务网格与传统的 API 管理形式（如 API 网关）之间的差异比较。借用 IBM 的解释，API 网关是位于一组微服务和应用“外部”之间，根据需要路由服务请求，让请求者无需知道它所访问的应用程序是基于微服务架构的。但服务网格不仅有上述能力，它还在应用程序“内部”的微服务之间协调请求，且各个组件完全了解整个应用内部的环境。

灰度发布

Service Mesh 是用来处理各服务间通信的基础设施层。它主要通过构建云原生应用程序的各种复杂拓扑结构来完成传递请求。实际上，Service Mesh 通常与应用程序代码一起部署轻量级网络代理的阵列来实现请求。

在 ServiceMesh 之前，我们已经采用了 APIGateway 来实现灰度发布，但 APIGateway 通常仅部署在用户流量的入口，完全灰度发布就需要完整地部署两套系统。但是在微服务时代，任何一个微服务发生变更都需要完整地部署两套系统，这不仅成本很高而且严重影响了产品变更的速度。

而 ServiceMesh 正好可以解决这些问题，它的应用类似于将 APIGateway 部署到本地，同时提供了集中化控制，极大地简化了灰度发布的实现流程、降低了变更成本、同时加快了产品发布的进度。