读云原生服务网格Istio - 原理、实践、架构与源码解析

原理篇

• 服务网格技术与istio项目的技术背景、设计理念
  与功能原理
• 掌握istio流量治理、策略与遥测和安全功能的使用方法。

序
云原生容器技术与微服务应用的出现，推动了人们对服务网格的需求。

• 什么是服务网格？
  服务网格是服务之间通信的控制器。

• 云原生技术面临的挑战？
  一个企业可能会有成千上万的容器运行，如何管理容器或服务之间的通信，包括负载均衡、流量管理、路由、运行状况监视、安全策略及服务间身份验证等。

服务网格不仅作用于容器里的服务，也可作用于非容器应用或服务。

前言

• 云原生：是对在现代的动态环境下（比如云计算的三大场景：公有云、私有云及混合云）可用来构建并运行可扩展应用的技术的总称：服务网格是云原生技术的典型代表之一，其他技术还包括容器、微服务、不可变基础设施、声明式API等。

第一章 istio介绍

istio是什么

istio是与k8s紧密结合的适用于云原生场景的Service Mesh形态的用于服务治理的开发平台。

服务治理主要包含以下四个方面：

• 连接：istio通过集中配置的流量规则控制服务间的流量和调用，实现负载均衡、熔断、故障注入、重试、重定向等服务治理功能。
• 安全：istio提供透明的认证机制、通道加密、服务访问授权等安全能力，可增强服务访问的安全性。
• 策略执行：istio通过可动态插拔、可扩展的策略实现访问控制、速率限制、配额管理、服务计费等能力。
• 可观察性：动态获取服务运行数据和输出，提供强大的调用链、监控和调用日志收集输出的能力。配合可视化工具，可方便运维人员了解服务的运行状况，发现并解决问题。

istio能做什么

与k8s语法风格类似，大意：将group是dev的流量转发到v2版本的recommendation服务，其他还是访问v1版本的recommendation服务，从未达到从v1版本切少量流量到灰度版本。

istio与服务治理

关于微服务

服务注册、服务发现、负载均衡作为微服务之间的桥梁进行访问。例如eureka等。

服务治理的三种形态

• 在应用程序中包含治理逻辑，治理逻辑和业务逻辑耦合。
• 治理逻辑独立的代码，把治理的公共逻辑抽象成一个公共库，使用这种开发框架的就拥有治理能力，例如SDK模式，最典型的服务治理框架spring cloud。但是业务代码和SDK是一起编译的，所以业务代码和SDK基于同一种语言（语言绑定）。
• 治理逻辑独立的进程，将业务逻辑和治理逻辑彻底独立，做到与开发语言无关。即sidecar模式。

istio和服务网格

服务网格的特点：

• 基础设施：服务网格是处理服务间通信的基础设施层。
• 云原生：服务网格尤其适用于在云原生场景下帮助应用程序在复杂的服务拓扑间可靠地传递请求。
• 网络代理：在实际使用中，服务网格一般是通过一组轻量级网络代理来执行治理逻辑的。
• 对应用透明：轻量网络代理与应用程序部署在一起，但应用感知不到代理的存在，还是使用原来的方式工作。

基础设施层对比

Sidecar类比TCP/IP网络协议栈，应用程序像使用TCP/IP一样使用这个通用代理：TCP/IP负责将字节码可靠的网络节点间传递，Sidecar则负责将请求可靠地在服务间进行传递。TCP/IP面向的底层的数据流，Sidecar则可以支持多种高级协议（HTTP等），以及对服务运行时进行高级控制，使服务变得可监控、可管理。

Inbound流量和Outbound流量

Sidecar组成的网格，对网格内的服务间访问进行管理，应用还是按照本来的方式进行互相访问，每个应用程序的Inbound流量和Outbound流量都要经过Sidecar代理，并在Sidecar上执行治理动作。最后，Sidecar使网格动作的执行体，全局的管理规则和网格内的元数据维护通过一个统一的控制面实现。

这种形态在服务的访问链路上导致以下两个问题：
从A服务访问B服务，Sidecar会拦截A服务的Outbound流量以及B服务的Inbound服务，执行治理动作。

• 增加了两处延迟和可能的故障点
• 多出来的这两跳对于访问性能、整体可靠性和整个系统的复杂性都带来了新的挑战

