Istio流量治理

Table of Contents

流量治理是Istio的核心功能，也是其“立身之本”。

在上一篇《Istio总览》中，我们可以看到，Istio分为控制平面和数据平面，流量控制属于数据平面。

流量控制CRD #

Istio的流量控制是通过一系列的CRD（Kubernetes的自定义资源）实现的，包括VirtualService、DestinationRule、ServiceEntry、Gateway和Sidecar五个资源。

VirtualService #

VirtualService 用于控制流量转发规则及API 粒度治理功能，包括错误注入、域控制等。

VirtualService中定义了一组路由规则，当流量进入时，逐个规则进行匹配，直到匹配成功后将流量转发给指定的路由地址。

DestinationRule #

DestinationRule 用于抽象路由转发的上游目标服务及其相关配置项，如负载均衡配置、目标服务连接池配置、熔断配置、健康检查配置等。用户DestinationRule 可以将目标服务根据特定标签匹配划分为多个子集。

DestinationRule在VirtualService的路由规则之后起作用。

ServiceEntry #

ServiceEntry可以将网格外的服务注册到Istio的注册表中，这样就可以把外部服务当作和网格内部的服务一样进行管理和操作，包括服务发现、路由控制等。

Gateway #

Gateway 一般用于 Ingress 和Egress，定义了服务网格的出入口及相关治理规则。通俗来说，Gateway 会控制一些特定的工作负载打开一个公开的监听端口，供服务网格内外部业务直接访问。再配合 VirtualService 和 DestinationRule 等CRD，可以对到达该端口的流量做一系列的管理和观察。

Gateway配置应用于网格边缘的独立的Envoy代理上，而不是服务负载的Envoy代理上。

Sidecar #

Sidecar用于声明服务网格中服务间的依赖关系。一般来说，网格数据平面为了代理网格流量，只需要了解其所依赖的少量服务的状态、治理配置、目标地址等信息即可。但是，因为服务网格不了解服务间依赖关系，所以默认服务网格会将所有配置都推送给网格数据平面，从而带来内存开销膨胀的问题。而 Sidecar 则可以显式指定服务间的依赖关系，改善内存开销问题。

灰度发布 #

灰度发布是指将流量按比例分配到不同的服务，常用的场景有：AB测试、金丝雀发布、

实现灰度发布仅需在ServiceEntry中对不同的Destination配置对应的比重即可，但是通常来说，需要配合DestinationRule为目标服务根据标签来划分为多个子集。

流量镜像 #

流量镜像（Mirroring /Traffic Shadow），也被称为影子流量，可以通过一定的配置将线上的真实流量复制一份到镜像服务中，并通过流量镜像转发，从而达到在不影响线上服务的情况下对流量或请求内容做具体分析的目的。它的设计思想是只做转发而不接收响应。

传统的测试手段无法满足复杂的现实场景，因此在项目上线前使用真实的流量进行服务检测，能够最大化的找到潜在的未知问题。
当遇到复杂的问题难以排查时，往往需要进行代码调试，而线上环境往往是不可调试的，因此，可以通过流量镜像将流量达到临时的环境中进行调试。

流量镜像并不是备份流量，只是将流量复制到一个新的服务。

超时控制 #

服务之前的请求需要设置超时时间，这样可以避免级联现象导致的“雪崩”。一般情况下我们都会在服务实例的层面上控制请求的超时时间，这样可以做到针对不同的请求设置不同的超时时间，但是这样做存在弊端：

繁琐：为每个服务请求都设置一个超时时间，这是一个繁琐且枯燥的的工作，可以通过封装通用的工具来解决这个问题。
容易遗漏：在服务数量巨大、开发人员质量参差不齐的情况下，很容易造成一些调用漏掉了超时时间，这就为未来发生的故障埋下了种子。

通过在网格数据平面拦截流量来统一实现超时控制，这能够大大降低开发人员的心智负担。但是新的问题也随之而来——有些请求本身就很慢怎么办？

这是一个很复杂的问题，不同的场景有不同的解决方案，如增加缓存、在数据平面增加重试、在业务上改造等等。

重试机制 #

重试机制的意义在于避免了某种偶发情况（如网络波动）导致的服务故障，其目的在于提升用户体验。

重试机制带来的问题是对服务层面的幂等性要求，当然，这不是数据平面带来的问题，普通的服务间访问也会有重试机制，但是开发人员需要明确自己的服务会不会受重试机制的影响。

熔断机制 #

熔断是系统的自我保护机制，就像家里的电器一样，当“断路器”发现整体电压过大（服务故障频发），就会进行“断路”操作，避免引发更大的灾难。

在微服务中，系统中的某些模块发生故障后，可以通过降级等方式来提升整体系统的可用性。

故障注入 #

系统的健壮性不是建立在完善的测试用例上，而在于处理各种意外情况的能力。因此，在对系统整体测试时，需要模拟各种情况下的服务故障。传统的方式（如手动停服务、改代码）的成本很高，操作也很复杂，Istio中提供了一种无侵入的注入故障的能力。

这些能力包括：模拟上游服务的处理时长、服务异常状态、自定义响应状态码等故障信息，暂不支持对服务主机内存、CPU等信息故障的模拟。实现方式则是通过配置上游主机的VirtualService实现的。