通常，我们服务程序都会打一个版本号（v1，v2 ...),我们发布了v1版本后，下次需要发布v2,但是我们不想所有用户使用新版v2，这时可以利用请求路由功能，把10%的用户引导使用v2,90%的用户还是继续使用v1。当v2运行稳定后，再把100%的用户导向使用v2版本。如下图
如上图所示，客户端不知道服务不同版本间的差异。他们可以使用主机名/IP地址继续访问服务。Envoy sidecar/代理拦截并转发客户端和服务器之间的所有请求/响应。
运维人员使用Pilot指定路由规则，Envoy根据这些规则动态地确定其服务版本的实际选择。该模型使应用程序代码能够将它从其依赖服务的演进中解耦出来，同时提供其他好处（参见 Mixer）。路由规则允许Envoy根据诸如header，与源/目的地相关联的标签和/或分配给每个版本的权重的标准来选择版本。
Istio还为同一服务版本的多个实例提供流量负载均衡。可以在服务发现和负载均衡中找到更多信息。
Istio不提供DNS。应用程序可以尝试使用底层平台（kube-dns，mesos-dns等）中存在的DNS服务来解析FQDN。
这里以bookinfo为例子，将“reviews”服务90％的传入流量发送到“v1”版本，10％的传入流量发送到“v2”版本。DSL规则如下描述：
cat ./bookinfo-rule.yaml:
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
name: reviews-default
spec:
destination:
name: reviews
route:
- labels:
version: v1
weight: 90
- labels:
version: v2
weight: 10
istioctl create -f ./bookinf-rule.yaml这时候再访问 http://${GATEWAY_URL}/productpage 会有90%的流量指向v1,10%的流量指向v2 。
destination是service的名称，流量将被导向到这里。
route lables标记将接受流量的特定服务实例。如在samples/bookinfo/kube/bookinfo.yaml中相应名称：
....
apiVersion: v1
kind: Service
metadata:
name: reviews
labels:
app: reviews
spec:
ports:
- port: 9080
name: http
selector:
app: reviews
......
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: reviews-v1
spec:
replicas: 1
template:
metadata:
labels:
app: reviews
version: v1
......
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: reviews-v2
spec:
replicas: 1
template:
metadata:
labels:
app: reviews
version: v2
......Ingress和Egress
Istio假定进入和离开服务网络的所有流量都会通过Envoy代理进行传输。通过将Envoy代理部署在服务之前，运维人员可以针对面向用户的服务进行A/B测试，部署金丝雀服务等。类似地，通过使用Envoy将流量路由到外部Web服务（例如，访问Maps API或视频服务API），运维人员可以添加故障恢复功能，例如超时、重试、熔断器等，并在访问这些服务的连接上获得详细指标。
参考：
http://istio.doczh.cn/docs/reference/config/istio.routing.v1alpha1.md
http://istio.doczh.cn/docs/tasks/traffic-management/request-routing.html
https://istio.io/docs/tasks/traffic-management/request-routing.html
https://istio.io/docs/concepts/traffic-management/rules-configuration.html