其中，后者本来属于基础设施层可维护性、可靠性的范畴。而前者引入的性能和资源消耗，通过保证转发代理的轻量和高性能降低时延影响，尤其时后端的应用程序比代理更重，叠加代理并不会明显影响应用的访问性能；另外，对于这些高性能的代理，只要消耗足够的资源踪能达到预期的性能。

服务网格选择istio

istio的早期版本使用Envoy V1版本的API，即Restful方式
新版本使用Envoy V2版本的API，即gRPC协议。

istio与k8s

k8s还缺乏的一些功能：

• k8s本身使支持微服务的架构，在pod中部署微服务很适合，也实现了微服务的互访互通问题，但对服务间访问的管理如服务的熔断、限流、动态路由、调用链追踪等都不在k8s的能力方位内。
• k8s的Service基于每个节点的kube-proxy从kube-apiserver上获取Endpoint的信息，并将对Service的请求经过负载均衡转发到对应的Endpoint上，但k8s值提供了4层负载均衡能力，无法基于应用层的信息进行负载均衡，更不会提供应用层的流量管理，在服务运行管理上也只会提供了基本的探针机制，并不提供服务访问指标和调用链追踪这种应用的服务运行诊断能力。

istio实现方式：
istio的服务发现是从kube-apiserver中获取Serivce和Endpoint，然后将其转换成istio服务模型的Service和SeviceInstance,但是其数据面不是kube-proxy，而是在每个pod里部署的Sidecar，也可以看作每个服务实例的Proxy。这样，Proxy的粒度更细了，可以做更细粒度的服务治理。

istio和k8s适配性

• 数据面
  数据面Sidecar运行在pod里
• 统一服务发现
  istio的服务发现机制完美地基于k8s的域名访问机制构建，避免再搭一个注册中心，也避免了数据不一致问题。
• 基于k8s的CRD描述规则
  istio的所有路由规则和控制策略都是通过k8s CRD实现的。
  istio不仅数据面Envoy泡在k8s的pod里，其控制面也运行再k8s集群中，其控制面本身存在的形式也是k8s Deployment和Service，基于k8s扩展和构建。

总结

第二章 istio架构概述

istio工作机制

（1）自动注入
指在创建应用程序时自动注入Sidecar代理。
（2）流量拦截
envoy会拦截服务的Inbound和Outbound流量
（3）服务发现
envoy调用管理面组件Pliot的服务发现接口获取目标服务的实例
（4）负载均衡
envoy从Pliot中获取forecast服务的负载均衡配置，并执行负载均衡动作
（5）流量治理
envoy从Pliot中获取配置的流量规则，再拦截到出、入流量的时候执行治理操作
（6）访问安全
Pliot下发安全相关配置，在frontend服务和forecast服务的envoy上自动加载证书和密钥来实现双向认证，其中证书和密钥由另一个管理面组件Citadel维护
（7）服务遥测
在服务通信时，通信双方的envoy都会连接管里面组件Mixer上报访问数据，并通过Mixer将数据转发给对应的监控后端
（8）策略执行
在进行服务访问时，通过Mixer连接后端服务来控制服务间的访问，判断对访问是放行还是拒绝。
（9）外部访问
在网格的入口处有一个envoy扮演入口网关的角色。当外部服务通过Gateway访问入口服务frontend,对frontend服务的负载均衡和一些流量治理策略都在这个Gateway上执行

总结：服务调用双方的envoy代理拦截流量，并根据管里面的相关配置执行相应的治理动作，这也是istio的数据面和控制面的配合方式。

istio的服务模型

服务、服务版本和服务实例等几个对象构成了istio的服务模型。

istio的几个资源对象就是基于k8s的相应资源对象构建的，加上部分约束来满足istio服务模型的要求。

• 端口命名：protocol-suffix，例：“name:http2-forecast"。如果端口未命名或者没有基于这种格式进行命名，则端口的流量会被当做TCP流量来处理。其中protocol包括tcp\http\http2\https\grpc\tls\mongo\mysql\redis等。
• 服务关联：pod需要关联到服务，如果一个pod属于多个k8s服务，则要求服务不能在同一个端口上使用不同的协议。
• Deployment使用app和version标签：建议Deployment显式地包含app和version标签。

