Istio,灰度发布从未如此轻松!!!

jujusharp  •  May 25, 2019 8:57:21 AM

原文地址


三个问题,回顾前情提要。

ServiceMesh解决什么问题?

SM本质是业务服务底层技术体系解耦

  • 一个进程实现业务逻辑(不管是调用方,还是服务提供方),biz,即上图白色方块

  • 一个进程实现底层技术体系,proxy,即上图蓝色方块

画外音:负载均衡、监控告警、服务发现与治理、调用链…等诸多基础设施,都放到这一层实现。

什么是Istio?

Istio是ServiceMesh的产品化落地。

Istio的分层架构设计如何?

Istio采用实施与控制分离的数据平面与控制平面两层架构。

数据平面

  • envoy(proxy):负责高效转发与策略落地[核心]

控制平面

  • mixer:适配组件,数据平面与控制平面通过它交互

  • pilot:策略配置组件[核心]

  • citadel:安全组件

  • galley:底层平台(例如:K8S)解耦组件

整个架构的核心是envoy与pilot。

今天起,聊聊Istio的流控,典型如灰度发布。

就如同ServiceMesh的设计初衷,是技术体系与业务服务解耦一样,Istio流控模型的本质,是流量控制与服务实例扩展的解耦,更具体的:

  • 用户只需要通过控制平面中的Pilot设定期望流量要以什么规则进行路由

  • 不需要规定服务实例(service pods)如何接收

  • 数据平面Envoy将从Pilot中获取规则和命令,然后落地各类分流策略

如上图所示,最开始时,ServiceA访问旧版的ServiceB。

画外音,业务与底层解耦:

(1)灰色圆形为业务Svc服务;

(2)紫色六边形为Envoy代理;

(3)服务与代理之间都是本地访问;

(4)跨网段之间都是Envoy代理交互(蓝色箭头);

如何进行灰度发布呢?

如上图所示,服务A调用服务B,服务B要发布一个灰度版本,需要5%的流量打到服务B的新版本,只需要:

(1)部署服务B的新版本;

(2)控制平面Pilot上进行策略配置,策略同步到Envoy;

(3)数据平面Envoy接收到策略配置,实时分流策略;

画外音:图形上没有画出Pilot和Envoy的交互。

搞定,这个过程业务服务与流量控制策略完全解耦,完美!

除了基于按流量比例分流的灰度发布,基于应用层的灰度发布通过Istio也非常容易实现。

如上图所示,服务B要发布一个灰度版本,需要把iPhone的流量打到B的新版本,操作流程完全一样(部署服务,Pilot控制,Envoy实施),非常方便。

如果Envoy原来只支持按照流量比例分流,不支持基于应用层协议分流,此时只需要:

(1)升级Envoy的分流策略,以及策略控制端Pilot;

(2)调用方服务A不需要升级;

(3)服务方服务B也不需要升级;

业务与底层基础设施完全解耦,完美!

画外音:这是Service Mesh的核心理念之一,详见《ServiceMesh究竟解决什么问题》。

如果是用传统微服务框架的方式,需要框架升级,调用方与服务方均需要配合升级与重启。

最近下班都比较晚,今天先写到这里。Pilot的分层架构如何,它又是如何与Envoy配合实现流控的,且听下回分解。

思路比结论重要。

架构师之路-分享技术思路

相关文章:

ServiceMesh究竟解决什么问题?

Istio究竟是什么?

Istio分层架构设计?

大伙升级一个流控策略,业务服务要升级,要重启么?

0 回复
暂时没有回复,你也许会成为第一个哦