istio110学习笔记09Istio流量管理之设置请求超时和熔断
在前面的章节中，我们学习了Istio API资源对象中的VirtualService、DestinationRule、Gateway。它们可以用于将集群外部的流量(http或tcp)连接到服务网格中，并可以执行一些常见的流量管理功能，如设置请求路由、故障注入、流量传输(http或tcp)等。在本节中，我们将了解使用istio进行流量管理的另外两个常见功能:设置请求超时和融合。
设置请求超时。HTPP服务的请求超时可以由虚拟服务的路由规则中的超时字段指定。默认情况下，此配置是禁用的。以下测试是基于bookinfo应用完成的。
在这个测试中，评论服务的超时设置为1秒。为了观察测试结果，istio的故障注入功能也将用于向评级服务注入2秒延迟故障。
首先，执行以下命令来初始化bookinfo应用程序服务的路由规则:
kubectl apply-f samples/book info/networking/virtual-service-all-v1 . YAML
修改reviews服务的虚拟服务，并将reviews服务的所有请求路由到v2版本:
kubectl apply-f- lt；
对评级服务执行故障注入，注入2秒的延迟:
kubectl apply-f- lt；
此时，当您使用我们之前配置的Istio Gateway门户访问bookinfo应用https://bookinfo.example.com/productpage时，您会发现bookinfo应用运行正常(显示评级的星形符号)，但每次刷新页面时，会有2秒的延迟。
因为reviews:v2服务通过调用ratings服务来获取评级信息，所以默认reviews服务在默认情况下不设置请求超时，所以它将等待ratings服务中注入的2秒延迟，并且每次刷新页面时都会有2秒延迟。
由于productpage服务中有硬编码的重试，即遇到错误时会重试一次，我们将为调用review服务设置0.5秒的超时:
kubectl apply-f- lt；
此时，如果再次刷新/productpage页面，会有1秒的延迟，页面中的图书评分信息会出现错误。获取产品评论时出错！。这是因为这个请求的调用链如下:productpage(出现请求超时错误时重试)->: Reviews(请求超时设置为0.5秒)->: Ratings(延迟2秒注入)。可以看出，通过设置reviews服务的请求超时，实现了在微服务治理中设置请求超时的功能，完全在服务网格中实现，不入侵微服务的业务逻辑。通过在服务治理中设置请求超时，可以避免大量请求长时间占用资源。
融合是创建弹性微服务的重要模式。融合可以使应用程序应对故障、潜在峰值和其他未知网络因素。熔断机制是一种应对雪崩效应的微观业务链路保护机制。服务雪崩是指当呼叫链中的某个环节，尤其是服务提供商不可用时，会导致上游环节不可用，最终将这种影响扩大到整个系统，导致整个系统不可用。
以下将展示istio中交通管理的融合功能。
首先在k8s的默认命名空间中部署测试用的httpbin应用，因为之前在默认命名空间空中部署bookinfo应用时已经开启了istio sidecar的自动注入功能，所以在这里直接部署httpbin应用就足够了:
kubectl apply-f samples/http bin/http bin . YAML
httpbin.yaml的内容如下:
API version:v1kind:Service accountmetadata:name:http bin-API version:v1kind:Servicemetadata:name:http binlabels:app:http binService:http binspec:ports:-name:http
再一次，看看下图中istio中虚拟服务和目标规则之间的关系。熔丝的配置需要在目标规则上进行配置。
接下来，创建一个在调用httpbin时设置保险丝的目标规则:
kubectl apply-f- lt；
在httpbin的目标规则的trafficPolicy中定义了MaxConnections: 1和http1MaxPendingRequests: 1。这意味着，如果并发连接和请求的数量超过1，当在istio-proxy中进行进一步的请求和连接时，后续的请求和连接将被阻塞。
接下来，在k8s的默认命名空间空中部署httpbin的客户端程序fortio。Fortio专门用于负载测试。它可以控制连接数、并发和发送HTTP请求的延迟。因为默认命名室空在过去部署bookinfo应用时已经开启了istio sidecar的自动注入功能，所以可以直接部署在这里:
kubectl apply-f samples/http bin/sample-client/fortio-deploy . YAML
fortio-deploy.yaml的内容如下:
API version:v1kind:Servicemetadata:name:fortiolabels:app:fortioService:fortiospec:-port:8080name:httpselector:app:fortio-API version:apps/v1断路示例任务#给出了检查特使统计数据的示例。sidecar.istio.io/statsInclusionPrefixes: cluster . outbound，cluster_manager，listener_manager，http_mixer_filter，tcp_mixer_filter，server，cluster . xds-grpc标签:app:fortio规范:容器:-名称:fortioimage:fortio/fortio:latest _ releaseimagepull policy:alys端口:-container port:800
进入fortio的舱里测试一下。以下命令将从fortio向httpbin发送一个请求。如果返回200，成功的请求意味着fortio部署完成，可以进行下一次熔丝测试:
FORTIO _ POD = $(ku ectl get POD | grep FORTIO | awk ' { print $ 1 } ')ku ectl exec-it $ FORTIO _ POD- c FORTIO/usr/bin/FORTIO-load-curl http://http bin:8000/get
在下面的fortio中，向httpbin发送一个2并发(-c 2)的连接，请求20次(-n 20):
FORTIO _ POD = $(ku ectl get POD | grep FORTIO | awk ' { print $ 1 } ')ku ectl exec-it $ FORTIO _ POD- c FORTIO-/usr/bin/FORTIO load-C2-QPS 0-n 20-log level Warning http://http bin:8000/get......代码200:13(65.0%)代码503 : 7 (35.0 %)......
可以看出，35%的请求被fuses拦截，并返回503服务不可用。HTTP503服务不可用表示服务不可用，通常是因为服务器停机维护或过载。返回此状态代码也是合适的。
接下来，将并发连接数增加到3，请求20次:
FORTIO _ POD = $(ku bectl get POD | grep FORTIO | awk ' { print $ 1 } ')ku bectl exec-it $ FORTIO _ POD- c FORTIO-/usr/bin/FORTIO load-C3-QPS 0-n 20-log level Warning http://http bin:8000/getCode 200:2(10.0%)Code 503:18(90.0%)
可以看出，只有10%的请求成功，90%的请求被熔丝拦截。