带你玩转Istio-第9篇---非侵入的流量治理

Http重定向（HTTPRedirect）

我们通过 HTTPRedirect 可以发送一个301重定向的应答给服务调用方，简单讲就是从一个 URL到另外一个 URL的永久重定向。如图 3-33所示，用户输入一个 URL，通过HTTPRedirect 可以将其跳转到另一个 URL。比较常见的场景：有一个在线网站，网址变了，通过这样的重定向，可以在用户输入老地址时跳转到新地址。

                                                     图3-33 HTTP重定向

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

需要注意的是，这里使用HTTPRedirect的uri的配置会替换原请求中的完整Path，而不是匹配条件上的 uri 部分。如下所示，对 forecast 服务所有前缀是“/advertisement”的请求都会被重定向到new-forecast的“/recommendation/activity”地址：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: forecast
  namespace: weather
spec:
  hosts:
  - forecast
  http:
  - match:
    - uri:
        prefix: /advertisement
    redirect:
      uri: /recommendation/activity
      authority: new-forecast

HTTP重写（HTTPRewrite）

我们通过HTTP重写可以在将请求转发给目标服务前修改HTTP请求中指定部分的内容，流程如图 3-34 所示。不同于重定向对用户可见，比如浏览器地址栏里的地址会变成重定向的地址，HTTP重写对最终用户是不可见的，因为是在服务端进行的。

                                    3-34 HTTP重写的流程

和重定向 HTTPRedirect的配置类似，重写 HTTPRewrite 也包括 uri 和 authority 这两个字段。
◎ uri：重写URL中的Path部分。
◎ authority：重写URL中的Authority部分。

和HTTPRedirect规则稍有不同，HTTPRedirect的uri只能替换全部Path，HTTPRewrite的 uri 是可以重写前缀的，即如果原来的匹配条件是前缀匹配，则修改后也只修改匹配到的前缀。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: forecast
  namespace: weather
spec:
  hosts:
  - forecast
  http:
  - match:
    - uri:
        prefix: /advertisement
    rewrite:
      uri: /recommendation/activity
    route:
    - destination
      host: forecast

HTTP重试（HTTPRetry）

如图3-35所示，HTTP重试是解决很多请求异常最直接、简单的办法，尤其是在工作环境比较复杂的场景下，可提高总体的服务质量。但重试使用不当也会有问题，最糟糕的情况是重试一直不成功，反而增加了总的延迟和性能开销。所以，据系统运行环境、服务自身特点，配置适当的重试规则显得尤为重要。

                                                图3-35 HTTP重试

HTTPRetry可以定义请求失败时的重试策略。重试策略包括重试次数、超时、重试条件等，这里分别描述相应的三个字段。
◎ attempts：必选字段，定义重试的次数。
◎ perTryTimeout：每次重试的超时时间，单位可以是毫秒（ms）、秒（s）、分钟（m）和小时。
◎ 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时执行重试。

如下示例为 forecast 服务配置了一个重试策略，在“5xx，connect-failure”条件下进行最多5次重试，每次重试的超时时间是3秒：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: forecast
  namespace: wwather
spec:
  hosts:
  - forecast
  http:
  - route:
    - destination:
        host: forecast
    retries:
      attempts: 5
      perTryTimeout: 3s
      retryOn: 5xx,connect-failure

HTTP流量镜像（Mirror）

HTTP 流量镜像指的是在将流量转发到原目标地址的同时将流量给另外一个目标地址镜像一份。如图 3-36 所示，把生产系统中宝贵的实际流量镜像一份到另外一个系统上，完全不会对生产系统产生影响，这里只镜像了一份流量，数据面代理只需关注原来转发的流量就可以，不用等待镜像目标地址的返回。

                                                          图3-36 HTTP流量镜像

只要使用VirtualService进行如下配置即可实现图3-36中的流量镜像效果：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: forecast
  namespace: weather
spec:
  hosts:
  - forecast
  http:
  - route:
    - destination:
        host: forecast
        subset: v1
    mirror:
      host: forecast
      subset: v2

HTTP故障注入（HTTPFaultInjection）

除了支持Redirect、Rewrite、Retry等HTTP请求的常用操作，在HTTPRoute上还支持故障注入。

在场景上，与其说是HTTP支持 Istio的故障注入功能，倒不如说是 Istio的故障注入功能支持HTTP。在Istio中为了支持非侵入的故障注入，要构造一定的业务故障，最好在HTTP这个通用的应用协议上有所支持。

实现上，在 HTTP 上做故障注入和 Redirect、Rewrite、Retry 没有太多差别，都是修改HTTP请求或者应答的内容。需要注意，在使用故障输入时不能启用超时和重试。

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

1）延迟故障注入

        HTTPFaultInjection中的延迟故障使用HTTPFaultInjection.Delay类型描述延时故障，表示在发送请求前进行一段延时，模拟网络、远端服务负载等各种原因导致的失败，主要有如下两个字段。

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

如下所示为让forecast服务的v2版本上百分之1.5的请求产生10秒的延迟：

....
      route:
      - destination
          host: forecast
          subset: v2
      fault:
        delay:
          percentate:
            value: 1.5
          fixedDelay: 10s

2）请求中止故障注入
       HTTPFaultInjection使用 HTTPFaultInjection.Abort描述中止故障，模拟服务端异常，给调用的客户端返回预先定义的错误状态码，主要有如下两个字段。

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

如下所示为在刚才的例子中增加中止故障注入，让forecast服务v2版本上百分之1.5的请求返回“500”状态码：

.....
      route:
      - destination:
          host: forecast
          subset: v2
      fault:
        abort:
          percentage:
            value: 1.5
          httpStatus: 500

HTTP跨域资源共享（CorsPolicy）

如图 3-37 所示，当一个资源向该资源所在服务器的不同的域发起请求时，就会产生一个跨域的HTTP请求。出于安全原因，浏览器会限制从脚本发起的跨域HTTP请求。通过跨域资源共享CORS（Cross Origin Resource Sharing）机制可允许Web应用服务器进行跨域访问控制，使跨域数据传输安全进行。在实现上是在HTTP Header中追加一些额外的信息来通知浏览器准许以上访问。

在VirtualService中可以对满足条件的请求配置跨域资源共享。

◎ 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。

                                                图3-37 HTTP跨域资源共享

我们给forecast服务配置跨域策略，允许源自news.com的GET方法的请求的访问：

....
   http:
   - route:
     - destination:
         host: forecast
     corsPolicy:
       allowOrigin:
       - news.com
       allowMethods:
       - GET
       maxAge: "2d"