【译文连载】 理解Istio服务网格（第一章 概述）

书籍英文版下载链接为 https://developers.redhat.com/books/introducing-istio-service-mesh-microservices/，作者 Burr Sutter 和 Christian Posta。 

第一章 概述

中文翻译  刘世民 @2020.02

 

如果你正在寻找带有详细示例的有关Istio的介绍性文档，那这本书正好合适你。本书适合正在基于微服务架构开发云原生应用的应用架构师和开发团队组长们阅读。本书假设你已有Docker使用经验；因为Istio已在多个Linux容器编排项目中被用到，本书聚焦在Kubernetes和OpenShift中使用Istio。本书中，我们会不加区分地使用Kubernetes和OpenShift这两个术语（OpenShift是红帽公司发布的Kubernetes发行版本）。 

如果你需要一本介绍基于Spring Boot和Thorntail（之前被称为WildFly Swarm）的Java微服务的书，我推荐你阅读由Christian Posta写作的Microservices for Java Developers（O’Reilly）一书。

如果你对响应式微服务（reactive microservice）感兴趣，那我推荐你从阅读Clement Escoffier所作的Build Reactive Microservices in Java（O’Reilly）一书开始。这书详细介绍了Vert.x，这是一个使用JVM的响应式微服务编程套件。 

另外，本书还假设你已有一些Kubernetes/OpenShift使用经验；如果还没有，那我推荐你阅读由Grant Shipley 和 Graham Dumpletion写作的OpenShift for Developers（面向开发者的OpenShift，O’Reilly）一书。我们会在OpenShift环境中部署、配置和使用Istio；然而，我们所用到的大多数命令都可以直接在Kubernetes中使用。 

我们现在来看下Istio可以帮助开发者解决哪些困难，然后介绍它的主要组件。 

1.1 前方的挑战 

当前，软件开发领域正处于数字化转型时代，正在追求更好地服务客户和用户。如今的数字化创造者，也就是应用程序员们，不仅已通过运用Agile标准进入更快的开发周期，而且还在不断追求更快的开发速度。尽管单体应用有可能每月或每周做一次部署，但是，通过将大型单体应用拆分为更小的单元，将大型开发团队拆分为更小的小组，采用小组间无依赖的工作流、管理模型和开发流水线，我们还可能取得更快的产品交付速度。业界将这称为微服务架构。 

关于使用微服务而会面临的各种挑战已有很多报道，首当其冲的，是将它和分布式计算（distributed computing）混为一谈。最大的假象是“网络是可靠的”。微服务通过网络（即微服务之间的连接）进行有效通信。这是过去几十年来大多数企业软件制作方式的根本变化。当你将网络依赖性添加到应用程序的逻辑中时，就会导致很多潜在风险，这些风险与应用程序所依赖的连接数量成指数性增长，而不是成倍增加。 

很容易理解的是，当部署周期从每几个月一次显著提升到每周甚至可能每天数十次时，挑战会层出不穷。 

一些大型互联网公司不得不开发特殊的框架和库来帮助缓解不可靠的网络、易失性的云主机以及海量代码量所带来的挑战。例如，像Netflix这样的公司创建了Ribbon、Hystrix和Eureka等项目来解决这种问题。Twitter和Google等其他公司也做了类似的事情。他们创建的这些框架具有非常强的语言和平台依赖性，因此，当使用这些框架不支持的编程语言时，这些框架将很难用得上。每当这些框架更新后，还需要相应地更新应用程序。最后，即使他们为每种语言运行时在框架中都增加了支持，在使用过程中也会有大量开销。至少在Netflix中，这些库的创建是在虚拟机（VM）作为主要可部署单元的情景中，它们只能在单个云平台和单个应用程序运行时（Java虚拟机）上实现标准化。大多数公司不能也不会这样做。 

