最近几年，软件体系结构领域发生了巨大的变化。我们都见证了这一重大转变，就是将大型的整体应用程序和粗粒度应用程序分解为被称为微服务的细粒度部署单元，主要通过同步REST和gRPC接口以及异步事件和消息传递进行通信。这种架构的好处很多，但缺点同样明显。在“旧世界”中曾经很简单的软件开发过程，例如调试，概要分析和性能管理，现在变得复杂了一个数量级。此外，微服务架构也带来了自己独特的挑战。

服务更具流动性和弹性，并且跟踪它们的实例、它们的版本和依赖关系是一项艰巨的挑战，随着微服务的发展，它的复杂性迅速增加。最重要的是，单个服务可能会孤立地失败，并且这种失败会由于不可靠的网络而进一步加剧。如果系统足够大，则在任何给定时间点，部分系统可能会遭受轻微故障，可能会影响一部分用户，而这往往是在操作员不知情的情况下发生的。拥有如此众多的“活动部件”，如何应对这些挑战并确保系统平稳运行而又既不影响客户，又能避免让开发人员精疲力尽呢？

随着微服务的日益普及，该行业一直在稳步提出各种模式和最佳实践，这些模式和最佳实践使整个体验更佳。弹性模式，服务发现，容器编排，Canary版本，可观察性模式，BFF，API网关…这些是从业人员将用来构建更健壮和可持续的分布式系统的概念。但是这些概念仅仅是抽象概念和模式，它们需要有人在系统中的某个地方实现它们。很多时候，那个“某人”就是你，“某个地方”便是处不在。

一、开始之前

本文旨在提供对Istio的“温和”介绍。所谓“温和”，不是指快速。我们将从基本概念入手，然后浏览一下如何将它们与增量示例结合在一起。请尝试按照顺序执行这些示例，因为某些示例将取决于前面的示例。到最后，您应该了解Istio是什么，可以在哪里使用它，并有信心自己使用它。

本文介绍的材料在Kubernetes知识范围内将被分类为中级或高级。因此对Kubernetes和Docker的掌握至关重要：您应该对Kubernetes核心概念有透彻的实践了解，具有部署和管理容器化工作负载的能力，并可以轻松地使用kubectl导航和更改Kubernetes集群的状态。

二、介绍Istio

Istio是一个服务网格—一种应用程序感知的基础结构层，用于促进服务到服务的通信。“应用程序感知”是指服务网格在某种程度上了解服务通信的本质，可以以增量的方式进行干预。例如，服务网格可以实现弹性模式（重试，断路器），更改流量（调整流量，影响路由行为），以及添加大量全面的安全控制措施。Istio本质上了解服务之间传递的流量，因此还可以提供细粒度的仪表和遥测见解，从而为原本不透明的分布式系统提供一定程度的可观察性。

注意：*服务网格是指*OSI参考模型中的第7层协议，但也可以配置为在第3层和第4层运行。

Istio得到了Google，IBM和Lyft的支持，并且是目前使用最广泛的服务网格体系结构。Kubernetes最初由Google设计，也很好地融入了Istio。因此将Istio标记为“Kubernetes-native服务网格”将是合理的。

像大多数服务网格实现一样，Istio用称为sidecar的代理容器补充了现有的应用程序容器。Sidecar代理是经过特殊配置的Envoy实例，可拦截进入和离开服务容器的网络流量，并通过专用网络重新路由流量，如下所示。

Sidecar代理是针对延迟和吞吐量进行了优化的轻量级组件，具有最小的配置和路由智能。路由决策是基于由单独的控制平面（服务网格的隐喻“大脑”）托管的策略做出的。控制平面包括部署在Kubernetes集群中的一组专用组件-与任何其他容器化应用程序一样，驻留在专用istio-system名称空间中。控制平面的组件有意与数据平面分离，这些元素直接执行应用程序容器的网络流量实际路由和接口。下图说明了这种分离。

笔记：*Sidecar代理模式不是服务网格实现的唯一方法。由Netflix技术套件首创的另一种方法是使用客户端库（Ribbon，Hysterix，Eureka和Archaius）来填充数据平面的角色，并从集中控制平面获取路由提示。这种方法的好处是，与容器编排引擎（或者实际上完全是容器）无关，它可以以嵌入式形式部署在传统的无容器应用程序中。Netflix库的好处也是它的缺点-它们需要对应用程序进行侵入式更改，并为有限的编程语言提供支持，这些编程语言主要针对JVM。

毫不奇怪，基于Sidecar的服务网格在运营和DevOps团队中得到了广泛采用-在现代服务网格设计中，业务逻辑和基础架构之间的高度分离得以实现。

三、核心概念

Istio扩展了具有几种特定于Istio的资源类型的Kubernetes设置的命名法。作为Kubernetes原生服务网格，Istio使用自定义资源定义（CRDs）来实现这些概念。CRDs文件更多的是使用YAML声明配置片段和使用kubectl进行管理，类似于内置的类型，如Pod，Service，Deployment。

一个虚拟服务指定请求是如何入站到一个特定的虚拟主机，并路由到底层的目的地。

虚拟服务将服务使用者与服务提供商之间的耦合程度降到了传统的Kubernetes服务所无法达到的程度，而传统的Kubernetes服务则是基本的负载平衡器。虚拟服务的典型用例包括将请求流量分区到服务的不同版本，这些版本指定为服务子集。

客户端在不了解底层提供程序实现的情况下将请求发送到虚拟服务，然后Envoy根据虚拟服务配置中定义的规则将流量转发到不同版本。例如，“X％的呼叫转到新版本”或“这些用户的呼叫转到Y版本”。精明的读者将把这些用例视为“canary”的部署，其中逐步增加了对新服务版本的访问量，以缓解大爆炸版本的风险。

除了将流量分配给多个基础提供商实现之外，虚拟服务还允许您做相反的工作-将多个完全不同的服务组合到一个虚拟服务中。换句话说，虚拟服务可以充当基本的聚合层，从而消除了对专用反向代理（例如NGINX）的需求。

精心计划的虚拟服务还可以促进StranglerPattern。假设服务合同不变，细粒度的服务路由规则可以针对各个端点，一旦原始端点在整体上已过时，就将请求流量转移到微服务风格的实现中。将匹配规则与基于百分比的流量策略相结合，可以透明地在提供方安排逐步迁移，而服务使用者则不需要做什么。

下面的代码片段提供了虚拟服务的简单示例。

apiVersion:networking.istio.io/v1alpha3kind:VirtualServicemetadata:name:reviewsspec:hosts:-shoppingcart

转载请注明:http://www.aideyishus.com/lkgx/1148.html