Istio微服务治理笔记(一)

一 背景

1.1 微服务是什么

• 服务之间有轻量级的通信机制，一般为REST API
• 去中心化的管理机制
• 每一个服务可使用不一样的编程语言实现，使用不一样的数据存储技术
• 应用按业务拆分红服务，一个大型应用系统能够由多个独立的服务组成
• 各个服务都可独立部署，都有本身的业务逻辑
• 服务可被多个应用共享，其余服务可复用一些公共的资源服务

1.2 微服务的优点

• 模块化开发，以单哥服务为组件进行更新升级，提高系统总体异常稳定性

• 模块化开发管理方便，单独团队开发维护，职责分明

• 模块服用，公共服务模块可被其余业务模块使用

• 系统架构更加分明

• 结合CI/CD，实现DevOPS

• 弹性伸缩，结合服务编排K8S动态HPA

• 服务熔断/降级，避免但节点异常雪崩效应，分散故障节点

1.3 微服务带来的挑战

• 服务愈来愈多，配置管理维护复杂
• 服务间依赖关系复杂
• 服务调用链追踪难
• 服务之间的负载均衡
• 服务的拓展
• 服务监控/日志
• 服务熔断/降级
• 服务鉴权
• 服务上线与下线
• 服务文档
• ...

1.4 什么是微服务治理

针对以微服务为咱们带来的方便以及挑战，从裸金属到虚拟化再到公有云，再到容器，到serverless，技术不断革新，应对微服务带来的挑战，如何对服务进行注册发现，请求链路追踪，负载均衡，服务熔断/降级，服务限流，访问控制，监控日志，配置管理，金丝雀发布呢，本文为本身学习Istio的笔记，istio解决了一些问题，还有一些挑战须要其余工具平台解决，本文后续更新不断，一块来学习Kubernetes中服务治理神器Istio。

二 Istio介绍

2.1 istio是什么

Istio 容许您链接、保护、控制和观测微服务，在较高的层次上，Istio 有助于下降这些部署的复杂性，并减轻开发团队的压力。它是一个彻底开源的服务网格，能够透明地分层到现有的分布式应用程序上。它也是一个平台，包括容许它集成到任何日志记录平台、遥测或策略系统的 API。Istio 的多样化功能集使您可以成功高效地运行分布式微服务架构，并提供保护、链接和监控微服务的统一方法。

1.2 什么是service mesh

在从单体应用程序向分布式微服务架构的转型过程当中，开发人员和运维人员面临诸多挑战，使用 Istio 能够解决这些问题。

服务网格（Service Mesh）这个术语一般用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增加，服务网格愈来愈难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及一般更加复杂的运维需求，例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。

Istio 提供了一个完整的解决方案，经过为整个服务网格提供行为洞察和操做控制来知足微服务应用程序的多样化需求。

1.3 为何使用istio

Istio 提供一种简单的方式来为已部署的服务创建网络，该网络具备负载均衡、服务间认证、监控等功能，只须要对服务的代码进行一点或不须要作任何改动。想要让服务支持 Istio，只须要在您的环境中部署一个特殊的 sidecar 代理，使用 Istio 控制平面功能配置和管理代理，拦截微服务之间的全部网络通讯：

• HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡。
• 经过丰富的路由规则、重试、故障转移和故障注入，能够对流量行为进行细粒度控制。
• 可插入的策略层和配置 API，支持访问控制、速率限制和配额。
• 对出入集群入口和出口中全部流量的自动度量指标、日志记录和追踪。
• 经过强大的基于身份的验证和受权，在集群中实现安全的服务间通讯。

Istio 旨在实现可扩展性，知足各类部署需求。

三 核心功能

3.1 流量管理

经过简单的规则配置和流量路由，您能够控制服务之间的流量和 API 调用。Istio 简化了断路器、超时和重试等服务级别属性的配置，而且能够轻松设置 A/B测试、金丝雀部署和基于百分比的流量分割的分阶段部署等重要任务。

