共计 3445 个字符，预计需要花费 9 分钟才能阅读完成。
Istio 中的要害概念
要学习 Istio 须要先明确以下几个要害术语。
1. 容器 / 容器镜像
进入到 云原生时代 的服务网格架构，利用的公布、部署都是围绕 Kubernetes 为代表的容器基础设施开展的。这就须要对 容器 及容器镜像 的概念有清晰的了解。
实际上，容器的遍及要归功于 Docker 技术的风行，而从实质上说容器就是运行在操作系统中的，受资源隔离限度的一组过程，也称为“容器运行时”。它能够将用户打包的代码及其所赖的关系残缺的还原进去。通过容器化运行的应用程序，能够更快、更牢靠地运行，而不受具体计算环境的影响。
容器镜像，是容器化的重要介质和载体。从模式上来说，它就是一个 轻量级的、独立的、可执行的软件包文件，包含了运行应用程序所须要的所有：代码、工具、零碎库及各种设置。
容器技术的呈现，彻底颠覆了利用构建、公布及运行的形式，目前曾经成为服务端利用公布的事实标准。后续要聊到的 Istio 服务网格技术，无论是 “网格根底组件” 还是“应用程序”，都是以容器的形式运行在 Kubernetes 容器平台之上的。
2. 微服务
微服务是一种架构格调，它将一个宏大的单体服务拆分为一组 涣散耦合 的微服务汇合，该微服务汇合提供了与单个单体利用雷同的性能。但微服务能够独立于其余服务进行 独立的开发和部署。此外，微服务是围绕业务能力组织的，能够由较小的团队领有，因而，在开发 / 部署上可能实现更小、更独立的迭代。
目前次要的微服务架构解决方案，以 Spring Cloud 为代表的微服务架构体系是支流；但随着云原生技术概念的风行，以 Istio 为代表的 Service Mesh（服务网格）微服务架构计划也在逐渐失去推广。
3. 管制立体
在以 Spring Cloud 为代表的传统微服务架构中，利用自身与服务治理逻辑是耦合在一起的。而在 Service Mesh（服务网格）计划中，服务治理 规定的治理 、 服务治理行为 、 利用自身 都是相互独立，这就使得利用能够专一于业务，而服务治理逻辑则齐全能够抽离进去由运维团队进行对立的治理。
像这种专门负责服务治理规定治理的 逻辑或组件，在 Service Mesh（服务网格）架构中就叫做“管制立体“。“管制立体”次要由 API 和工具组成，用于治理服务治理行为（数据立体）。服务网格运维人员能够操控管制立体，以配置服务网格中的数据立体行为。例如，将流量配置作用于管制立体——翻译配置并将其推送到数据立体。
4. 数据立体
在 Service Mesh（服务网格）中，数据立体就是具体实现服务治理行为的代理。在 Istio 中数据立体 由负责路由、负载平衡、服务发现、健康检查和受权 / 认证的 Envoy 代理组成。这些代理在每个服务实例的旁边运行（在 k8s 中，与利用容器运行在同一个 Pod），拦挡所有传入和传出的用户流量，并在这一过程中依据管制立体下发的服务治理规定进行流量治理。
5.Envoy
在 Istio 中，数据立体就是由 Envoy 代理实现的。它是一个 古代的、高性能边缘的小型 L7 代理。Envoy 是为大型古代微服务架构设计的，能够与 Nginx 和 HAProxy 等负载均衡器相匹配。
6. 代理
在网络中，代理是一个 两头服务器，位于客户端和服务端之间，能够治理申请和响应。在 Istio 服务网格状况下，代理（Envoy）运行在每个利用实例的后面。当向应用程序发动申请时，代理（Envoy）会拦挡该申请，并将其转发给应用程序实例。同样地，当应用程序实例试图发出请求时，代理（Envoy）也会拦挡出站申请并将其发送到目的地。
因为 代理（Envoy）拦挡了所有申请，所以它能够批改申请，从而实现流量路由、故障注入、受权等性能。
7.L7 代理
L7（第 7 层）代理在 OSI 模型的 应用层 工作。在这一层，代理能够解决每个申请的内容。例如Http 就是一个风行的 L7 协定。因为能够拜访申请的数据，所以 L7 代理（Envoy）就能够依据申请的内容（URL、Cookies 等）做出负载平衡的决定。
Istio 的架构及模块组成
Service Mesh（服务网格）的架构形式为咱们提供了一种 对立的形式来连贯、爱护和察看微服务 。网格内的代理（如 Envoy）能够 捕捉网格内所有的通信申请和指标——每一次失败或胜利的调用、重试或超时的申请都能够被捕捉，并被可视化和报警。
这种将 通信逻辑从业务和应用逻辑中分离出来 的架构形式，能够使开发人员专一于业务逻辑，而服务网格运维人员则专一于服务网格配置。
后面通过对几个要害术语的解释，以及对服务网格架构益处的介绍，置信大家或多或少了解了什么是服务网格。接下来将重点介绍 Istio 这一开源的服务网格实现。
从宏观上看，Istio 次要反对以下性能：
1. 流量治理
流量治理是 Istio 最外围的性能，通过配置，能够管制服务之间的流量——例如设置断路器、超时或重试等服务治理机制，在 Istio 中都能够通过简略的配置扭转来实现。
2. 可察看性
Istio 能够通过跟踪、监控和记录服务间的申请来更好地实现对服务的监控，不便咱们理解服务运行状况，并及时发现和修复问题。
3. 安全性
Istio 能够在代理层面来治理认证、受权和通信的加密，而无需对利用自身造成侵入。而这些平安配置操作只须要通过疾速的配置变更即可实现。
接下来，咱们看下 Istio 的架构组成。如下图所示：
如上图所示，Istio 实现服务网格，依然遵循了将组件拆散成 “管制立体”和“数据立体” 这一常见的分布式系统构建模式。
Istio 中的数据立体由 Envoy 代理组成，管制服务之间的通信。Envoy 是一个用 C ++ 开发的高性能代理。Istio 将 Enovy 代理作为一个 sidecar 容器注入到利用容器的旁边，而后拦挡该服务的所有入站和出站流量。而这些注入利用容器旁边的 Enovy 代理组合在一起就形成了 Istio 服务网格的数据立体。
Istiod则是 Istio 的管制立体组件，次要提供服务发现、配置和证书治理等性能。Istiod 采纳 YAML 文件格式来编写流量管制规定，并将其转换为 Envoy 的可操作配置，之后通过 xDS 协定 将配置流传给网格中的所有 sidecar 代理。
Istiod 次要由 Pilot、Citadel、Galley 这三个组件组成。其中 Pilot 形象了特定平台的服务发现机制（如 Kubernetes、Consul 或 VM），并将其转换为能够被 sidecar 应用的规范格局。Citadel 则是 Istio 的外围平安组件，实现证书受权、证书生成，实现数据立体中 sidecar 代理之间的 mTLS 平安通信。
而 Galley 则次要服务配置管理，包含验证配置信息的格局和内容正确性，并将这些配置信息提供给 Pilot 等其余管制立体组件应用。
Istio 的流量治理实现
Istio 流量治理示意图如下：
如上图所示，要在 Istio 服务网格中实现流量治理，须要通过 VirtualService（虚构服务） 及DestinationRule（路由规定）资源来治理流量路由规定。
而具体的路由规定流量的执行由 Istio 网关资源来实现。其中 Ingress Gateway（入口网关） 和Egress Gateway（进口网关）是 Istio 服务网格组件的一部分，这两个网关都运行着一个 Envoy 代理实例，它们在服务网格的边缘作为负载均衡器运行，入口网关接支出站连贯，而进口网关则接管从集群进来的连贯。
须要留神，这里了解入口网关和进口网关的概念不要广义的了解为就是 Istio 服务网格的边缘入口和进口。对于 Istio 服务网格来说除了内部流量的进出能够通过 VitrualService（虚构服务）关联 Gateway（网关资源）来实现流量路由 外，网格之间也能够通过该形式来实现流量的路由。
所以，在应用 Istio 服务网格来实现微服务的流量治理时，能够依据场景来别离创立针对内部流量的 Gateway+VirtualService 资源，以及针对具体微服务网格间流量的 Gateway+VirtualService 资源，并通过 VitrualService 随时批改相应的路由规定。
而对于 Gateway 网格资源的创立来说，则依据是管制入口流量还是进口流量来抉择关联 Ingress Gateway（入口网关）还是 Egress Gateway（进口网关）。
最初总结
以上内容就是对 Istio 服务网格实现流量治理外围逻辑的简略介绍，也是为了不便大家了解之前文章中的一些操作。尽管目前以 Istio 服务网格架构还没有齐全代替 Spring Cloud 微服务体系，但服务网格这种将管制立体和数据立体拆散的架构思维，将是将来微服务架构的支流。