ServiceMesh&Istio入门
参考:微信公众号:架构师之路
ServiceMesh(1)
ServiceMesh究竟解决什么问题?
服务网格(ServiceMesh)这两年异常之火,号称是下一代微服务架构,接下来两个月,准备系统性的写写这个东西,希望能够让大家对最新的架构技术,有个初步的了解。
画外音:我的行文的风格了,“为什么”往往比“怎么样”更重要。
互联网公司,经常使用的是微服务分层架构。
画外音:为什么要服务化,详见《服务化到底解决什么问题?》。
随着数据量不断增大,吞吐量不断增加,业务越来越复杂,服务的个数会越来越多,分层会越来越细,除了数据服务层,还会衍生出业务服务层,前后端分离等各种层次结构。
画外音:分层的细节,详见《互联网分层架构演进》。
不断发现主要矛盾,抽离主要矛盾,解决主要矛盾,架构自然演进了,微服务架构,潜在的主要矛盾会是什么呢?
引入微服务架构,一般会引入一个RPC框架,来完成整个RPC的调用过程。
如上图粉色部分所示,RPC分为:
-
RPC-client,它嵌在调用方进程里
-
RPC-server,是服务进程的基础
画外音:《离不开的微服务架构,脱不开的RPC细节》。
不只是微服务,MQ也是类似的架构:
如上图粉色部分所示,MQ分为:
-
MQ-send-client
-
MQ-server
-
MQ-recv-client
画外音:《MQ,互联网架构解耦神器》。
框架只是第一步,越来越多和RPC,和微服务相关的功能,会被加入进来。
例如:负载均衡
如果要扩展多种负载均衡方案,例如:
-
轮询
-
随机
-
取模
-
一致性哈希
RPC-client需要进行升级。
例如:数据收集
如果要对RPC接口处理时间进行收集,来实施统一监控与告警,也需要对RPC-client进行升级。
画外音,处理时间分为:
-
客户端视角处理时间
-
服务端视角处理时间
如果要收集后者,RPC-server也要修改与上报。
又例如:服务发现
服务新增一个实例,通知配置中心,配置中心通知已注册的RPC-client,将流量打到新启动的服务实例上去,迅猛完成扩容。
再例如:调用链跟踪
如果要做全链路调用链跟踪,RPC-client和RPC-server都需要进行升级。
下面这些功能:
-
负载均衡
-
数据收集
-
服务发现
-
调用链跟踪
-
…
其实都不是业务功能,所以互联网公司一般会有一个类似于“架构部”的技术部门去研发和升级相关功能,而业务线的技术部门直接使用相关框架、工具与平台,享受各种“黑科技”带来的便利。
完美!!!
理想很丰满,现实却很骨感,由于:
-
RPC-client,它嵌在调用方进程里
-
RPC-server,是服务进程的基础
往往会面临以下一些问题:
-
业务技术团队,仍需要花时间去学习、使用基础框架与各类工具,而不是全心全意将精力花在业务和产品上
-
client要维护m个版本, server要维护n个版本,兼容性要测试m*n个版本
-
如果要支持不同语言,往往要开发C-client,Python-client,go-client,Java-client多语言版本
-
每次“黑科技”的升级,都需要推动上下游进行升级,这个周期往往是以季度、半年、又甚至更久,整体效率极低
画外音:兄弟,贵司推广一个技术新产品,周期要多长?
这些耦合,这些通用的痛点,有没有办法解决呢?
一个思路是,将服务拆分成两个进程,解耦。
-
一个进程实现业务逻辑(不管是调用方,还是服务提供方),biz,即上图白色方块
-
一个进程实现底层技术体系,proxy,即上图蓝色方块
画外音:负载均衡、监控告警、服务发现与治理、调用链…等诸多基础设施,都放到这一层实现。
-
biz和proxy共同诞生,共同消亡,互为本地部署,即上图虚线方框
-
biz和proxy之间,为本地通讯,即上图黑色箭头
-
所有biz之间的通讯,都通过proxy之间完成,proxy之间才存在远端连接,即上图红色箭头
这样就实现了“业务的归业务,技术的归技术”,实现了充分解耦,如果所有节点都实现了解耦,整个架构会演变为:
-
绿色为biz
-
蓝色为proxy
整个服务集群变成了网格状,这就是Service Mesh服务网格的由来。
架构演进,永无穷尽,痛点多了,自然要分层解耦。希望大家有收获,后续再细聊SM的设计与架构细节。
思路比结论更重要。
ServiceMesh(2)
Istio究竟是干嘛的?
上一篇介绍了《ServiceMesh究竟解决什么问题?》,当微服务架构体系越来越复杂的时候,需要将“业务服务”和“基础设施”解耦,将一个微服务进程一分为二:
-
一个进程实现业务逻辑,biz,即上图白色方块
-
一个进程实现底层技术体系,proxy,即上图蓝色方块,负载均衡、监控告警、服务发现与治理、调用链…等诸多基础设施,都放到这一层实现
如此解耦之后:
-
biz不管是调用服务,还是提供服务,都只与本地的proxy进行本地通信
-
所有跨网的通信,都通过proxy之间进行
要聊ServiceMesh,就不得不提Istio,它是ServiceMesh目前最流行的实践,今天说说Istio是干啥的。
画外音:不能落伍。
什么是Istio?
Istio是ServiceMesh的产品化落地,它的一些关键性描述是:
-
帮助微服务之间建立连接,帮助研发团队更好的管理与监控微服务,并使得系统架构更加安全
画外音:Istio helps you to connect, secure, control, and observe microservices.
-
帮助微服务分层解耦,解耦后的proxy层能够更加专注于提供基础架构能力,例如:
(1)服务发现(discovery);
(2)负载均衡(load balancing);
(3)故障恢复(failure recovery);
(4)服务度量(metrics);
(5)服务监控(monitoring);
(6)A/B测试(A/B testing);
(7)灰度发布(canary rollouts);
(8)限流限速(rate limiting);
(9)访问控制(access control);
(10)身份认证(end-to-end authentication);
画外音:佩服,硬是凑齐了十条,其实SM还能提供更多基础服务功能。
-
使得业务工程团队与基础架构团队都更加高效的工作,各自专注于自己的工作,更好的彼此赋能
画外音:说的还是解耦。
Istio官网是怎么吹嘘自己的?
画外音:这个问题的另一个问法是“为什么大家要来用Istio”。
Istio非常牛逼,如果要实施ServiceMesh,必须用Istio,因为:
-
可以通过,在现有服务器新增部署边车代理(sidecar proxy),应用程序不用改代码,或者只需要改很少的代码,就能实现上述N项基础功能
画外音:你信了么?
-
可以通过,控制后台,简单改改配置,点点按钮,就能管理和查看上述N项基础功能
-
以下特性,Istio在这个环节里进行了附加说明:
(1)负载均衡支持多协议,HTTP, gRPC, WebSocket, TCP;
(2)通过路由、重试、故障转移对流量进行细粒度流控;
(3)通过可插拔策略层以及可配置API,能够支持流量访问控制、限速、配额管理;
(4)自动度量、日志收集、调用跟踪;
(5)服务到服务的身份认证;
Istio的核心特性是什么?
Istio强调了它提供的五项关键特性:
-
流控(traffic management)
画外音:断路器(circuit breakers)、超时、重试、高可用、多路由规则、AB测试、灰度发布、按照百分比分配流量等。
-
安全(security)
画外音:加密、身份认证、服务到服务的权限控制、K8S里容器到容器的权限控制等。
-
可观察(observability)
画外音:追踪、监控、数据收集,通过控制后台全面了解上行下行流量,服务链路情况,服务运行情况,系统性能情况,国内微服务架构体系,这一块做得比较缺乏。
-
平台无关系(platform support)
画外音:K8s,物理机,自己的虚机都没问题。
-
集成与定制(integration and customization)
画外音:可定制化扩展功能。
Istio的吹嘘与特性,对于国外很多通过RESTful提供内网服务的公司,很有吸引力,但相对于国内微服务架构,未必达到了很好的拉拢效果:
(1)国内基本都是TCP的RPC框架,多协议支持未必是必须的;
(2)RPC框架里,路由、重试、故障转移、负载均衡、高可用都是最基础的;
(3)流控、限速、配额管理,是服务治理的内容,在微服务架构初期是锦上添花;
(4)自动度量,系统入口出口数据收集,调用跟踪,可观察和可操控的后台确实是最吸引人的;
(5)服务到服务的身份认证,微服务基本是内网访问,在架构初期也只是锦上添花;
另外一个花边,为什么代理会叫sidecar proxy?
看了上图就容易懂了,biz和proxy相生相伴,就像摩托车(motor)与旁边的车厢(sidecar)。未来,sidecar和proxy就指微服务进程解耦成两个进程之后,提供基础能力的那个代理进程。
Istio这么牛逼,它的核心架构如何呢?
且听下回分解。
ServiceMesh(3)
Istio分层架构?80%的人有误解
前篇:
Istio是ServiceMesh的产品化落地:
-
它帮助微服务之间建立连接,帮助研发团队更好的管理与监控微服务,并使得系统架构更加安全
-
它帮助微服务分层解耦,解耦后的proxy层能够更加专注于提供基础架构能力,例如:
(1)服务发现(discovery)
(2)负载均衡(load balancing)
(3)故障恢复(failure recovery)
(4)服务度量(metrics)
(5)服务监控(monitoring)
(6)A/B测试(A/B testing)
(7)灰度发布(canary rollouts)
(8)限流限速(rate limiting)
(9)访问控制(access control)
(10)身份认证(end-to-end authentication)
等功能。
-
它使得业务工程团队与基础架构团队都更加高效的工作,各自专注于自己的工作,更好的彼此赋能
今天来说一下Istio的核心架构设计。
关于Istio的架构设计,官网用了这样一句话:
逻辑上,Istio分为:
-
数据平面(data plane)
-
控制平面(control plane)
这两个词,是Istio架构核心,但又是大家被误导最多的地方。
数据平面和控制平面,不是ServiceMesh和Istio第一次提出,它是计算机网络,报文路由转发里很成熟的概念:
-
数据平面(data plane):一般用来做快速转发
-
控制平面(control plane):为快速转发提供必要的信息
画外音:上两图为路由器架构。
它的设计原则是:
-
在一个路由设备里,转发是最重要的工作,它具备最高的优先级,数据平面(data plane)的设计核心就是高效转发,如何在最短的时间里处理最多的包,往往使用高效内存管理、队列管理、超时管理等技术实现在硬件里
-
控制平面(control plane)则不然,它要实现路由协议,设备管理,IGMP,ARP协议的,它更偏向于控制与应用,往往由软件实现
画外音:
IGMP(Internet GroupManagement Protocol),一个组播协议;
ARP(Address ResolutionProtocol),这个大家比较熟悉,根据IP地址获取MAC地址;
Istio的架构核心与路由器非常类似:
-
服务(最上面的小红框),通过本地通讯与proxy交互
-
数据平面,由一系列proxy组成(中间一层的两个小红框),核心职责是:
(1)高效转发;
(2)接收和实施来自mixer的策略;
-
控制平面(底下的大红框),核心是控制与应用,核心职责是:
(1)管理和配置边车代理;
(2)通过mixer实施策略与收集来自边车代理的数据;
画外音:
(1)sidecar proxy,原文使用的是envoy,后文envoy表示代理;
(2)mixer,不确定要怎么翻译了,有些文章叫“混音器”,后文直接叫mixer;
(3)pilot,galley,citadel,不敢翻译为飞行员,厨房,堡垒,后文直接用英文;
如架构图所示,该两层架构中,有五个核心组件。
数据平面,有一个核心组件:
Envoy (proxy)
Envoy的核心职责是高效转发,更具体的,它具备这样一些能力:
(1)服务发现
(2)负载均衡
(3)安全传输
(4)多协议支持,例如HTTP/2,gRPC
(5)断路器(Circuit breakers)
(6)健康检查
(7)百分比分流路由
(8)故障注入(Fault injection)
(9)系统度量
大部分能力是RPC框架都具备,或者比较好理解的,这里面重点介绍下断路器和故障注入。
断路器设计
它是软件架构设计中,一个服务自我保护,或者说降级的设计思路。
举个例子:当系统检测出某个接口有大量超时时,断路器策略可以终止对这个接口的调用(断路器打开),经过一段时间后,再次尝试调用,如果接口不再超时,则慢慢恢复调用(断路器关闭)。
故障注入设计
它是软件架构设计中,一种故意引入故障,以扩大测试覆盖范围,保障系统健壮性的方法,主要用于测试。
国内大部分互联网公司,架构设计中不太会考虑故障注入,在操作系统内核开发与调试,路由器开发与调试中经常使用,可以用来模拟内存分配失败、磁盘IO错误等一些非常难出现的异常,以确保测试覆盖度。
控制平面,有四个核心组件:
Mixer
Mixer的一些核心能力是:
(1)跨平台,作为其他组件的adapter,实现Istio跨平台的能力;
(2)和Envoy通讯,实时各种策略
(3)和Envoy通讯,收集各种数据
Mixer的设计核心在于“插件化”,这种模型使得Istio能够适配各种复杂的主机环境,以及后端基础设施。
Pilot
Pilot作为非常重要的控制平面组件,其核心能力是:
(1)为Envoy提供服务发现能力;
(2)为Envoy提供各种智能路由管理能力,例如A/B测试,灰度发布;
(3)为Envoy提供各种弹性管理能力,例如超时,重试,断路策略;
Pilot的设计核心在于“标准化”,它会将各种流控的控制命令转化为Envoy能够识别的配置,并在运行时,将这些指令扩散到所有的Envoy。Pilot将这些能力抽象成通用配置的好处是,所有符合这种标准的Envoy都能够接入到Pilot来。
潜台词是,任何第三方可以实现自己的proxy,只要符合相关的API标准,都可以和Pilot集成。
Citadel
Citadel组件,它提供终端用户身份认证,以及服务到服务的访问控制。总之,这是一个和安全相关的组件。
Galley
Gally组件,它是一个配置获取、校验、处理、分发的组件,它的设计核心在于“解耦”,它将“从底层平台(例如:K8S)获取用户配置”与Istio解耦开来。
花边:为什么80%的中文用户对Istio的二层架构的了解是错的?
很多朋友问我,通过什么渠道学习最新的技术知识,我的回答一直是,英文官网。
画外音:本文所有信息来源于Istio1.1英文官网。
我在百度搜了下Istio,80%的资料,将二层架构翻译为:
-
数据面板
-
控制面板
画外音:大家可以百度搜一下“istio 控制面板”
一开始我极其蒙圈,因为“数据平面”和“控制平面”是非常成熟的翻译,路由器就是使用这个二层架构,ServiceMesh使用相同的架构设计进行解耦,应该不需要创造性翻译呀。
后来,我懂了:
-
控制平面(control plane)
-
控制面板(control panel)
半吊子英语的程序员,二手的技术文档,真害人,唉。
总结
Istio采用二层架构,五大模块,进行微服务ServiceMesh解耦:
-
数据平面,主要负责高效转发
(1)envoy模块:即proxy;
-
控制平面,主要负责控制与应用
(2)mixer模块:支持跨平台,标准化API的adapter;
(3)pilot模块:控制与配置envoy的大部分策略;
(4)citadel模块:安全相关;
(5)galley模块:与底层平台(例如:K8S)配置解耦;
实施与控制分离,经典的架构设计方法,GOT?
思路比结论重要。
Istio,灰度发布从未如此轻松
三个问题,回顾前情提要。
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架构体系中,流控(Traffic Management)虽然是数据平面的Envoy Proxy实施的,但整个架构的核心其实在于控制平面的Pilot。
灰度发布的过程在《Istio,灰度发布》一文中已经有过描述,今天重点说说Pilot和Envoy的交互流程与内部结构。
一、通用交互流程
图示:
-
灰色圆形,为业务服务
-
紫色六边形,为Envoy代理
二者相生相伴。
起初,上游调用方ServiceA访问下游服务提供方ServiceB的V1版本,在ServiceB的V2版本部署好之后,调用方如何知道“SvcA切分1%的流量至SvcB的V2版本”这个指令的呢?
整个过程主要分为三大步骤:
(1)用户在控制平面的后台,通过Pilot的API,修改A到B的路由策略(标号1);
(2)Pilot将路由策略固化存储,以便未来新注册的调用方A能够知道当前最新的路由策略;对于已经存在的调用方A,Pilot则通过主动通知的方式告之调用方A对应的Envoy(标号2);
(3)Envoy作为数据平面,实施最新的路由策略(标号3),在本例中,即将1%的流量导给灰度版本Bv2;
二、服务发现与负载均衡
讲了通用的流控策略实施通用流程,而服务发现与负载均衡,只是一个种策略实施的特例:
(1)提供服务的SvcB新增一个Pod(标号1);
(2)在Pilot后台修改SvcB的集群配置(标号2);
(3)Pilot将SvcB的最新信息同步给该配置的订阅方(标号3),即SvcB的调用方SvcA对应的Proxy;
(4)SvcA对应的Proxy增加到SvcB的链接(标号4),并实施负载均衡;
画外音:实际是链接到SvcB对应的Proxy。
整个过程,与使用配置中心来实施服务发现基本类似。
三、请求的入口及出口
ServiceMesh的核心,是技术基础设施与业务服务的解耦,服务A调用服务B,再次强调:
-
一个容器Pod内的一个服务,服务进程(SrvA/SrvB)和边车进程(Proxy)是相生相伴的,他们之间的交互是本地交互(标号1)
-
跨容器Pod之间的远程调用,必须通过Proxy进行(标号2)
言下之意,服务A调用服务B,请求的流程是:
SvcA -> SvcA Proxy -> SvcB Proxy -> SvcB
响应的流程则反过来:
SvcB -> SvcB Proxy -> SvcA Proxy -> SvcA
跨网之间调用,请求的入口和出口,都是Proxy。
四、Pilot内部结构
Pilot它的内部结构并不复杂:
(1)Pilot的核心,是各种流控策略的维护,Abstract Model;
(2)必然,Pilot需要提供接口给用户,增删查改这些策略,Rules API;
(3)一方面,Pilot需要保持各类底层基础设施的兼容性,Platform Adapter;
(4)另一方面,Pilot又需要保持不同Proxy实接口的兼容性,Envoy API;
这么设计的好处是:
-
Istio设计时已经考虑了异构的基础设施,不管底层是K8s还是其他体系,都可以兼容
-
任何第三方可以实现自己的proxy,只要符合相关的API标准,都可以和Pilot集成
Pilot与Envoy的配合,是Istio的核心,如此一来:
-
服务发现(discovery)
-
负载均衡(load balancing)
-
故障恢复(failure recovery)
-
服务度量(metrics)
-
服务监控(monitoring)
-
A/B测试(A/B testing)
-
灰度发布(canary rollouts)
-
限流限速(rate limiting)
等很多能力都可以实现了。
MerviceMesh并没有大家想的复杂。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· go语言实现终端里的倒计时
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· Ollama——大语言模型本地部署的极速利器
· 使用C#创建一个MCP客户端
· 分享一个免费、快速、无限量使用的满血 DeepSeek R1 模型,支持深度思考和联网搜索!
· Windows编程----内核对象竟然如此简单?
· ollama系列1:轻松3步本地部署deepseek,普通电脑可用