一、Istio 流量治理基本介绍

1.1 流量治理演进

上一代微服务框架，大部分流量治理方案是将流量治理策略集成在 SDK 中，该类微服务框架以 Java 语言为主，比如，SpringCloud，Dubbo 等等，此类框架对于非 Java 语言的开发者不是特别友好，还缺少灵活性，并且流量治理策略一般是静态配置，不过还是有少数配置是支持动态配置的。

对于 Istio 的流量治理方案，其流量治理策略完全通过 Sidecar 的方式实现，也就是说我们开发应用所使用的语言和 Sidecar 的语言是毫不相干的，Sidecar 对于应用来讲也是无感知的，无需应用做任何配置和代码入侵，对于开发者来说只要关注自己的应用就可以，无需考虑如何接入以及使用什么开发语言开发应用，极大了降低开发的学习成本，最后，Istio 的使用非常灵活，并且支持动态配置，也是即时生效。

下图就是 Istio 的 Sidecar 方式：

1.2 Istio 流量治理基本介绍

流量治理的主要功能包括，熔断、降级，超时，重试，A/B 测试，金丝雀发布，基于权重的流量切分，故障检测与恢复。

Istiod 生成 xDS 配置，然后通过 gRPC 连接发送给所有的 Envoy，等待 Envoy 加载之后就能按照上层的配置进行工作。

二、Istio 流量治理深度剖析

2.1 VirtualService

VirtualService 是 Istio 中最重要的路由 API。它允许我们配置如何将请求路由到 Istio 服务网格中的服务，构建在 Istio 与平台提供的基本连接和发现之上。没有 VirtualService 的话，Istio 也可以按照基本的负载均衡策略将流量分发到所有的实例，在 Istio 中共如下4种策略分发请求：ROUND_ROBIN（循环）、LEAST_CONN（最小连接）、RANDOM（随机）、PASSTHROUGH（直连）。如果有了 VirtualService 之后会有什么新技能呢？不仅可以将请求按照比例或权重（weight）分发到一组或多组实例，还可以根据请求属性（header，method，uri），将请求路由到不同的服务实例组，比如，灰度发布。

2.2 VirtualService 基本属性一

• Host：选择目标服务，VirtualService 应用到目标服务上。它可以是IP地址、DNS名称，也可以是短名称，如果是短名称会被隐式或显式解析为全限定域名（FQDN）***.default.svc.cluster.local。
• Match：匹配 HTTP 属性 Header，Authority，URI，Method，QueryParam。
• Host：目标服务。
• Subnet：通过 DestinationRule 定义的服务实例集合。
• Weight：流量权重分配。

下面我们可以结合一个 yaml 文件看一下 VirtualService 的这些属性是如何使用：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
      end-user:
        exact:jason
      route:
      - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v3
      weight: 75
    - destination:
        host: reviews
        subset: v3
      weight: 75

2.2 VirtualService 基本属性二

• Timeout：HTTP 超时时间。为了保证 Istio 不会无限的等待服务响应，可以通过其设置 Istio 层面的最长等待时间。
• Retries：HTTP 重试策略。为给定的失败场景进行重试操作，增加了服务的可用性，不会因为服务的短暂不可用而导致立即返回错误，而是有限次数的进行重试请求。
• Fault：HTTP 故障注入。可以增加服务的健壮性，通过故障注入测试应用的故障恢复能力。

2.3 Header manipulation

VirtualService 允许我们修改请求响应中的 Header 信息，

• set：使用给定的键值覆盖 header 中的键值。
• add：在 header 中增加键值对。
• remove：通过 key 删除 header 中指定的键值。

2.4 DestinationRule

• 常常与 VistualService 配合使用，VistualService 定义一些策略将流量路由到某些目标服务，而 DestinationRule 允许用户针对目标服务配置一些负载均衡，异常检测，连接池以及证书。
• 特别是利用 DR Subnet 定义特定服务的实例分组，结合 VirtualService 可以实现完整的蓝绿部署（比如路由到不同的版本），金丝雀发布等功能。

我们可以通过下图看观察 DestinationRule 和 Envoy 之间负载均衡策略配置的对应关系：

我们可以通过下图观察 DestinationRule 和 Envoy 之间熔断和异常检测配置的对应关系：

2.5 Gateway

