科普帖：什么是服务网格？
戳蓝字“CSDN云计算”关注我们哦！
译| 风车云马
文| Josh Fruhlinger
来源| InfoWorld网站
在数字化转型的背景下，IT行业正在将大型的应用程序集成到小的、离散的微服务容器中，这些容器包含所有的服务代码和依赖项，而这些依赖项彼此独立且很容易地从一台服务器转移到另一台服务器。
这种容器架构很容易在云中扩展和运行，并且可以快速构建独立的微服务。然而随着应用程序变得越来越大，并且同一服务的多个实例同时运行，这些微服务之间的通信变得越来越复杂，在此基础上服务网格是一种新兴的机构形态，旨在以一种减少管理和编程开销的方式动态连接这些微服务。
正如Red Hat（红帽）所描述的，“服务网格是一种控制不同应用程序共享数据的方法。”实际上，这听起来非常像大多数开发人员所熟知的客户端-服务器应用程序中的中间件。
服务网格的独特之处在于它是为适应分布式微服务环境而构建的。在由微服务构建的大规模应用程序中，任何给定服务可能有多个实例，这些实例运行在各种本地或云服务器上。这显然使单个微服务很难找到它们需要与之通信的其他服务，而服务网格会根据时间顺序自动地负责连接服务，这样就“解放”了开发人员和单个微服务。
我们可以将服务网格看作软件定义网络(SDN)。正如SDN创建一个抽象层，使网络管理员不必处理物理网络连接一样，服务网格将应用程序的底层基础设施与所交互的抽象体系结构解耦。
图片来源网络
当开发人员开始处理庞大的分布式体系结构时，服务网格的概念就自然而然地产生了。该领域的第一个项目是Linkerd，它是Twitter内部项目的一个分支；Istio则是另一个受欢迎的项目，主要由企业支持，起源于Lyft。
解决“服务网格”管理微服务的通信问题有许多不同的方法。Aspen Mesh的Andrew Jenkins提出了三种可能的方式，即服务网格创建的通信层可能位于：
在每个微服务导入的库中
在向特定容器提供服务的节点代理程序中
在与应用程序容器一起运行的sidecar容器中
基于sidecar的模式是目前最流行的服务网格模式之一，甚至在某种程度上它已经成为服务网格的同义词。严格地说它们并不等同，不过sidecar方法已经得到了如此多的关注，这就是我们将要详细讨论的架构。
那在应用程序容器中运行一个sidecar容器是什么意思？红帽（Red Hat ）有一个很好的解释。这种类型的服务网格中，每个微服务容器都有与之对应的另一个代理容器，服务到服务通信所需的所有逻辑都从微服务中抽象出来，放到sidecar中。
这看起来可能很复杂，毕竟实际使应用程序中的容器数量增加了一倍，但是这种设计模式成为简化分布式应用程序的关键。它通过将所有网络和通信代码放到一个单独的容器中，将其作为基础设施的一部分，并使开发人员实现应用程序时不必考虑这一点。
从本质上说，这个微服务只需要专注于其业务逻辑，不需要知道如何在其运行的环境中与所有其他服务通信。它只要知道如何与sidecar通信，sidecar负责其余的工作就可以了。
那么目前有哪些可用的服务网格呢?据了解市面上没有现成的商业产品，大多数服务网格都是开源项目，需要一些技巧才能实现。最著名的有：
Linkerd——于2016年发布，是最古老的产品，最早是从Twitter开发的一个库中分离出来的。该领域的一位重量级人物Conduit引入了Linkerd项目，后来成为Linkerd 2.0的基础。
Envoy——Lyft创建的Envoy占领了服务网格的“data plane”（数据区）。为了提供一个完整的服务网格，它需要与一个“control plane”（控制区）相匹配，比如Istio……
Istio——由Lyft、IBM和谷歌合作开发，Istio是一个服务于Envoy等代理的控制计划。虽然Istio和Envoy是默认的一对，但是它们都可以与其他平台配对。
HashiCorp Consul—— Consul 1.2中引入了一个名为Connect的特性，它向HashiCorp的分布式系统添加了服务加密和身份授权，用于服务搜索和配置，从而将其转变为一个完整的服务网格。
服务网格 VS 负载平衡
服务网格提供的一个关键特性是负载平衡。我们通常认为负载平衡是一种网络功能，即为了防止任何一台服务器或网络链接流量过大，因此需要相应地路由数据包。正如Twain Taylor所描述的，服务网格类似于应用程序层的软件定义的网络。
本质上，服务网格的工作之一是跟踪分布在基础设施中的各种微服务的实例。它可能会轮询，看看它们在做什么；或者跟踪哪些实例对服务请求响应较慢，然后将后续请求发送给其他实例。
服务网格会为网络路由做类似的工作，注意到消息到达目的地花费的时间过长，就采取其他路由进行补偿。这些延迟可能是由于底层硬件的问题，或者仅仅是由服务请求过载或处理能力不足造成的。重要的是，服务网格可以找到相同服务的另一个实例并将其路由到另一个实例，从而最有效地利用整个应用程序的容量。
服务网格 VS Kubernetes
如果对基于容器的体系结构比较熟悉，那么就一定知道Kubernetes在这方面的地位。作为流行的开源容器编制平台，Kubernetes不就是管理容器之间的通信吗? 正如Kublr团队指出的，用户可以将Kubernetes的服务资源看作是一种非常基本的服务网格，因为它提供服务发现和请求的轮循；但是服务网格提供了更多功能，例如管理安全策略和加密、“断路”等以限制对慢响应实例的请求、负载平衡等。
毋庸置疑大多数服务网格实际上都需要像Kubernetes这样的编排系统，提供扩展功能而不是替代Kubernetes。
服务网格 VS API网关
每个微服务将提供一个应用程序编程接口(API)，作为其他服务与其通信的方式，这引发了服务网格与其他更传统的API网关之间的差异问题。正如IBM所解释的，API网关位于一组微服务和“外部”世界之间，根据需要路由服务请求，以便请求者避免知道它正在处理的微服务应用程序；另一方面服务网格在微服务应用程序“内部”协调请求，各个组件完全了解它们的环境。
还有一种解释，正如Justin Warren在《福布斯》中所写的，服务网格用于集群内的东西流量，而API网关用于集群内外的南北流量。但是整个服务网格的概念还处于早期阶段，而且还在不断变化之中。许多服务网格，包括Linkerd和Istio现在也提供南北功能。
究竟哪种服务网格更适合?目前还没有办法给出定论。但值得注意的是，以上提出的所有产品都已经在大型场合和高标准的环境中得到了验证。其中Linkerd和Istio拥有最广泛的特性集，都在快速发展；另外在这个新的领域，新的竞争者随时可能出现。
-
漫画：程序员战力图鉴
-
我们到底该如何看待6G？
-
漫画： 什么是插入排序？
-
从七个方面，面试大厂高级工程师
-
为什么说边缘计算的发展比5G更重要？
记一道字节跳动的算法面试题