应用服务网格（Service Mesh）应对微服务中面临的三种挑战

微服务适用于开发运维（DevOps），可是这些架构依赖的服务到服务通信在生产环境下运行和管理起来很复杂。这时候Service Mesh闪亮登场了：这是企业扩展、保护和监控应用程序的最佳方式。

服务网格定义

Service Mesh是一个专用的软件基础设施层，用于控制和监控微服务应用程序中服务到服务的内部通信，让服务到服务通信变得快速、安全和可靠。它通常表现为“数据平面”和“控制平面”。在这种模式下，开发者（“服务所有者”）并不意识到Service Mesh的存在，而运营者（“平台工程师”）被赋予一套新的工具，以确保可靠性、安全性和可见性。Service Mesh 实际上就是处于 TCP/IP 之上的一个抽象层，它假设底层的 L3/L4 网络能够点对点地传输字节（当然，它也假设网络环境是不可靠的，所以 Service Mesh 必须具备处理网络故障的能力）。

Service mesh 有如下几个特点

1. 应用程序间通讯的中间层；
2. 轻量级网络代理；
3. 应用程序无感知；
4. 解耦应用程序的重试、超时、监控、追踪和服务发现；

Service Mesh 的架构图

在实施微服务过程中，企业正面临着技术和组织挑战的双重挑战。我将集中讨论服务网格所解决的技术挑战，但值得注意的是，服务网格所做的一件事是带来一致性，以便跨团队实现相同的目标，从而减少对某些技能的需求。

每一个附加的微服务增加了操作上的挑战

服务网格通过API来提供微服务的监视、可伸缩性和高可用性，而并没有使用离散设备。服务网格这个灵活的框架消除了与现代应用程序相关的操作复杂性。基础设施服务传统上是作为离散设备实现的，这意味着需要到实际设备获取一个服务。而每个设备都是惟一的，这样很难去监视、扩展和为每个设备提供高可用性。一个服务网格通过API在计算集群本身中提供这些服务，并且不需要任何额外的设备。使用服务网格意味着添加新的微服务不必增加复杂性。

找到性能问题的根本原因很困难

服务网格工具箱提供了一些帮助解决这个问题的东西：

分布式跟踪

跟踪为不同的微服务提供服务依赖分析，并跟踪通过多个微服务跟踪的请求。这也是一种识别性能瓶颈并放大到特定请求的好方法，以定义哪些微服务导致了请求的延迟或哪个服务导致了错误。

度量收集

使用服务网格获得的另一个强大功能是度量收集的能力。度量是了解您的应用程序中发生了什么，以及什么时候它们是健康的，和不健康的关键。服务网格可以从整个网格中收集遥测数据，并为每一跳生成一致的度量。这使得在未来快速解决问题和构建更有弹性的应用程序变得更容易。

不同的开发语言和框架

受访者指出的另一个主要挑战是在一个多语种世界中维护分布式架构的挑战。当从单体架构转向微服务时，许多公司都在头疼处理这样的问题：要让系统运转起来，他们必须使用不同的语言和工具。大型企业更容易受到这样的影响，因为它们有许多大型的分布式团队。服务网格通过提供与编程语言无关的特性来提供一致性，这种特性可以解决多语言环境中的不一致性。在这个环境中，不同的团队，每个团队都有自己的微服务，很可能使用不同的编程语言和框架。网格还提供了一个统一的、应用程序范围的点，用于将可见性和控制引入到应用程序运行时中，将服务通信从隐含的基础设施领域转移到易于查看、监视、管理和控制的地方。

微服务是很酷的，但是服务网格使它们变得更酷。如果您正在进行微服务之旅，并且发现难以应对管理基础设施的挑战，那么服务网格可能是正确的答案。

服务网格 Istio 介绍

Istio是由Google、IBM和Lyft开源的微服务管理、保护和监控框架。Istio为希腊语，意思是”起航“。官方中文文档地址：https://istio.doczh.cn

Istio架构图：

istio-arch

Istio架构分为控制层和数据层。

1. 数据层：由一组智能代理（Envoy）作为sidecar部署，协调和控制所有microservices之间的网络通信。
2. 控制层：负责管理和配置代理路由流量，以及在运行时执行的政策。

Istio架构各个组成部分。

• Envoy：Istio使用Envoy代理的扩展版本，该代理是以C++开发的高性能代理，用于调解service mesh中所有服务的所有入站和出站流量。
• Mixer：Mixer负责在service mesh上执行访问控制和使用策略，并收集Envoy代理和其他服务的遥测数据。
• Istio Manager：Istio-Manager用作用户和Istio之间的接口，收集和验证配置，并将其传播到各种Istio组件。
• Istio-auth：Istio-Auth提供强大的服务间和最终用户认证，使用相互TLS，内置身份和凭据管理。

服务网格使用的Sidecar模式介绍：

将应用程序的组件部署到单独的进程或容器中，以提供隔离和封装。 使用此模式还可以使用异构组件和技术来构建应用程序。

此模式之所以称作Sidecar，是因为它类似于三轮摩托车上的挎斗。 在此模式中，Sidecar附加到父应用程序，为应用程序提供支持性功能。 此外，Sidecar与父应用程序具有相同的生命周期：与父应用程序一起创建，一起停用。 Sidecar模式有时也称为搭档模式，这是一种分解模式。

微信公众号：程序你好