Istio与Ingress灰度发布对比

一、首先简单介绍下服务网格的概念：

服务网格能够通过一组网络代理来做到消除在分布式软件系统中管理所有服务到服务通信的责任，本质上，服务之间的请求是通过与服务一起运行但位于基础结构层之外的代理路由的，这些代理基本上为服务创建了一个网状网络--因此，名称为服务网格。通过这些代理，服务网格能够控制服务到服务通信的各个方面。 

Istio 提供了一个完整的服务网格解决方案，通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求，该服务网格具有负载均衡、服务间认证、监控等功能，只需要对服务的代码进行一点或不需要做任何改动。想要让服务支持 Istio，只需要在环境中部署一个特殊的 sidecar 代理，使用 Istio 控制平面功能配置和管理代理，拦截微服务之间的所有网络通信：  HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡。 通过丰富的路由规则、重试、故障转移和故障注入，可以对流量行为进行细粒度控制。 可插入的策略层和配置 API，支持访问控制、速率限制和配额。 对出入集群入口和出口中所有流量的自动度量指标、日志记录和跟踪。 通过强大的基于身份的验证和授权，在集群中实现安全的服务间通信 。

二、Istio灰度发布与ingress的区别

在使用k8s进行应用部署时可以使用ingress或istio来实现，从改造难度上来看，使用ingress只需要在原有的service上增加一层ingress的域名解析和代理，通过ingress配置灰度策略即可实现灰度发布，相较于istio改造难度更小。但是，改造难度小也意味着ingress在灰度发布过程中可扩展新更小，适应场景更少。

ingress对service进行代理，在灰度发布中需要使用多个域名+service组合完成灰度发布，

--Ingress为服务提供一层代理，将域名与服务绑定

--不能配置复杂的网关路由 

Ingress灰度发布

Istio为服务提供可灵活网关，通过虚拟服务设置各服务的路由规则，网关路由配置灵活 ，灵活使用virtual service可以将请求分发到同一个service绑定的不同deployment（通过tag区分）上

Istio灰度发布

从持续灰度发布部署的角度看，Istio能够保证只需要更新deployment和虚拟服务的路由即可持续进行版本更新，而ingress controller由于绑定的是service，每个版本都会创建不同命名的service服务，变更影响更大。 

因此，对于需要对多个后端微服务进行灰度发布的项目，推荐使用istio来进行灰度发布。

作者：赵心域

链接：移动云开发者社区

来源：移动云官网开发者社区