Linux容器（例如Docker）和Kubernetes / OpenShift的出现，使得DevOps团队通过在高度自动化的流水线中使用快速流转的不可变镜像来获得更高的速度。现在，开发团队管理流水线的方式独立于容器内运行的语言或框架。OpenShift使我们能够为一组复杂的分布式多语种工作负载提供更好的弹性和整体管理。OpenShift确保开发人员可以轻松部署和管理数百个甚至数千个微服务。这些服务被打包为在Kubernetes Pod中运行的容器，并带有它们各自的语言运行时（例如Java Virtual Machine，CPython和V8）及其所有必要的依赖库，通常以特定语言的框架的形式出现（例如Spring或Express）和库（例如jar或npms）。但是，OpenShift并不介入在各个Pod中运行的应用程序组件之间的交互。这是架构师和开发人员所面临的挑战。快速部署和管理多语言服务的工具和基础架构已经成熟，但是当处理这些服务之间的交互时，我们却缺少类似功能。在这里，Istio这种服务网格将使你作为应用程序开发人员可构建更好的软件并比以往更快地交付它。 

1.2 初始Istio 

Istio是一种服务网格（service mesh）的实现。服务网格是服务之间的连接组织，带有一些附加功能，例如流量控制、服务发现、负载平衡、弹性、可观察性和安全性等。服务网格使得应用程序从代码中卸载这些功能，以让开发人员专注于业务逻辑。 

Istio一开始就被设计为可跨部署平台工作的，同时它具有一流的对Kubernetes的集成性支持。 

就像Kubernetes生态系统中的许多开源项目一样，Istio是希腊航海术语，意为“风帆”，就像Kubernetes本身是希腊语中的“舵手”或“船上驾驶员”一样。有了Istio后，人们对服务网格概念的兴趣与日俱增，而Kubernetes / OpenShift离开的地方就是Istio的起点。Istio为开发人员和架构师提供了丰富的声明式服务发现和路由功能。在Kubernetes / OpenShift的服务（service）组件为你提供默认的轮询（round-robin）负载均衡功能时，Istio允许你在网格内的所有服务之间引入唯一且细粒度的路由规则。Istio还为我们提供了强大的可观察性，以能更深入地研究分布式微服务间的网络拓扑，了解它们之间的流（跟踪）并能够即时查看关键指标。

既然网络实际上并不总是可靠的，那么，就需要对微服务间的关键链路进行更严格的监控和操作。Istio为我们提供了网络层的弹性功能，例如重试、超时以及各种断路器功能。 

Istio还为开发人员和架构师提供了实践混沌工程学的能力。在第5章中，我们描述了Istio推动混沌注入的能力，以便你可以看到整个应用程序及其潜在的数十种相互依赖的微服务的弹性和健壮性。 

在开始讨论之前，我们想确保你对Istio有基本的了解。以下部分将概述Istio的基本组件。

1.3 理解Istio组件 

Istio服务网络主要包含两个平面：数据平面（data plane）和控制平面（control plane），如图1-1所示。

 

 图1-1 Istio的数据平面和控制平面

1.3.1 数据平面 

数据平面的实现方式是拦截所有入站（ingress，入口）和出站（egress，出口）网络流量。你的业务逻辑、应用程序和微服务都不会觉察到这种拦截。你的微服务可使用简单框架在整个网络上调用远程HTTP端点（例如Spring RestTemplate或JAX-RS客户端），并且大多数情况下对这种拦截带来的众多有趣能力全然不知。图1-2描述了Istio出现之前的典型微服务。

 

 

 图1-2 Istio出现前的微服务架构 

Istio服务网格的数据平面由以边车容器（sidecar container）形式运行的istio-proxy实例组成，如图1-3所示。

 

图1-3 Evoy边车（istio-proxy）

服务代理 

服务代理（Service proxy）增强了应用程序服务。每当需要通过网络进行通信时，应用程序服务就会通过服务代理进行调用。服务代理充当中介或拦截器，可以添加诸如自动重试、断路器、服务发现和安全性等功能。Istio的默认服务代理基于Envoy代理。 

