（译）Service Mesh 选型指南
如果你正在管理云原生微服务，应该会听说 Service Mesh，并且也了解为何使用 Service Mesh，那么这篇文章就是为你而作。当你开始靠近观察 Service Mesh 的时候，会突然意识到，已经有了多个可选方案了。选哪个呢？你如何分辨不同 Service Mesh 之间的差异，哪个 Service Mesh 更适合你呢？本文以客观、中立的态度来帮助你启动这第一步。
Service Mesh 是一个独立的基础设施层，用于管理服务之间的通信，让这些通信可见可管控。不同产品之间有一些细节差异，但是总的说来，Service Mesh 产品是有一些共同点的。
Service Mesh 的普遍特征
在上面的基础架构图中，数据面的绿色方框代表着应用，蓝色方框则代表 Service Mesh 的代理服务器，灰色的矩形区域就是应用的端点（Pod、物理机等）了。控制面提供了一个中心化的 API，用于集中控制代理服务器的行为。和控制面的交互是可以自动化的（也就是可以使用 CI/CD Pipeline 来完成），这是用户和 Service Mesh 进行交互的典型方式。
本文中的任何 Service Mesh 都有一些基础功能：
- 应用弹性（重试、超时、Deadline 等）
- 防止级联故障（熔断）
- 健壮的负载均衡算法
- 请求路由控制（对 CI/CD 这样的发布模式很有帮助）
- 在端点之间的同心过程中加入 TLS 支持的能力
- 丰富的指标，用来监控服务间的交互
这些功能的细节——如何实现、配置等，各个产品都有差异。但是总的说来，这些要素应该作为 Service Mesh 应该提供的标准功能。本文会着重关注不同产品之间的功能差异。
Service Mesh 的区别？
有了 Service Mesh 的帮助，让分布式应用的可靠性得以提升。在微服务中，服务之间的通信是应用运行质量的决定性因素。过去使用同一运行环境的本地调用变成了通过不可靠网络进行的远端过程调用。反应企业需求的复杂决策树，其成败取决于对分布式系统建设的实际情况的清楚认识。
因此当厂商主张 Service Mesh 的时候，会尝试对远程调用的消息（或者 API 调用）进行管理。因此必然要把 Service Mesh 和其他的消息管理方案例如面向消息的中间件、ESB、EAI 或者 API 网关等进行比较。Service Mesh 和这些产品会有一些功能上的重叠，但是整体上来说，Service Mesh 面向的是一个更大的问题集。
Service Mesh 之所以与众不同，是因为他在应用之外作为基础设施而存在。他的价值主要体现在对 RPC（或者消息）的管理上，但还可以更进一步的管理所有入站出站的流量。无需在应用中编写代码来实现通信管理，而是实现了一系列的互联互通的代理服务器（或 “mesh”），这些代理服务器将逻辑从应用中解耦出来，也将开发人员解放出来。
好好好，那怎么选择？
在观察 Service Mesh 家族中的特定产品之前，回答以下运维和技术问题，能帮助你有一个更加清晰的起步。
- 我和我的组织准备好使用 Service Mesh 了么？使用任何新的工具，都需要在使用、管理方面投入学习成本。要确定这些投入是值得的。如果你要管理一个存在大量不同服务调用的分布式应用，那么就应该需要 Service Mesh了。
- 我面临的是什么问题？当管理你的分布式产品时，最突出的痛点是什么？是关于可见性、服务依赖关系、安全管理或者管理能力方面的问题么？如果是一个肯定的回答，那么你很需要 Service Mesh。记住最大的痛点，因为你会在未来用到它。
- 你要支持什么平台？你的分布式系统运行在哪里？除了支持你的容器管理平台之外，是否需要连接 Mesh 之外的服务？你要求 Service Mesh 产品能扩展到什么程度？
- 目前你的服务监控做到什么程度？Service Mesh 最显而易见的有点就是开箱即用的服务通信监控能力。对于你的组织来说，这一功能是否重要？目前阶段相差多远？这是个容易被忽视的问题，但是这也可能是 Service Mesh 给你带来的第一个收益（想想你的痛点）。
- 你是否已经有了部分 Service Mesh 的能力？引入 Service Mesh 之后，这些原有能力该向何处去？你要选择的 Service Mesh 产品中间有多少类似功能已经在现有应用中已经实现？这种情况下引入 Service Mesh 会产生问题么？如何除旧布新？需要对旧有能力进行整合么？
- 你的团队在这些功能方面是如何分工的？开发团队是否需要自行管理自己的代理配置？这些管理工作是否有一个统一的运维团队？不管你的组织中的职责如何分配，要确认我们将选择的 Service Mesh 能够以符合组织形态的方式进行管理。
- 你倾向于中心化还是去中心化的功能？按照应用的规模和复杂度，你会倾向基于主机的代理服务器池，还是选择相对复杂的 Sidecar 模型？
- 你和你的团队期望得到什么样的支持？典型的开源社区支持能够满足要求么？对于产品的快速变更的容忍程度如何？是否需要商业支持？在生产环境运行时，这些因素非常重要。
当然，这些问题每个人都会有自己的答案，不会存在适合左右人的标准选择。但是在比较产品的功能、设计理念和目标用例的时候，应该对这些问题随时保持警醒。
产品比较
这篇指南中我们着重关注四个开源产品。我们会使用发布日期进行排序。这里会尝试突出不同产品之间的重要区别。
Linkerd
Linkerd（发音 linker-dee）由 Buoyant 资助，在 2016 年 2 月发布的。这一产品首先提出了 Service Mesh 这一术语。Linkerd 是一个强大、多平台、功能丰富的 Service Mesh 产品。基于 Twitter 的 Finagle 库构建，Linkerd 用 Scala 编写，在 JVM 上运行，每实例每秒能够处理几万请求。
主要特性包括：
- 上文中提到的全部必要功能。
- 支持多平台（Docker、Kubernetes、DC/OS、Amazone ECS 以及任何独立服务器）。
- 内置的服务发现抽象，可以跨越多个系统。
- 支持 gRPC、HTTP/2 以及 HTTP/1.x 请求，以及所有 TCP 流量。
Linkerd 包含一个代理服务器作为数据面，以 Namerd（”namer-dee”）作为控制面，集成在同一个包中。Linkerd 是一个开源项目，同时 Buoyant 还提供了商业支持。截止到 2018 年 4 月，超过 50 个公司在生产环境上运行 Linkerd，Linkerd 具有经过考验的应用案例，为用户处理超过万亿次的服务请求。
Envoy
Envoy 在 2016 年 10 月由 Matt Klein 以及 Lyft 团队以开源项目的形式发布。这是一个用 C++ 编写的高性能应用，为现代云原生服务架构设计。Envoy 的设计，既可以用作独立的代理服务器，也可以作为 Service Mesh 架构的通用数据面使用。Envoy 的多元化社区由在生产环境中使用 Envoy 的贡献者们构成。
主要特性包括：
- 上文中提到的全部必要功能（前提是和一个控制面配合，例如 Istio）。
- 在负载情况下具有很低的 p99 尾延迟。
- 核心是 L3/L4 过滤器，开箱即用的为数众多的 L7 过滤器。
- 支持 gPRC 以及 HTTP/2
- API 驱动，动态配置
- 专注于指标收集、跟踪和整体可观测性。
Envoy 是一个高级的应用代理服务器，是 Service Mesh 架构中的数据面。Envoy 具有很小的资源占用，因此不管是共享代理还是 Sidecar 代理，Envoy 都能提供很好的支持。Envoy 是社区支持的，也有 Turbine Labs 这样的厂商提供了商业支持。你还会发现 Envoy 被嵌入安全框架、网关或者其他的 Service Mesh 解决方案，例如 Istio。当和 Istio 控制面配合的时候，Envoy 能够提供所有 Service Mesh 的必备功能。
Istio
Istio 面世于 2017 年五月，是由 Lyft、IBM 和 Google （还有其他的成员，例如红帽以及很多其他迅速加入的合作伙伴）合作的开源项目。Istio 的设计是要提供一个通用的控制面，用于管理底层大量的服务代理（缺省使用的是 Envoy）。起初 Istio 是针对 Kubernetes 的，但他的底层是平台无关的。Istio 控制面用 Go 语言编写，能够进行扩展。Istio 项目的设计宗旨是性能和规模、移植性，用松耦合的组件来支持弹性部署。
主要特性包括：
- 所有的必要功能（和 Envoy 这样的数据面结合）。
- 安全功能包括认证、密钥管理和 RBAC。
- 故障注入。
- 支持 gRPC、HTTP/2、HTTP/1.x、WebSockets 以及全部 TCP 流量。
- 策略、额度以及流量控制。
- 多平台、混合部署。
Istio 控制面专注于为运维人员提供多种对象进行策略的编制。有很多为不同应用编写的组件，让 Istio 能够匹配到不同的下级数据面上，例如商业授权的 Nginx 代理服务器。Istio 必须和一个底层代理服务器配合工作。
Conduit
Conduit 在 2017 年 12 月初次发布，同样由 Buoyant 赞助。Conduit 着重为 Kubernetes 用户提供简化的 Service Mesh 使用体验。COnduit 具有轻量级、高性能、安全以及易于理解使用的方便特性。Conduit 由 Rust 编写的数据面和 Go 编写的控制面组成。
主要特性包括：
- 所有的必要功能（根据 2018 年 4 月的路线图，有些还在实现之中）。
- 非常快速，值得期待的性能表现（1ms 以下的 p99 延迟）。
- 原生的 Kubernetes 使用体验（只支持 Kubernetes）。
- 支持 gRPC、HTTP/2、HTTP/1.x 请求以及所有 TCP 流量。
Conduit 具有一个最小化的架构，以及零配置的设计理念，开箱即用，极少需要用户干预。他的设计来源于对在生产环境中对 Service Mesh 的支持，Conduit 希望能用最小的额外复杂度来解决来自分布式系统管理的问题。
结论
这篇产品设计和功能差异方面的介绍，希望能够帮助读者决定如何踏上 Service Mesh 之旅。这些产品的尝试本身也很有挑战性，我们鼓励用户为自己演示不同的解决方案，从而做出最合适的决策。