内容简介:三个问题,回顾前情提要。ServiceMesh解决什么问题?
三个问题,回顾前情提要。
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分层架构设计? 》
调研:
大伙升级一个流控策略,业务服务要升级,要重启么?
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- Alodi:环境创建从未如此简单
- 使用REST规范从未完成的5件事
- iphone – 从未调用过MKAnnotationView viewForAnnotation
- 为什么微服务从未被技术雷达“采纳”?
- 从未排序的链表中删除重复项
- 从未如此简单:10分钟带你逆袭Kafka!
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。