服务网格是什么？( What is a Service Mesh? ) 翻译自Nginx官网

阅读前的小说明：

由于工作需要研究Service Mesh，故本人翻译了Nginx官网的一系列有关Service Mesh的文章，以便日后查阅，也方便各位参阅。希望能借此文章，与各位大佬们多多交流，谢谢。
此外，由于本人的英文功底着实较为薄弱，因此文中若如果出现部分翻译不当或翻译错误，也希望大家批评指正，不吝赐教！

原文链接( Nginx 官方网站 )：https://www.nginx.com/blog/what-is-a-service-mesh/
翻译By : 田同学 || Contact me : [email protected]
https://github.com/XinyaoTian 注明原出处及译者信息，欢迎转载。

啥是服务网格( Service Mesh )?

服务网格 == 一种微服务的基础架构 译者注。

服务网格( Service Mesh )是指用于微服务应用的可配置基础架构层( configurable infrastructure layer )。它使每个service实例之间的通信更加流畅、可靠和迅速。服务网格提供了诸如服务发现、负载均衡、加密、身份鉴定、授权、支持熔断器模式( Circuit Breaker Pattern )以及其他一系列功能。
服务网格的实现通常是提供一个代理实例，我们称之为"sidecar"。sidecar 包含在每一个service 之中。sidecar 主要处理 service 间的通信、监控、以及一些安全相关的考量 —— 任何可以从服务本体中抽象出来的安全方面的部分。通过这种方式，开发者可以在服务中专注于开发、支持以及维护；运维人员可以维护服务网格并运行app。

Istio( 由Google、IBM、Lyft公司在背后进行支持 ) 是目前最广为人知的一款服务网格架构。Kubernetes( 由Google最早进行设计并开源 ) 是目前 Istio 唯一支持的容器组织框架。

服务网格对于其组件service和功能有如下术语：

容器组织框架( Container orchestratiob framework ):

随着越来越多的容器被加入到应用的组织架构中，一个用于监控和管理这一系列容器的独立工具，即：容器组织框架，就变得不可或缺了。Kubernetes 由于考虑到市场原因( Docker Swarm和Mesosphere DC/OS是其主要竞争者 )，Istio 并非强制安装。因此安装时是否集成 Istio 变成了可选项。

Service 与 Service 实例( Service Instance ):

确切来讲，开发者创建的并非是一个service，而是一个由service定义的或者框架定义的实例。那些app创建的service实例由此而来，并且真正干活的是这些实例。然而，"service"一词经常被用来同时指代“定义service的东西”和“service实例”这两者。

Sidecar 代理(Sidecar Proxy):

sidecar proxy 指专“注于每个具体的service实例”的一个代理实例。它与其他的sidecar proxy通讯并由容器组织框架( 比如Kubernetes )进行统一管理。

服务发现( Service discovery ):

当一个实例需要与其他service进行通讯时，它需要“寻找并发现( find & discovery )”另一个健康、可用的 service 实例。容器管理框架( container managment framework )维护着一个时刻准备接收请求的实例列表。

负载均衡( Load balancing ):

在一个服务网格中，负载均衡自底向上地工作着。由服务网格维护的可用实例列表可以进行打分、评级、并选出“最闲”的service，这就是在高层次上的负载均衡。

加密( Encryption ):

服务网格可以加密和解密服务间的请求与相应，并从service中将这些步骤分离，从而减轻每个service内的负担。服务网格可以通过优先再利用已经存在的、持续的连接( connection )来提高性能，以便减少“新建连接”时高昂的计算开销。

认证与权限( Authentication and Authorization ):

服务网格可以授权并认证从外来的或是app内服的各种请求，并且只发送那些有效的请求给service。

支持熔断器模式( Support for the circuit breaker pattern ):

服务网格能够支持熔断器模式，它能隔离那些不健康的实例，并逐渐将那些有保证的实例再次添加进健康实例池( healthy instance pool )。

data plane 与 control plane

data plane == 数据流动的、工作真正被处理的部分 control plane == 管理监控这些工作运行的部分 译者注。

服务网格中工作被完成的部分( 包括service实例、sidecar代理以及它们间的沟通 )被称作 data plane 。但是服务网格中也会包含一个监控管理层，我们称它为 control plane。

control plane 处理的工作诸如：创建新实例、终止不健康或者不需要的实例、服务监控、集成监控与管理、实施应用范围的策略( application-wide policies )以及优美地将整个应用作为一个整体结束掉。典型的 control plane 包括、或被设计成用于连接API、命令行工具、或者一个用于管理整个应用的可视化用户界面。

(上图为 nginMesh —— 一个基于Istio的服务网格，包括了control plane，data plane 以及 使用 Nginx 作为sidecar Proxy)

Nginx 有一个可以兼容 Istio 架构的服务网格，我们称它为 nginMesh 。上图基于nginMesh的架构展示了 Nginx 作为sidecar Proxy的角色，与其他典型的Istio组件共同发挥作用。

一个典型的网格服务架构场景是，当你使用容器和微服务去解决一个对性能要求很严苛的应用开发工作时。比如使用微服务架构的先锋们——Lyft，Netflix和Twitter这些公司，他们需要健壮的service去服务全世界上百万的用户，每时每刻( 可以参考Netflix利用这种架构的实际应用场景，见: https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/)。对于那些较少访问需求的应用，上图这种简单的架构就足够了。

服务网格架构不可能永远是所有应用开发和交付问题的解决方案。架构师和开发者有许多很棒的工具，但要分清哪些是锤子、哪些是钉子。Nginx 微服务相关架构( 见: https://www.nginx.com/blog/introducing-the-nginx-microservices-reference-architecture/ )，包含了多种不同的模型，提供了解决微服务问题的整体方案。

这只是服务网格架构中的一个元素——就像Nginx、容器、Kubernetes和微服务作为一整个架构级的方案一样——可以被，也已经被用于富有成果的没有集成服务网格的实施中。比如Istio这个服务网格架构，它就设计成模块化的，因此开发者可以选择是否真的需要用它。将上面这些概念记在你的脑海中，当你开发一个坚实的应用时，服务网格的这些概念是很有价值的。即使你并不非常确切地明白它们。

后记

我们计划将服务网格写成一个系列，这篇是这个系列的第一章。我们计划在之后陆续更新这些文章：
什么是服务网格? :【本篇】
服务网格架构的好处与坏处: 主要用于阐述哪些场景下，服务网格是适用的；以及什么时候做出改动会是更好的。
服务网格架构 vs API途径: 我们将阐述：何时选择API、何时选择服务网格，或者何时将它们混合使用是适当的。
Kubernetes与服务网格架构: 阐述如何使用Kubernetes与其一系列架构，包括服务网格。
在服务网格架构中使用Nginx: Nginx可以作为一个关键角色，作用于各种服务网格架构之中——作为 sidercar proxy 、 准入控制( Ingress controller )或者同时作为这两者——或者提供诸如负载均衡、服务发现、缓存等特性的功能。

翻译By 田同学
希望对您的工作学习有所帮助，谢谢。