Envoy代理是Lyft开发的第7层（L7）代理（请参阅Wiki上的OSI模型），目前Lyft在生产环境中使用该代理每秒处理数百万个请求。它使用C ++编写，经过了实战测试，性能高和轻量级。它提供诸如HTTP1.1，HTTP2和gRPC的负载平衡功能。它具有收集请求级别指标和跟踪范围（trace span）能力，提供服务发现和注入故障等功能。你可能会注意到Istio的某些功能与Envoy重叠。由于Istio使用Envoy来实现这些功能，因此这一点很好理解。 

但是Istio如何将Envoy部署为服务代理呢？Istio使用一种称为边车（sidecar）的部署技术，使服务代理功能与应用程序代码尽可能靠近。 

边车（Sidecar） 

当Kubernetes / OpenShift诞生时，它们并没有像人们原本期望的那样将Linux容器用作可运行和可部署单元。相反，它创造了Pod概念，这是在Kubernetes / OpenShift世界中被管理的主要目标。为什么需要Pod呢？有人认为这借鉴了1956年的电影《Invasion of the Body Snatchers》，但实际上借鉴了家庭或鲸鱼概念。鲸鱼是与Docker开源项目相关联的早期映像，该项目是那个时代最流行的Linux容器解决方案。Pod可以是一组Linux容器。Sidecar是另一个Linux容器，直接与你的业务逻辑应用程序或微服务容器并存。在现实世界中，边车被固定在摩托车的一侧作为一简单附属品；与之不同的是，Istio中的边车可以接管车把和油门。 

使用Istio，可以将第二个Linux容器“ istio-proxy”（也称为Envoy服务代理）手动或自动注入到容纳你的应用程序或微服务的pod中。该边车负责拦截来自业务逻辑容器的所有入站（入口）和出站（出口）网络流量，这意味着可以应用新策略来重新路由传入或传出的流量，还可以应用诸如访问控制列表之类的策略（ ACL）或速率限制，还会抓取监视和跟踪数据（Mixer），甚至引入一些混乱，例如网络延迟或HTTP错误。 

1.3.2 控制平面 

控制平面负责成为配置和策略的中心，并使数据平面在群集中变得可操作，该群集可能由分散在多个节点上的数百个Pod组成。Istio的控制平面包括Istio的三项主要服务：Pilot，Mixer和Citadel。 

Pilot 

Pilot是一个Istio组件，它负责管理在Kubernetes / OpenShift集群中运行的所有微服务的边车。Istio Pilot将每个独立的istio-proxy微服务包装成Linux容器并在应用程序pod中运行，并具有整体拓扑的实时视图和保持更新的“路由表”。Pilot提供了服务发现等功能，以及对VirtualService的支持。VirtualService使你可以进行细粒度的请求分发、重试、超时等。我们将在第3章和第4章中对此进行详细介绍。 

Mixer 

顾名思义，Mixer是将事物整合在一起的Istio服务。每个分布式istio-proxy将遥测数据传递回Mixer。此外，Mixer维护整个微服务套件使用和访问策略的规范模型。使用Mixer，你可以创建策略，应用速率限制规则，甚至抓取自定义指标。Mixer具有可插拔的后端体系结构，并随着新插件和合作伙伴的发展而迅速发展，这些插件和合作伙伴以许多新颖有趣的方式扩展了Mixer的默认功能。Mixer的许多功能超出了本书的范围，但我们会在第6章中介绍可观察性，在第7章中介绍了安全性。 

Citadel 

Istio Citadel组件（以前称为Istio CA或Auth）负责证书签名、颁发、吊销及轮换。Istio向所有微服务颁发X.509证书，从而允许服务间进行双向传输层安全（mTLS）通信并透明地加密所有流量。它使用内置在基础平台中的身份，并将其构建到证书中。此身份使你可以执行策略。第7章讨论了设置mTLS的示例。  

本英文译稿版本由本人所有。水平有限，错误肯定是有的，还请海涵。 

感谢您的阅读，欢迎关注我的微信公众号：