istio的服务

apiVersion: v1
kind:Servicce
metadata:
  name: forecast
spec:
  ports:
  -port: 3002
   targetPort: 3002
  selector:
   app:forecast

以上表示创建一个名为forecast的Service，通过一个ClusterIP的地址就可以访问这个Service，指向有"app: forecast"标签的pod。k8s会自动创建一个和Service同名的Endpoint对象，Service的selector会持续关注属于Service的Pod,然后更新到相应的Endpoint对象。

istio的Service,只需要满足istio服务的约束，在端口名称上指定 协议

apiVersion: v1
kind:Servicce
metadata:
  name: forecast
spec:
  ports:
  -port: 3002
   targetPort: 3002
   # 添加name
   name: http
  selector:
   app:forecast

在以上实例中指定了3002端口是http，对这个服务的访问就可以应用http的诸多治理规则。
在istio中，Service是治理的对象，是istio中的核心管理实体。

istio的服务版本

• 这两个Deployment都有相同的“app:forecast”标签，正是这个标签和Service的标签选择器一样，保证了Service能关联到两个Deployment对应的Pod
• 这两个Deployment都有不同的镜像版本，因此各自创建的pod也不同；这连个Deployment version标签也不同，分别为v1和v2，表示这是服务的不同版本，这个不同的版本标签用来定义不同的Destination，进而执行不同的路由规则。

istio的服务实例

服务实例时真正处理服务请求的后端，就是监听在相同端口上的具有同样行为的对等后端。服务访问时由代理根据负载均衡策略将流量转发到其中一个后端处理。istio的ServiceInstance主要包括Endpoint\Service\Labels\AvailabilityZone和ServiceAccount等属性，Endpoint是最主要的属性，表示这个实例对应的网络后端（ip:port),Service表示这个服务实例归属的服务。

istio的主要组件

istio-pilot
istio-pilot是istio的控制中枢Pliot服务。主要包括两个重要的功能
1、服务发现
2、向数据面（envoy）下发规则，包括VirtualService、DestinationRule、Gataway、ServiceEntry等流量治理规则，也包括认证授权等安全规则。
istio-telemetry
istio-telemetry是专门用于收集遥测数据的mixer服务组件。对于Mixer来说，在服务间
交互时Envoy都会对Mixer进行一次调用，因此这是一种实时管理。
istio-policy
istio-policy是另外一个Mixer服务，和istio-telemetry基本上是完全相同的机制和流程。数据面在转发服务的请求前调用istio-policy的Check接口检查是否允许访问，对服务间的访问进行可扩展的控制。
istio-citadel
服务列表中的 istio-citadel是 Istio的核心安全组件，提供了自动生成、分发、轮换与撤销密钥和证书功能。
istio-galley
istio-galley并不直接向数据面提供业务能力，而是在控制面上向其他组件提供支持。
istio-sidercar-injector
istio-sidecar-injector是负责自动注入的组件，只要开启了自动注入，在Pod创建时就会自动调用istiosidecar-injector向Pod中注入Sidecar容器。
istio-proxy
数据面的轻量代理。里面包含Envoy以及叠加了istio的proxy功能的扩展。通常envoy、sidecar、proxy指的都是一个东西即数据面馆的代理。
istio-ingressgateway
istio-ingressgateway 就是入口处的 Gateway，从网格外访问网格内的服务就是通过这个Gateway进行的。
其他组件
除了以“istio”为前缀的以上几个Istio自有的组件，在集群中一般还安装Jaeger-agent、Jaeger-collector、Jaeger-query、Kiali、Prometheus、Tracing、Zipkin组件，这些组件提供了Istio的调用链、监控等功能，可以选择安装来完成完整的服务监控管理功能。

第三章 非侵入的流量治理

istio流量治理的原理

istio流量治理的目标：以基础设施的方式提供给用户非侵入的流量治理能力。

istio流量治理的概要流程如下：

• 在控制面会经过如下流程：
  （1）管理员通过命令行或者API创建流量规则；
  （2）Pilot将流量规则转换为Envoy的标准格式；
  （3）Pilot将规则下发给Envoy。
