转载

服务网格如何辅助微服务管理

June 13, 2019, By Josh Fruhlinger

IT在数据化转型旗帜下的一个重大转换就是将大型的，整体的应用架构分拆成为细小独立的，功能级的微服务架构。这些微服务软件包运行在容器内，同时封装了服务的所有代码和依赖关系，可以独立运行，并轻易地在服务器环境之间迁移。

也是受益于容器化架构可以轻易在云环境上运行和扩展，个体微服务同样可以快速部署和迭代更新。然而，随着应用中微服务数量，同一微服务的并行数不断增长，使得微服务之间的通信变得难以想象的复杂。这就需要架构上有一种方式可以动态地连接所有的微服务，从而减少管理和编程开销，于是，新兴的服务网格便应运而生了。

服务网格定义

从广义上讲，服务网格正如Red Hat所描述“一种控制应用程序内的不同模块相互共享数据的方法”。不过，这个描述涵盖了很多不同的内容。实际上，对于熟悉C/S应用的大多数开发人员来讲，这个描述听起来更像是中间件。

但服务网格的独特之处在于，它是为适应分布式微服务环境的独特特性而构建的。在微服务构建的大型应用中，任何给定服务都可能是运行在本地或云端的多个实例上。这种动态的架构显然很难做到，随时让单个微服务与所需要的其他服务建立通信。服务网格则能够自动地实现微服务的瞬间发现和相应服务的连接。让软件开发人员和单个微服务无需考虑这方面的功能和实现。

我们可以将服务网格的作用类比为OSI网络模型中第7级的软件定义网络(SDN)。SDN创建了一个抽象层，使网络管理员不必处理物理网络连接，服务网格则是将应用程序的底层基础设施与软件所交互的抽象体系结构进行了解耦。所以，当开发人员真正开始面对庞大复杂的分布式体系结构的问题的时候、，服务网格的概念就自然而然地产生了。代表性的项目有：首个服务网格项目Linkerd，它是Twitter内部项目的一个分支。以及另一个流行的服务网格项目Istio，它起源于Lyft，得到了许多大企业的支持。(稍后详细地介绍)

服务网格负载均衡

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

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

服务网格 VS Kubernetes

对容器化体系结构有所了解的人，可能想知道Kubernetes(开源容器编制平台)在服务网格方面的情况。况且，Kubernetes的核心意义就是管理容器之间的通信。正如Kublr团队在其公司博客上指出的，您可以将Kubernetes的“Service”资源看作是一种非常基本的服务网格，它提供了服务发现和请求的均衡轮询能力。但是专用的服务网格产品能够提供了更多的功能，例如安全策略管理、加密、对疑似响应慢实例的请求的“断路”挂起、请求的负载均衡等等。但需要始终牢记一点，大多数服务网格实际上都需要像Kubernetes这样的编排系统。服务网格提供的应该是功能的扩展，而不是功能替代。

服务网格 vs API网关

每个微服务都将提供一个应用程序编程接口(API)，用于与其他服务的通信。这就引出了服务网格与传统的API管理形式(如API网关)之间的差异比较。借用IBM的解释，API网关是位于一组微服务和应用“外部”之间，根据需要路由服务请求，让请求者无需知道它所访问的应用程序是基于微服务架构的。但服务网格不仅有上述能力，它还在应用程序“内部”的微服务之间协调请求，且各个组件完全了解整个应用内部的环境。另一种看法就如Justin Warren在《福布斯》中所写的，服务网格用于集群内的东西流量，而API网关用于集群内外的南北流量。

但目前，整个服务网格的概念还是处于很早期和不断变化之中。包括Linkerd和Istio在内的许多服务网格也能够提供南北流量的管理功能。

服务网格的架构

由于服务网格的概念是在最近几年才刚刚提出的，所以对于服务网格所解决的问题，例如管理微服务间通信等存在多种不同的实现方法。其中，对于服务网格创建的通信层应该位于架构的位置，Aspen Mesh的Andrew Jenkins就提出了三种可能的选择，即:

作为一个Lib库，让每个微服务可导入。
部署在节点的代理服务中，为所在节点的全部容器提供服务
与应用容器相并行，运作在一个独立的sidecar容器内。

其中，基于sidecar模式是目前最流行的服务网格模式，以至于在某种程度上讲，它已经成等同于服务网格的模式。虽然这样表达不准确，但是sidecar方法已经得到了非常多的关注，我们也将详细地讨论一下这种架构方法。

服务网格中的Sidecar 容器

在应用容器旁边运行一个sidecar容器意味着什么呢?红帽有一个很好的阐述：服务网格中的每个应用微服务容器都有一个对应匹配的代理容器。服务到服务的通信所需的所有逻辑请求都从微服务中抽象出来，放到了sidecar中处理。

这看起来可能很复杂，实际上，sidecar模式还使得应用程序中的容器数量翻了一倍！但这种设计模式也是简化分布式应用的关键所在。通过将所有网络和通信代码放到一个单独的容器中，使其成为基础设施的一部分，并使开发人员不必将如上的内容视为应用程序的一部分而投入精力处理。

从本质上说，抽象后剩下的也是一个微服务，但它可以非常专注于其业务逻辑。在微服务所运行的复杂环境中，它不需要知道如何与其他的任何微服务实现通信的问题，它只需要知道如何与sidecar通信，然后由sidecar负责余下的工作就可以啦。

服务网格产品：Linkerd、Envio、Istio、Consul

目前，服务网格还没有现成的商业产品，大多数都是开源项目，在部署应用上，需要一定的实施技巧和技术经验。比较有知名度的产品有:

Linkerd( 读作“link-dee”)：2016年发布的元老级项目。Linkerd最初是从Twitter开发的一个库中分离出来的，在领域内的另一个重量级项目Conduit加入后，便形成了Linkerd 2.0的基础。
Envoy ：由Lyft创建，Envoy充当服务网格的“数据平面”，与“控制平面”相匹配，提供比较完整的服务网格服务。
Istio ：由Lyft、IBM和谷歌联合开发而成，是服务于Envoy等代理的“控制平面”。虽然默认是与Envoy成对匹配，但是它们都可以与其他平台配对使用。
HashiCorp Consul ：在 Consul 1.2版本后，推出了名为Connect的功能，这个功能为HashiCorp的分布式系统的服务发现和配置部分，添加了服务加密和基于身份的授权的功能。这个使得使HashiCorp Consul成为非常完整的服务网格。

如何选择适合自己的服务网?这个问题的答案显然超出了本文的范围，但可以肯定的是，上面提到的所有产品都已经在大型和高要求的环境中得到了验证。Linkerd和Istio拥有最广泛的特性集，如果对具体特征有兴趣，建议您可以看看George Miranda对Linkerd、Envoy和Istio特性的分析。由于软件演化迭代迅速，所以请留意他的文章是在Conduit和Linkerd联合之前写的。

同时还需要注意，服务网格是一个新的领域，新的竞争者随时都可能出现。例如，2018年11月，亚马逊就提供了AWS的服务网格App Mesh的公开预览，考虑到AWS的众多零售客户，估计AWS APP Mesh应该会对这个领域产生重大影响。

原文链接：https://www.infoworld.com/article/3402260/how-a-service-mesh-helps-manage-distributed-microservices.html（翻译：易理林）

原文 http://dockone.io/article/9003

正文到此结束