经过更好地了解您的流量和开箱即用的故障恢复功能，您能够在问题出现以前先发现问题，使调用更可靠，而且使您的网络更增强大——不管您面临什么条件。

• 负载均衡
• 动态路由
• 灰度发布
• 故障注入

3.2 安全

Istio 的安全功能使开发人员能够专一于应用程序级别的安全性。Istio 提供底层安全通讯信道，并大规模管理服务通讯的认证、受权和加密。使用Istio，服务通讯在默认状况下是安全的，它容许您跨多种协议和运行时一致地实施策略——全部这些都不多或根本不须要应用程序更改。

虽然 Istio 与平台无关，但将其与 Kubernetes（或基础架构）网络策略结合使用，其优点会更大，包括在网络和应用层保护 pod 间或服务间通讯的能力。

• 认证
• 鉴权

3.3 可观察行

Istio 强大的追踪、监控和日志记录可以让您深刻了解服务网格部署。经过 Istio 的监控功能，能够真正了解服务性能如何影响上游和下游的功能，而其自定义仪表板能够提供对全部服务性能的可视性，并让您了解该性能如何影响您的其余进程。

Istio 的 Mixer 组件负责策略控制和遥测收集。它提供后端抽象和中介，将 Istio 的其他部分与各个基础架构后端的实现细节隔离开来，并为运维提供对网格和基础架构后端之间全部交互的细粒度控制。

全部这些功能可让您能够更有效地设置、监控和实施服务上的 SLO。固然，最重要的是，您能够快速有效地检测和修复问题。

• 调用链
• 访问日志
• 监控

3.4 平台支持

stio 是独立于平台的，旨在运行在各类环境中，包括跨云、内部部署、Kubernetes、Mesos 等。您能够在 Kubernetes 上部署 Istio 或具备 Consul 的 Nomad 上部署。Istio 目前支持：

• 在 Kubernetes 上部署的服务
• 使用 Consul 注册的服务
• 在虚拟机上部署的服务

3.5 集成和定制

策略执行组件能够扩展和定制，以便与现有的 ACL、日志、监控、配额、审计等方案集成。

四 架构

Istio 服务网格逻辑上分为数据平面和控制平面。

• 数据平面由一组以 sidecar 方式部署的智能代理（Envoy）组成。这些代理能够调节和控制微服务及 Mixer 之间全部的网络通讯。
• 控制平面负责管理和配置代理来路由流量。此外控制平面配置 Mixer 以实施策略和收集遥测数据。

4.1 架构图

4.2 组件

4.2.1 Envoy

Istio 使用 Envoy 代理的扩展版本，Envoy 是以 C++ 开发的高性能代理，用于调解服务网格中全部服务的全部入站和出站流量。Envoy 的许多内置功能被 Istio 发扬光大，例如：

• 动态服务发现
• 负载均衡
• TLS 终止
• HTTP/2 & gRPC 代理
• 熔断器
• 健康检查、基于百分比流量拆分的灰度发布
• 故障注入
• 丰富的度量指标

Envoy 被部署为 sidecar，和对应服务在同一个 Kubernetes pod 中。这容许 Istio 将大量关于流量行为的信号做为属性提取出来，而这些属性又能够在 Mixer 中用于执行策略决策，并发送给监控系统，以提供整个网格行为的信息。

Sidecar 代理模型还能够将 Istio 的功能添加到现有部署中，而无需从新构建或重写代码。能够阅读更多来了解为何咱们在设计目标中选择这种方式。

4.2.2 Mixer

• 概念

Mixer 是一个独立于平台的组件，负责在服务网格上执行访问控制和使用策略，并从 Envoy 代理和其余服务收集遥测数据。代理提取请求级属性，发送到 Mixer 进行评估。有关属性提取和策略评估的更多信息，请参见 Mixer 配置。