• 在数据面会经过如下流程：
  （1）Envoy拦截Pod上本地容器的Inbound流量和Outbound流量；
  （2）在流量经过Envoy时执行对应的流量规则，对流量进行治理。

负载均衡

负载均衡负责将请求转发到某一个健康的服务实例上面，保证应用的运行以及均衡。

istio负载均衡的流程，Pliot将服务发现数据通过Envoy的标准接口下发给数据面Envoy,Envoy则根据配置的负载均衡策略选择一个实例转发请求。Istio当前支持的负载均衡算法包括：轮询、随机、最小连接数算法。

服务熔断

服务熔断最典型的应用场景是防止网络和服务调用故障联级发生，限制故障的影响范围，防止故障蔓延导致系统整体性能下降或雪崩。

istio熔断
与Hystrix类似，在istio中也提供了连接池和故障实例隔离的能力，只是概念稍有不同：前者在istio的配置中叫做连接池管理，后者叫做异常点检测，分别对应Envoy的熔断和异常点检测。

istio的0.8版本之前使用V1alphal接口，其中专门有个CircuitBreaker配置，包含对连接池和故障实例隔离的全部配置。在istio1.1的V1alpha3接口中，CircuitBreaker功能被拆成连接池管理（ConnectionPoolSettings）和异常点检测(OutlierDetection)这两种配置。

• 连接池管理
  （1）当请求服务对目标服务的请求不超过配置的最大连接数，放行
  （2）当请求服务对目标服务的请求不超过最大等待请求数时，进入连接池等待
  （3）当请求服务对目标服务的请求超过配置的最大等待请求数时，直接拒绝。

• 异常点检测
  当连续的错误数超过配置的阈值时，后端实例会被移除。异常点检查在实现上对每个上游服务都进行跟踪，对于HTTP服务，如果有主机返回了连续的5xx，则会被踢出服务池；而对于TCP服务，如果到目标服务的连接超时和失败，则都会被记为出错。

故障注入

istio的故障注入是在网格中对特定的应用层协议进行故障注入。可以对某种请求注入一个指定的HTTP Code,也可以注入一个指定的延时。

灰度发布

灰度发布解决的问题：例如新版本上线时，直接将老版本全部升级是非常有风险的。灰度发布将少量流量分到新版本，确认没有问题后，再逐步加大流量。

服务访问入口

一组服务组合在一起可以完成一个独立的业务功能，一般都会有一个入口服务，从外部可以访问，主要是接收外部的请求并将其转发到后端的服务，有时还可以定义通用的过滤器在入口处做权限、限流等功能

外部接入服务治理

在Istio中是通过一个ServiceEntry的资源对象将网格外的服务注册到网格上，然后像对网格内的普通服务一样对网格外的服务访问进行治理的。

istio路由配置规则： VirtualService

(1) hosts:表示流量发送的目标。在k8s中，hosts一般使用的是Service的短域名。

(2) gateways: 表示应用这些流量规则的 Gateway。VirtualService 描述的规则可以作用到网格里的Sidecar 和入口处的 Gateway，表示将路由规则应用于网格内的访问还是网格外经过Gateway的访问。

以下三种使用场景：

• 场景1：服务只是在网格内访问的，这是最主要的场景，gateways字段可以省略。
• 场景2：服务只是在网格外访问的，配置要关联的Gateway。
• 场景3：在服务网格内和网格外都需要访问。这里至少要写两个元素，一个是外部访问的Gateway，另一个是保留关键字"mesh"

(3)http:是一个与 HTTPRoute 类似的路由集合，用于处理 HTTP 的流量，是 Istio中内容最丰富的一种流量规则。

(4)tls:是一个 TLSRoute 类型的路由集合，用于处理非终结的 TLS 和 HTTPS 的流量。

(5)tcp:是一个TCPRoute类型的路由集合，用于处理TCP的流量，应用于所有其他非 HTTP和 TLS端口的流量。如果在 VirtualService中对 HTTPS和 TLS没有定义对应的TLSRoute，则所有流量都会被当成TCP流量来处理，都会走到TCP路由集合上。

