要介绍istio请求路由，我们不由得先从pilot 和 envoy开始谈起。 在服务网格中，Pilot管理和配置所有的envoy实例。在pilot中，你几乎可以配置所有的关于流量导向规则及其他故障恢复规则。而Envoy不仅会获得从pilot拿到的基本负载均衡信息，同时周期性的健康检查，也会告诉所有的envoy其他的实例现在的运行状况。负载均衡信息，及健康检查的信息可以使envoy更加智能的去分发流量。
在上述的pilot结构中，不难理解，platform adapter作为平台适配器，可以使istio顺利的在任何平台下工作。Envoy Api则提供动态更新信息，服务发现及配置路由规则的功能。
请求路由
在istio中，envoy的存在为流入及流出的流量提供了可控和可视的基本条件。Envoy根据所维护的信息对请求流量的一方面有利于平衡各个pod的工作量，保证不会存在极端情况而是“雨露均沾”。另一方面，envoy对请求流量的分发，从使用者角度来讲是无感知的。
如图中，用户通过某个地址来访问服务A，服务A的envoy实时发现了网格内存在的服务B，并且根据既定的转发规则来分发流量（1%流入pod4访问B’版本其余99%根据负载均衡信息流入pod1-pod3访问B版本）。也正是envoy挂在服务外部的这一设计，方便开发和运维人员进行故障测试，熔断以及实时监控。
VirtualService & DestinationRule
Virtualservice
VirtualService中主要是定义了请求的路由规则，当某个请求满足了先前预设的路有条件，那么这个请求就会路由至预设的服务。我们看一个简单的VirtualService例子:
在这个virtualservice中，绿色范围内的host有两条内容，第一条是服务的短名称，实际上这个名称是省略后的FQDN，这里的全称应当是reviews.default.svc.cluster.local
中间标红的是规则所在的namespace，而不是reviews所在的namespace。第二条则是配置给reviews组件的通过负载均衡访问的地址。黄色部分则是路由地址，其中的subset对应的是服务中的版本。
DestinationRule
DestinationRule是路由后的流量访问策略，访问策略包含负载均衡算法，熔断等限制。下图是一个destinationrule的例子：
黄色部分很显然是服务的两个版本。绿色部分的意义是TrafficPolicy，里面配置的是负载均衡算法设定为最小连接数，当两个主机提供服务时，会自动选择连接数最小的主机。我们也可以在这里配置连接池，TLS连接，端口级别策略，自动移除不健康主机等设置。
连接池管理
连接池配置给上游主机，这意味着该主机所有获取到来自envoy的链接请求，都要遵循配置好的连接池原则，这些原则既可以配在TCP层也可以配在HTTP层。
| 所属 | 类型 | 描述 |
| TCP | ConnectionPoolSetting.TCPSettings | 由于HTTP和TCP的关系，这部分属性既会作用在http连接也会作用在tcp连接 |
| HTTP |
ConnectionPoolSetting.HTTPSettings |
这部分是对于应用层的HTTP连接专有的配置 |
HTTP连接池配置
http1MaxPendingRequests： 到目标主机最大等待请求数，如果不设定默认是1024，这是针对http1.1设定的，对于http2因为不会将请求放入队列所以不受影响。
http2MaxRequests： 对后端的最大请求数量，不设定会默认为1024、
maxRequestsPerConnection: 每次连接最大的请求数，如果这个属性值设为1，那么每次连接最多发送一个请求，也就是无法保持连接。
MaxRetries： 最大重试次数。
TCP连接池配置
MaxConnections: 最大连接数，但是只作用于http1.1也不作用于http2，因为后者只建立一次连接。
ConnectionTimeOut： TCP连接超时
负载均衡器配置
负载均衡概述
负载均衡有两种：基于负载均衡算法和基于一致性哈希。对于基于负载均衡算法的配置十分简便，只要在simpleLB配上响应的字段即可。
| 算法字段 | 描述 |
| ROUND_ROBIN | 简单的轮训算法，这也是默认的方式 |
| LEAST_CONN | 随机选择两个健康的主机，并且在两者中选择连接数少的一个 |
| RANDOM | 健康主机内随机选择 |
| PAASTHROUGH | 直接分发到目标地址主机 |
基于一致性哈希的负载均衡方式可以根据HTTP header，cookie来提供soft session affinity，但是这种负载均衡方式仅支持http连接。
| 算法字段 | 描述 |
| httpHeaderName | 根据http header获得哈希 |
| httpCookie | 根据http cookie获得哈希 |
| useSourceIp | 根据IP地址获得哈希 |
| minimumRingSize | 哈希环中最小虚拟节点数，默认是1024 |
负载均衡样例
负载均衡策略配置十分灵活，可以针对某个服务进行配置，配置后隶属于该服务的所有pod将会按照设定的负载均衡方式进行请求的分配，除此之外，istio也允许用户进行更深一层的配置，对于服务中的版本进行负载均衡配置的。配置后符合该版本的pod 将会按照深层配置的负载均衡模式进行分配，其余的则还按服务层面的负载均衡模式进行分配。下面我们根据一个实例来看这种情况。
如图所示，绿色的内容是针对服务层面设置的负载均衡方式，如果请求了ratings这个服务那么默认将会采用最小连接数这个负载均衡方式，如果请求访问这个服务需要的是v3版本这时候版本级的负载均衡方式将会覆盖服务级的负载均衡方式，这时则会使用ROUND_ROBIN的方式。不同层级的负载均衡设置可以让操作者更加细化自身的服务设计。
总结
本文只介绍了很小一部分istio请求路由的内容，其灵活的配置，非侵入式的设计，跨平台的支持极大地提升了开发效率，降低了测试难度。深入理解virtualservice，destinationrule等是使用istio功能的基本前提，熟练使用连接池和负载均衡配置可以在有限资源的前提下最大化的提升应用性能。