idou老师教你学Istio05: 如何用Isito实现智能路由配置

概要

要介绍 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： 对后端的最大请求数量，不设定会默认为102四、

• 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 功能的基本前提，熟练使用链接池和负载均衡配置能够在有限资源的前提下最大化的提高应用性能。