(6)exportTo: 用于控制VirtualService 跨命名
空间的可见性，这样就可以控制在一个命名空间下定义的VirtualService是否可以被其他命名空间下的Sidecar和Gateway使用了。如果未赋值，则默认全局可见。“.”表示仅应用到当前命名空间，“”表示应用所有命名空间。在Istio 1.1中只支持“.”和“”这两种配置。

HTTP路由（HTTPRoute）

使用场景：
◎ 服务的端口协议是HTTP、HTTP2、GRPC，即在服务的端口名中包含http-、http2-、grpc-等。
◎ Gateway的端口协议是HTTP、HTTP2、GRPC，或者Gateway是终结TLS，即Gateway外部是HTTPS，但内部还是HTTP。
◎ ServiceEntry的端口协议是HTTP、HTTP2、GRPC。

1、HttpRoute规则解析

HTTPRoute 规则的功能是：满足 HTTPMatchRequest 条件的流量都被路由到HTTPRouteDestination，
执行重定向（HTTPRedirect）、重写（HTTPRewrite）、重试（HTTPRetry）、故障注入
（HTTPFaultInjection）、跨站（CorsPolicy）策略等。HTTP 不仅可以做路由匹配，还可以做一些写操作
来修改请求本身

2、HTTP匹配规则（HTTPMatchRequest）

支持将HTTP属性如uri、scheme、method、authority、port 等作为条件来匹配请求

（1）uri、scheme、method、authority：4个字段都是StringMatch类型，在匹配请求时都支持exact、prefix和regex三种模式的匹配，分别表示完全匹配输入的字符串，前缀方式匹配和正则表达式匹配。
（2）headers：匹配请求中的Header，是一个Map类型。Map的Key是字符串类型，Value 仍然是StringMatch 类型。即对于每一个 Header 的值，都可以使用精确、前缀和正则三种方式进行匹配。

exact:精确 prefix:前缀 regex:正则

