概要
要介绍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层。
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 将会按照深层配置的负载均衡模式进行分配，其余的则还按服务层面的负载均衡模式进行分配。
总结
本文只介绍了很小一部分istio请求路由的内容，其灵活的配置，非侵入式的设计，跨平台的支持极大地提升了开发效率，降低了测试难度。深入理解virtualservice，destinationrule等是使用istio功能的基本前提，熟练使用连接池和负载均衡配置可以在有限资源的前提下最大化的提升应用性能。
欢迎关注微信公众号【容器魔方】，如果您想加入容器交流技术群，添加管理员monicka，申请入群，容器圈的人看过来~
原文地址：http://blog.51cto.com/13762283/2307474