Gateway 用于管理进出网格的流量，是 L4-L6 层的负载均衡，但 Gateway 可以和绑定一个 VirtualService 用于表示 Istio Ingress 的配置模型，Istio Ingress 的缺省实现则采用了和 Sidecar 相同的Envoy，在 VirtualService 中可以配置七层路由规则，这些七层路由规则包括根据按照服务版本对请求进行导流，故障注入，HTTP 重定向，HTTP 重写等所 Istio 内部支持的路由规则。Gateway 的流量分为 Ingress 流量和 Egress 流量。Gateway 的配置应用于网格边缘的独立的 Envoy 代理上，而不是服务负载的 Envoy 代理上。

Gateway 配置介绍

• Selector：通过 label 选择 Gateway 实例。
• Servers：定义网关监听的端口以及应用协议。
• Host：指定需要匹配的 domain。

2.6 ServiceEntry

类似于 k8s service, 将外部服务注册到 k8s 注册中心，或者是将虚拟机注册到 k8s 注册中心，这样的话，虚拟机可以像原生 k8s 应用一样使用 Istio 进行服务治理。当配合 VirtualService 与 DestinationRule 时，可应用部分治理能力（比如，重试、超时、故障注入、熔断、异常检测）。

2.7 Sidecar

Sidecar 是 Istio 中最关键的 API 之一。在 Istio 中，默认所有的工作负载可以访问所有的服务，所有网格的服务之间是相互可见的。利用 Sidecar 可以限制负载可访问的服务，也就是限制服务可以暴露给谁，还可以精确控制部分端口可被访问，这种配置的力度就更精细一些。Sidecar 可作用于具体的工作负载，也可以作用于 Namespaces 下的所有 Sidecar。在大规模场景下，可以降低控制面和数据面开销（比如，内存、CPU、带宽）。

三、Istio 监控深度剖析

3.1 Istio 可观测性

Istio 提供了一些基本的非侵入式的观测能力，包括，Metrics 应用流量粒度的监控统计（比如，请求量统计，请求时延数据），Distributed Traces 调用链上报，Access Logs 访问日志，我们可以根据自己的需要打印日志输入的字段。

3.2 服务网格监控-Metrics

Metrics 主要依赖于 Istio 扩展的 Filter。重写 ALPN 的过滤器 istio.alpn 过滤器，将 http 请求转换为 Envoy 能够识别的 alpn。交换双方 Metadata 的 istio.metadata_excahnge 过滤器，用于交换 Server 端和 Client 端的 Metadata 的过滤器。记录 metrics 的 istio.stats 过滤器，根据 Metadata 或者访问的属性记录时延、计数等指标。

下面为 alpn 和 metadata_exchange 的工作原理图： 

3.3 服务网格监控-Trace

Trace 并非完全零入侵，应用必须进行调用链埋点，即从接收的请求中采集相关 Trace 信息（比如，x-request-id，x-b3-traceid，x-b3-spanid，x-b3-parentspanid，x-b3-sampled，x-b3-flags，x-ot-span-context），并且发送给下一个服务，最后 Envoy 可以将这些 Trace 信息发送给各种 Trace 后端服务（比如，Zipkin，Lightstep，Datadog，Stackdriver，Opencensus，Skywalking），这些后端服务根据 Envoy 上报的 Trace 进行集成并整合调用之间的关系。

下图为 Jaeger 的 Trace 展示：

3.4 服务网格监控-AccessLog

Accesslog 在请求过程中是通过异步方式记录日志，不会因此阻塞正常的访问。支持的 AccewssLog Sink 包括异步写文件，gRPC，stdout，stderr。在 AccessLog 的配置中可以通过 path 指定日志的输出，通过 logFormat.textFormat 执行日志输出的字段。

可以参考如下配置样例：

四、总结

Sidecar 模式将业务服务与应用管理服务剥离，该模式使业务开发更关注业务，应用管理人员更关注应用管理和控制，避免了相互的依赖和入侵。Istio 为网格内所有的服务通信生成详细的遥测数据。这种遥测技术提供了服务行为的可观察性，使运维人员能够排查故障、维护和优化应用程序，而不会给服务的开发人员带来任何额外的负担。通过 Istio，运维人员可以全面了解到受监控的服务如何与其他服务以及 Istio 组件进行交互。

五、参考连接

流量治理：流量治理_应用服务网格 ASM_用户指南_用户指南（1.0）_华为云 (huaweicloud.com)

流量监控：流量监控_应用服务网格 ASM_用户指南_用户指南（1.0）_华为云 (huaweicloud.com)

Istio 官方网站：Istio

ASM 应用服务网格官方首页：成长地图_应用服务网格 ASM_华为云 (huaweicloud.com)

本文整理自华为云社区【内容共创】活动第14期。
https://bbs.huaweicloud.cn/blogs/336904
任务24. 华为云云原生钻石课程14：Istio流量治理与监控管理深度剖