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

标签: istio 灰度 | 发表时间:2020-12-24 09:57 | 作者:58沈剑_架构师之路
出处:https://juejin.im/backend

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

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 配合实现流控的,且听下回分解。

思路比结论重要。

调研:

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

相关 [istio 灰度] 推荐:

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

- - 掘金后端
ServiceMesh 解决什么问题. SM 本质是 业务服务与 底层技术体系的 解耦:. 一个进程实现业务逻辑(不管是调用方,还是服务提供方),. 画外音:负载均衡、监控告警、服务发现与治理、调用链… 等诸多基础设施,都放到这一层实现. Istio 是 ServiceMesh 的产品化落地.

istio灰度发布流量管理_llarao的博客-CSDN博客_istio使用

- -
VirtualService路由规则配置. 1.HttpRoute的路由目标. 2.HTTPRedirect重定向. 3.HTTPRewrite重写. 4.HTTPRerty重试. 6.HttpFaultInjection故障注入. DestinationRule目标规则. DestinationRule规则定义.

基于 Istio 的全链路灰度方案探索和实践 - 阿里巴巴云原生 - 博客园

- -
审核&校对:曾宇星(宇曾). 微服务软件架构下,业务新功能上线前搭建完整的一套测试系统进行验证是相当费人费时的事,随着所拆分出微服务数量的不断增大其难度也愈大. 这一整套测试系统所需付出的机器成本往往也不低,为了保证应用新版本上线前的功能正确性验证效率,这套系统还必须一直单独维护好. 当业务变得庞大且复杂时,往往还得准备多套,这是整个行业共同面临且难解的成本和效率挑战.

istio 原理简介

- - 掘金 架构
由于 istio 自 1.5 版本以后架构上有了较大变化,控制面从多组件变成了单体的 istiod 组件,所以下文会先介绍 1.5 之前的架构,再介绍 1.5 之后的,是一个由繁到简的过程. istio 1.5 之前架构. Istio 的架构分为控制平面和数据平面. 数据平面:由一组智能代理(Envoy)以 sidecar 模式部署,协调和控制所有服务之间的网络通信.

Istio 常见的 10 个异常分析

- - DockOne.io
本文总结了使用 Istio 常见的 10 个异常. Istio 支持多平台,不过 Istio 和 Kubernetes 的兼容性是最优的,不管是设计理念,核心团队还是社区, 都有一脉相承的意思. 但 Istio 和 Kubernetes 的适配并非完全没有冲突,一个典型问题就是 Istio 需要 Kubernetes Service 按照协议进行端口命名(Port Naming).

Istio究竟是干嘛的? - 知乎

- -
当微服务架构体系越来越复杂的时候,需要将“业务服务”和“基础设施”解耦,将一个微服务进程一分为二:. 一个进程实现业务逻辑,biz,即上图白色方块. 一个进程实现底层技术体系,proxy,即上图蓝色方块,负载均衡、监控告警、服务发现与治理、调用链…等诸多基础设施,都放到这一层实现. biz不管是调用服务,还是提供服务,都只与本地的proxy进行本地通信.

使用 Istio 进行金丝雀部署

- -
本篇博客最后更新时间 2018 年 5 月 16 号,采用了最新版本的流量管理模型. Istio项目的一大好处就是为服务金丝雀方式部署提供了控制便利. 金丝雀部署(或上线)背后的想法是通过让一小部分用户流量引入的新版本进行测试,如果一切顺利,则可以增加(可能逐渐增加)百分比,逐步替换旧版本. 如在过程中出现任何问题,则可以中止并回滚到旧版本.

实践k8s istio熔断 - fat_girl_spring - 博客园

- -
熔断主要是无感的处理服务异常并保证不会发生级联甚至雪崩的服务异常. 在微服务方面体现是对异常的服务情况进行快速失败,它对已经调用失败的服务不再会继续调用,如果仍需要调用此异常服务,它将立刻返回失败. 与此同时,它一直监控服务的健康状况,一旦服务恢复正常,则立刻恢复对此服务的正常访问. 这样的快速失败策略可以降低服务负载压力,很好地保护服务免受高负载的影响.

知乎落地的 Service Mesh Istio

- -
在知乎,我们很早就进行了非常彻底的容器化部署. 全站在线运行的微服务数量高达两千多个. 这些微服务通过我们自己维护的 RPC 框架和 Kodor 体系来实现服务互联的能力. 在这其中,我们也存在一系列的问题:. 各种基础组件维护成本比较高,单点风险存在. 各语言客户端特性难以统一,熔断、重试等特性实现颇有不同,且不能做到动态线上进行调整.

Istio 中的服务和流量的抽象模型

- - IT瘾-dev
本文介绍了 Istio 和 Kubernetes 中的一些服务和流量的抽象模型. 虽然 Istio 一开始确定的抽象模型与对接的底层平台无关,但目前来看基本绑定 Kubernetes,本文仅以 Kubernetes 说明. 另外在 ServiceMesher 社区中最近有很多关于 Istio、Envoy、Kubernetes 之中的服务模型关系的讨论,本文作为一个开篇说明,Kubernetes 和 Isito 之间有哪些共有的服务模型,Istio 在 Kubernetes 的服务模型之上又增加了什么,为什么说 Kubernetes service 存在的意义仅剩下做服务发现.