Mixer 中包括一个灵活的插件模型，使其可以接入到各类主机环境和基础设施后端，从这些细节中抽象出 Envoy 代理和 Istio 管理的服务。

• 架构图

  

4.2.3 Pilot

• 概念

Pilot 为 Envoy sidecar 提供服务发现功能，为智能路由（例如 A/B 测试、金丝雀部署等）和弹性（超时、重试、熔断器等）提供流量管理功能。它将控制流量行为的高级路由规则转换为特定于 Envoy 的配置，并在运行时将它们传播到 sidecar。

Pilot 将平台特定的服务发现机制抽象化并将其合成为符合 Envoy 数据平面 API 的任何 sidecar 均可以使用的标准格式。这种松散耦合使得 Istio 可以在多种环境下运行（例如，Kubernetes、Consul、Nomad），同时保持用于流量管理的相同操做界面。

• 架构图

4.2.4 Citadel

• 概念

Citadel 经过内置身份和凭证管理赋能强大的服务间和最终用户身份验证。可用于升级服务网格中未加密的流量，并为运维人员提供基于服务标识而不是网络控制的强制执行策略的能力。从 0.5 版本开始，Istio 支持基于角色的访问控制，以控制谁能够访问您的服务，而不是基于不稳定的三层或四层网络标识。

• 架构图

4.2.5 Galley

Galley 表明其余的 Istio 控制平面组件，用来验证用户编写的 Istio API 配置。随着时间的推移，Galley 将接管 Istio 获取配置、 处理和分配组件的顶级责任。它将负责将其余的 Istio 组件与从底层平台（例如 Kubernetes）获取用户配置的细节中隔离开来。

4.3 设计目标

• 最大化透明度：若想 Istio 被采纳，应该让运维和开发人员只需付出不多的代价就能够从中受益。为此，Istio 将自身自动注入到服务间全部的网络路径中。Istio 使用 sidecar 代理来捕获流量，而且在尽量的地方自动编程网络层，以路由流量经过这些代理，而无需对已部署的应用程序代码进行任何改动。在 Kubernetes中，代理被注入到 pod 中，经过编写 iptables 规则来捕获流量。注入 sidecar 代理到 pod 中而且修改路由规则后，Istio 就可以调解全部流量。这个原则也适用于性能。当将 Istio 应用于部署时，运维人员能够发现，为提供这些功能而增长的资源开销是很小的。全部组件和 API 在设计时都必须考虑性能和规模。
• 可扩展性：随着运维人员和开发人员愈来愈依赖 Istio 提供的功能，系统必然和他们的需求一块儿成长。虽然咱们指望继续本身添加新功能，可是咱们预计最大的需求是扩展策略系统，集成其余策略和控制来源，并将网格行为信号传播到其余系统进行分析。策略运行时支持标准扩展机制以便插入到其余服务中。此外，它容许扩展词汇表，以容许基于网格生成的新信号来执行策略。
• 可移植性：使用 Istio 的生态系统将在不少维度上有差别。Istio 必须可以以最少的代价运行在任何云或预置环境中。将基于 Istio 的服务移植到新环境应该是垂手可得的，而使用 Istio 将一个服务同时部署到多个环境中也是可行的（例如，在多个云上进行冗余部署）。
• 策略一致性：在服务间的 API 调用中，策略的应用使得能够对网格间行为进行全面的控制，但对于无需在 API 级别表达的资源来讲，对资源应用策略也一样重要。例如，将配额应用到 ML 训练任务消耗的 CPU 数量上，比将配额应用到启动这个工做的调用上更为有用。所以，策略系统做为独特的服务来维护，具备本身的 API，而不是将其放到代理/sidecar 中，这允许服务根据须要直接与其集成。

参考连接

• juejin.im/post/5a3f20…
• juejin.im/post/5acb0d…
• juejin.im/post/5a727e…
• segmentfault.com/a/119000001…