微服务的EnvoyIstio和Kubernetes

Posted 2021-04-13 云技术实践

我们使用微服务架构构建商业的IT系统，使企业业务更加灵活的快速转变，更容易构建新的功能，并在竞争中保持领先优势。微服务并不大家想的那么简单，还有很多困难的部分，微服务基于分布式系统，分布式系统就不简单。

Kubernetes已经成为主流，高兴的是Kubernetes和OpenSHIFT这样的平台，已经成为我们基础设施的一部分；但当开始建立网络体系结构和应用程序时，必须要解决一些重要的分布式系统问题。

当我们向服务发送一个消息会发生什么呢？请求会被分割成比较小的块，通过一系列的节点，网关和防火墙等在网络上传输。带着这种分布式计算的错误，应用程序在异步网络进行通信时，缺少时间同步，每个服务都有自己的时间，异步网络基于路径是否呆用，是否拥塞，是否有硬件故障来路由分组，就不能保证消息在有限时间内到达目的地。所以网络不可控。

随着我们转向服务架构，将复杂性推向了服务之间的部分。这些需要解决的应用程序网络复杂性包括：

●服务发现

●重试

●超时

●负载均衡

●限速

●线程bulkheading

●断路

这些都是横向关注的问题，无论实施情况如何，都适用于服服务，服务可用Java，Go，Python或Node.js编写，应该同语言没关系；应用程序网络的实现应该对应用程序是透明的。 当网络和应用问题确实发生时，应该很容易确定问题的根源。

如果我们能够在一个地方实现此功能一次，并让任何语言/框架/来调用它，该怎么办？

服务网格

服务网格是服务之间的分散式应用程序网络基础架构，提供弹性，安全性，可观察性，路由控制以及最重要的是了解一切运行情况。 业务程网状，由一个数据平面和一个控制平面组成，代理构成数据平面，应用程序之间的流量通过这些代理流动。 控制平面负责管理和配置代理以路由流量，以及在运行时执行策略。

服务网格已经成为帮助服务交流范例。 它使我们能够以最小的开销和高度分散的方式将应用程序网络功能集成到基础架构中，并能够控制，配置和监视应用程序级别的请求，解决一些问题。

随着服务体系结构变得越来越异构，将服务实现限制到特定的库、框架甚至语言变得更加困难（或不切实际）。随着服务网格的发展，我们看到了一些弹性模式，比如电路中断，在基础设施中实现为语言/框架无关的解决方案。

通过服务网格，我们明确地将应用程序网络功能与应用程序代码和业务逻辑分开，并且我们将它向下推进到基础架构中 - 类似于我们对网络堆栈，TCP等的处理方式。

使用Envoy代理

开启代理，您可以将功能抽象为单个二进制文件，并将其应用于所有服务，而不管您使用何种语言，并让所有流量都通过中心点运行。 同样，这构成了服务网格中的数据平面。 这反过来：

●实现异构体系结构。

●移除此功能的应用程序特定实现。

●一致地强制执行这些属性。

●正确地执行这些属性。

●提供选择插入以及安全网。

Envoy代理是一个很好的例子。 Envoy最初建于Lyft，是一个高性能的代理服务，为服务网格提供了基础。 它与应用程序并行运行，通过以平台无关的方式提供通用功能来抽象网络。 当基础架构中的所有服务流量都通过Envoy网格时，通过一致的可观测性，很容易地查看问题区域，调整整体性能并在一个位置添加特殊。

像Envoy这样的服务代理可以帮助将弹性，服务发现，路由，指标收集等的责任推到应用程序下的一层。 否则，我们冒着希望并祈祷各种应用程序将正确实现这些关键功能或依靠特定于语言的库来实现这一目标。

代理体系结构在使用服务体系结构的大多数堆栈中提供了两个关键部分 - 强大的可观察性和易于调试。有了这些工具，开发人员就可以专注于另一个重要方面：业务逻辑。

再说istio服务

通过将特定于语言的低级基础设施问题从应用程序转移到服务网格中，使Istio.io成为构建微服务的下一个步骤，使开发人员能够专注于业务逻辑。 它用作配置一组Envoy代理的控制平面。 虽然Istio最初是为支持Kubernetes而编写的，但它并不依赖于Kubernetes，可以在任何平台上运行，包括跨多个平台的混合架构。

该项目最初由Google，Lyft和IBM赞助，并使用Envoy代理的扩展版本，该代理被部署为同一Kubernetes相关服务。 作为实现服务网格功能的一种方式，它已经引起了开源社区的注意。 这些功能包括将应用网络问题推送到基础架构中：重试，负载平衡，超时，截止日期，断路，相互TLS，服务发现，分布式跟踪等。

Istio最重要的方面之一是它能够控制服务之间的流量路由。 通过对应用级流量进行细粒度控制，我们可以做一些有趣的弹性处理，例如绕过故障路由，在必要时路由到不同的可用区域，更重要的是，还可以控制部署流量，以便减少系统改变的风险。

Istio支持多个高阶群集语义，包括：

●服务可观测性

●逐步部署和发布

●政策执行

●集群可靠性

●混沌测试

●快速配置

●强大的安全选项

下一步工作

还是摸索中。 在一个服务网格中，我们说我们的应用程序应该知道程序网络的功能，但它们不应该在应用程序代码中实现。 要使应用程序更精确地了解应用程序网络功能/服务网格层正在做什么，有一点值得一提。 我们很可能会在某些情况下看到库/框架的构建。

例如，如果Istio服务网格引发断路器，重试某些请求或因特定原因失败，那么应用程序可以更好地了解这些方案或情况。 我们需要一种方法来捕获这些信息并将其传回服务。 另一个例子是在服务之间传播跟踪上下文（像OpenTracing这样的分布式跟踪），并透明地完成这一过程。 我们可能会看到的是这些精简的应用程序/语言特定的库，它们可以使应用程序/服务更加智能化，并允许它们采取针对错误的追索。

不管哪种方式，我们现在开始看到Envoy和Istio的实施部署已经通过Kubernetes和Red Hat OpenShift部署到生产环境中，迄今为止的反馈都是好的。 Istio在某些情况下甚至帮助建立刚刚进入该领域的人员，甚至跨越两三代微服务工作。 因此，虽然我们仍处于开始阶段，但有许多不同的方式可以以最适合应用程序的方式来设置相关技术。

译者介绍

张伟，从事过多年的软件开发工作，精通Linux系统管理，曾经做过RHCE培训讲师、熟悉公有云、私有云（OpenStack）的体系架构、熟悉OpenStack、安装部署、系统运维、系统开发，拥有多年的私有云安装部署运维经验，主编了《深度实践OpenStack》系列教材（18年3月出版）。

↓↓↓ 点击"阅读原文" 【加入云技术社区】

相关阅读：