(3）port：表示请求的服务端口。大部分服务只开放了一个端口，这也是在微服务实践中推荐的做法，在这种场景下可以不用指定port。
（4）sourceLabels：是一个 map 类型的键值对，表示请求来源的负载匹配标签。这在很多时候非常有用，可以对一组服务都打一个相同的标签，然后使用sourceLabels字段对这些服务实施相同的流量规则。在Kubernetes平台上，这里的Label就是Pod上的标签。

http:
  - match:
    - sourceLabels:
      app:fronted
      version:v2

（5）gateways：表示规则应用的Gateway名称，语义同VirtualService上面的gateways定义，是一个更细的Match条件，会覆盖在VirtualService上配置的gateways。

3、HTTP路由目标（HTTPRouteDestination）

(1)destination
核心字段 destination 表示请求的目标。在 VirtualService 上执行一组规则，最终的流量要被送到这个目标上。这个字段是一个Destination类型的结构，通过host、subset和port三个属性来描述。
host 是 Destination 的必选字段，表示在 Istio 中注册的服务名，不但包括网格内的服务，也包括通过ServiceEntry方式注册的外部服务。在Kubernetes平台上如果用到短域名，Istio 就会根据规则的命名空间解析服务名，而不是根据 Service 的命名空间来解析。所以在使用上建议写全域名，这和VirtualService上的hosts用法类似。
(2)weight
除了 destination，HTTPRouteDestination 上的另一个必选字段是 weight，表示流量分配的比例，在一个route下多个destination的weight总和要求是100。
在下面的示例中，从原有的v1版本中切分20%的流量到v2版本，这也是灰度发布常用的一种流量策略，即不区分内容，平等地从总流量中切出一部分流量给新版本：

(3)headers
headers 字段提供了对 HTTP Header 的一种操作机制，可以修改一次 HTTP 请求中Request或者Response的值，包含request和response两个字段。
◎ request：表示在发请求给目标地址时修改Request的Header。
◎ response：表示在返回应答时修改Response的Header。
对应的类型都是HeaderOperations类型，使用set、add、remove字段来定义对Header的操作。
◎ set：使用map上的Key和Value覆盖Request或者Response中对应的Header。
◎ add：追加map上的Key和Value到原有Header。
◎ remove：删除在列表中指定的Header。

4、HTTP重定向（HTTPRedirect）
HTTPRedirect包括两个重要的字段来表示重定向的目标。
◎ uri：替换URL中的Path部分。
◎ authority：替换URL中的Authority部分。

5、HTTP重写（HTTPRewrite）
我们通过HTTP重写可以在将请求转发给目标服务前修改HTTP请求中指定部分的内容,但与HTTPRedirect稍有不同，HTTPRewrite对用户是不可见的。
◎ uri：重写URL中的Path部分。
◎ authority：重写URL中的Authority部分。
和HTTPRedirect规则稍有不同，HTTPRedirect的uri只能替换全部Path，HTTPRewrite的 uri 是可以重写前缀的，即如果原来的匹配条件是前缀匹配，则修改后也只修改匹配到的前缀。

6、HTTP重试（HTTPRetry）
◎ attempts：必选字段，定义重试的次数。
◎ perTryTimeout：每次重试的超时时间，单位可以是毫秒（ms）、秒（s）、分钟（m）和小时
（h）。
◎ retryOn：进行重试的条件，可以是多个条件，以逗号分隔。
其中，重试条件retryOn的取值包括以下几种。
◎ 5xx：在上游服务返回5xx应答码，或者在没有返回时重试。
◎ gateway-error：类似5xx异常，只对502、503和504应答码进行重试。
◎ connect-failure：在连接上游服务失败时重试。
◎ retriable-4xx：在上游服务返回可重试的4xx应答码时执行重试。
◎ refused-stream：在上游服务使用REFUSED_STREAM错误码重置时执行重试。
◎ cancelled：在gRPC应答的Header中状态码是cancelled时执行重试。
◎ deadline-exceeded：在gRPC应答的Header中状态码是deadline-exceeded时执行重试。
◎ internal：在gRPC应答的Header中状态码是internal时执行重试。
◎ resource-exhausted：在gRPC应答的Header中状态码是resource-exhausted时执行重试。
◎ unavailable：在gRPC应答的Header中状态码是unavailable时执行重试。

7、HTTP流量镜像（Mirror）
HTTP 流量镜像指的是在将流量转发到原目标地址的同时将流量给另外一个目标地址镜像一份。

8、HTTP故障注入（HTTPFaultInjection）
HTTPFaultInjection通过delay和abort两个字段配置延时和中止两种故障，分别表示Proxy延迟转发HTTP请求和中止HTTP请求。

(1)延迟故障注入
◎ fixedDelay：一个必选字段，表示延迟时间，单位可以是毫秒、秒、分钟和小时，要求时间必须大于1毫秒。
◎ percentage：配置的延迟故障作用在多少比例的请求上，通过这种方式可以只让部分请求发生故障。

（2）请求中止故障注入
◎ httpStatus：是一个必选字段，表示中止的HTTP 状态码。
◎ percentage：配置的中止故障作用在多少比例的请求上，通过这种方式可以只让部分请求发生故障，用法同延迟故障。

9、HTTP跨域资源共享（CorsPolicy）
当一个资源向该资源所在服务器的不同的域发起请求时，就会产生一个跨域的HTTP请求。在实现上是HTTP Header中追加一些额外的信息来通知浏览器准许以上访问。
◎ allowOrigin：允许跨域资源共享的源的列表，在内容被序列化后，被添加到Access-Control-Allow- Origin的Header上。当使用通配符“*”时表示允许所有。
◎ allowMethods：允许访问资源的HTTP方法列表，内容被序列化到Access-Control-Allow-Methods的Header上。
◎ allowHeaders：请求资源的HTTP Header列表，内容被序列化到Access-Control-Allow-Headers的Header上。
◎ exposeHeaders：浏览器允许访问的 HTTP Header 的白名单，内容被序列化到Access-Control-Expose-Headers的Header上。
◎ maxAge：请求缓存的时长，被转化为Access-Control-Max-Age的Header。
◎ allowCredentials：是否允许服务调用方使用凭据发起实际请求，被转化为Access-Control-Allow- Credentials的Header。

TLS路由（TLSRoute）

使用场景：
◎ 服务的端口协议是HTTPS和TLS。即在服务的端口名中包含https-、tls-等。
◎ Gateway的端口是非终结的 HTTPS和 TLS。
◎ ServiceEntry的端口是HTTPS和TLS。

TCP路由（TCPRoute）

所有不满足以上HTTP和TLS条件的流量都会应用TCP流量规则。

三种协议路由规则的对比

从规则构成上都是先定义一组匹配条件，然后对满足条件的流量执行对应的操作。

VirtualService的典型应用

以上三条路由规则随便调整顺序，都会导致另一个规则在理论上不会有流量。例如，调整v2和v3的顺序，则匹配“/weather/”的所有流量都被路由到v2版本，在v3版本上永远不会有流量。在路由规则执行时，只要有一个匹配，规则执行就会跳出，类似代码中的switch分支，碰到一个匹配的case就break，不会再尝试下面的条件。

istio目标规则配置： DestinationRule

在路由的目标对象Destination中大多包含表示Service子集的subset字段，这个服务子集就是通过DestinationRule定义的。

DestinationRule规则定义

• VirtualService也是一个虚拟Service，描述的是满足什么条件的流量被哪个后端处理。
• == DestinationRule描述的是这个请求到达某个后端后怎么去处理，即所谓目标的规则。==

DestinationRule的重要属性如下:
（1）host：是一个必选字段，表示规则的适用对象，取值是在服务注册中心中注册的服务名，可以是网格内的服务，也可以是以ServiceEnrty方式注册的网格外的服务。如果这个服务名在服务注册中心不存在，则这个规则无效。host如果取短域名，则会根据规则所在的命名空间进行解析。
（2）trafficPolicy：是规则内容的定义，包括负载均衡、连接池策略、异常点检查等。
（3）subsets：是定义的一个服务的子集，经常用来定义一个服务版本，如VirtualService中的结合用法。
（4） exportTo：Istio 1.1 在 DestinationRule 上还添加了一个重要字段，用于控制DestinationRule跨命名空间的可见性，这样就可以控制在一个命名空间下定义的资源对象是否可以被其他命名空间下的Sidecar 执行。如果未赋值，则默认全局可见。“.”表示仅应用到当前命名空间，“”表示应用到所有命名空间。在Istio 1.1中只支持“.”和“”这两种配置。

1、流量策略（TrafficPolicy）

流量策略包含以下4个重要的配置：
◎ loadBalancer：LoadBalancerSettings类型，描述服务的负载均衡算法。
◎ connectionPool：ConnectionPoolSettings类型，描述服务的连接池配置。
◎ outlierDetection：OutlierDetection，描述服务的异常点检查。
◎ tls：TLSSettings类型，描述服务的TLS连接设置。
此外，流量策略还包含一个PortTrafficPolicy类型的portLevelSettings，表示对每个端口的流量策略。

2、负载均衡设置（LoadBalancerSetting）

◎ ROUND_ROBIN：轮询算法，如果未指定，则默认采用这种算法。
◎ LEAST_CONN：最少连接算法，算法实现是从两个随机选择的服务后端选择一个活动请求数较少
的后端实例。
◎ RANDOM：从可用的健康实例中随机选择一个。
◎ PASSTHROUGH：直接转发连接到客户端连接的目标地址，即没有做负载均衡。

一致性哈希是一种高级的负载均衡策略，只对 HTTP有效，因为在实现上基于 HTTP Header、Cookie的取值来进行哈希。
◎ httpHeaderName：计算哈希的Header。
◎ httpCookie：计算哈希的Cookie。
◎ useSourceIp：基于源IP计算哈希值。
◎ minimumRingSize：哈希环上虚拟节点数的最小值，节点数越多则负载均衡越精细。如果后端实例
数少于哈希环上的虚拟节点数，则每个后端实例都会有一个虚拟节点。

3、连接池设置（ConnectionPoolSetting）

Istio连接池管理在协议上分为TCP流量和HTTP流量治理。

(1)TCP连接池配置（TCPSetting）
◎ maxConnections：表示为上游服务的所有实例建立的最大连接数，默认是 1024，属于 TCP层的配置，对于 HTTP，只用于 HTTP/1.1，因为 HTTP/2对每个主机都使用单个连接。
◎ connectTimeout：TCP连接超时，表示主机网络连接超时，可以改善因调用服务变慢导致整个链路变慢的情况。
◎ tcpKeepalive：设置TCP keepalives，是Istio 1.1新支持的配置，定期给对端发送一个keepalive的探测包，判断连接是否可用。这种0长度的数据包对用户的程序没有影响。它包括三个字段：probes，表示有多少次探测没有应答就可以断定连接断开，默认使用操作系统额配置，在Linux系统中是9；time，表示在发送探测前连接空闲了多长时间，也默认使用操作系统配置，在 Linux 系统中默认是两小时；interval，探测间隔，默认使用操作系统配置，在Linux中是75秒。

(2)HTTP连接池配置（HTTPSettings）
◎ http1MaxPendingRequests：最大等待 HTTP 请求数，默认值是 1024，只适用于HTTP/1.1 的服务，因为 HTTP/2 协议的请求在到来时会立即复用连接，不会在连接池等待。
◎ http2MaxRequests：最大请求数，默认是 1024。只适用于 HTTP/2 服务，因为HTTP/1.1使用最大连接数maxConnections即可，表示上游服务的所有实例处理的最大请求数。
◎ maxRequestsPerConnection：每个连接的最大请求数。HTTP/1.1和HTTP/2连接池都遵循此参数。如果没有设置，则没有限制。设置为 1 时表示每个连接只处理一个请求，也就是禁用了Keep-alive。
◎ maxRetries：最大重试次数，默认是3，表示服务可以执行的最大重试次数。如果调用端因为偶尔抖动导致请求直接失败，则可能会带来业务损失，一般建议配置重试，若重试成功则可正常返回数据，只不过比原来响应得慢一点，但重试次数太多会影响性能，要谨慎使用。不要重试那些重试了也总还是失败的请求；不要对那些消耗大的服务进行重试，特别是那些不会被取消的服务。
◎ idleTimeout：空闲超时，定义在多长时间内没有活动请求则关闭连接。

，在控制最大请求数时，对 HTTP/1.1使用maxConnections参数配置，对HTTP/2则使用http2MaxRequests参数配置。

(3)异常实例检测设置（OutlierDetection）
◎ consecutiveErrors：实例被驱逐前的连续错误次数，默认是 5。对于 HTTP 服务，返回 502、503 和504 的请求会被认为异常；对于 TCP 服务，连接超时或者连接错误事件会被认为异常。
◎ interval：驱逐的时间间隔，默认值为10秒，要求大于1毫秒，单位可以是时、分、毫秒。
◎ baseEjectionTime：最小驱逐时间。一个实例被驱逐的时间等于这个最小驱逐时间乘以驱逐的次数。这样一个因多次异常被驱逐的实例，被驱逐的时间会越来越长。默认值为30秒，要求大于1毫秒，单位可以是时、分、毫秒。
◎ maxEjectionPercent：指负载均衡池中可以被驱逐的故障实例的最大比例，默认是10%，设置这个值是为了避免太多的服务实例被驱逐导致服务整体能力下降。
◎ minHealthPercent：最小健康实例比例，是Istio 1.1新增的配置。当负载均衡池中的健康实例数的比例大于这个比例时，异常点检查机制可用；当可用实例数的比例小于这个比例时，异常点检查功能将被禁用，所有服务实例不管被认定为健康还是不健康，都可以接收请求。参数的默认值为50%。

注意：在Istio 1.1的异常点检查中增加了minHealthPercent配置最小健康实例。当负载均衡池中的健康实例数的比例小于这个比例时，异常点检查功能将会被禁用。如下所示为检查4分钟内forecast服务实例的访问异常情况，连续出现5次访问异常的实例将被隔离 10分钟，被隔离的实例不超过 30%，在第 1次隔离期满后,异常实例将重新接收流量，如果仍然不能正常工作，则会被重新隔离，第 2 次将被隔离 20 分钟，以此类推：

(4)端口流量策略设置（PortTrafficPolicy）
端口流量策略是将前面讲到的 4 种流量策略应用到每个服务端口上。

（5）服务子集（Subset）
◎ name：Subset的名字，为必选字段。通过VirtualService引用的就是这个名字。
◎ labels：Subset上的标签，通过一组标签定义了属于这个Subset的服务实例。比如最常用的标识服务版本的Version标签。
◎ trafficPolicy：应用到这个Subset上的流量策略。

DestinationRule的典型应用

• 定义Subset
• 服务熔断
• 负载均衡配置
• TLS认证配置

istio服务网关配置：Gateway