1. 准备工作

  • 运行以下命令初始化版本的路由
  1. $ kubectl apply -f samples/bookinfo/networking/virtual-service-all-v1.yaml

2. 请求超时

针对http的请求超时，可以使用路由规则中的timeout字段。默认timeout是关闭的。但是在此任务中，设置reviews服务的超时时间为1秒。为了查看它的影响，我们还可以在调用ratings服务的时候引进一个2秒的延迟。

  1. 路由请求到reviews的v2版本。
  1. kubectl apply -f - <<EOF
  2. apiVersion: networking.istio.io/v1alpha3
  3. kind: VirtualService
  4. metadata:
  5.   name: reviews
  6. spec:
  7.   hosts:
  8.     - reviews
  9.   http:
  10.   - route:
  11.     - destination:
  12.         host: reviews
  13.         subset: v2
  14. EOF
  1. 路由请求到ratings服务，添加2秒的延迟。
  1. kubectl create -f - <<EOF
  2. apiVersion: networking.istio.io/v1alpha3
  3. kind: VirtualService
  4. metadata:
  5.   name: ratings
  6. spec:
  7.   hosts:
  8.   - ratings
  9.   http:
  10.   - fault:
  11.       delay:
  12.         percent: 100
  13.         fixedDelay: 2s
  14.     route:
  15.     - destination:
  16.         host: ratings
  17.         subset: v1
  18. EOF

  1. 打开浏览器http://$GATEWAY_URL/productpage,应该能看到Bookinfo的应用工作正常，但你刷新页面时，它会有2秒的延迟。

  2. 现在针对调用reviews服务添加0.5秒的延迟。

  1. kubectl apply -f - <<EOF
  2. apiVersion: networking.istio.io/v1alpha3
  3. kind: VirtualService
  4. metadata:
  5.   name: reviews
  6. spec:
  7.   hosts:
  8.   - reviews
  9.   http:
  10.   - route:
  11.     - destination:
  12.         host: reviews
  13.         subset: v2
  14.     timeout: 0.5s
  15. EOF

现在，您应该看到它在大约1秒(而不是2秒)后返回，并且reviews不可用

即使超时配置为半秒，响应也需要1秒，这是因为在productpage服务中有一个硬编码的重试，所以它在返回之前会两次调用计时的 reviews服务。

5. 请求的超时 - 图1

3. 理解发生了什么？

在此任务中，使用istio针对调用reviews微服务的请求超时时间设置为半秒。 但是默认的请求超时是关闭的。 因此当reviews服务去调用ratings服务时，而我们设置的调用超时时间为2秒。这就导致了reviews的微服务超时，因为2秒大于它本身设置的0.5秒。

仔细观察reviews服务页面显示，你就会发现Sorry, product reviews are currently unavailable for this book..这其实就是从reviews服务收到的结果。

如果你要仔细检查故障注入,你会发现productpage微服务去调用reviews微服务也有它相应的应用级别超时。

4. 清除本实验

  1. $ kubectl delete -f samples/bookinfo/networking/virtual-service-all-v1.yaml