Istio分层架构?80%的人有误解

简介: Istio是ServiceMesh的产品化落地。

  ServiceMesh(3)

 

前篇:

《ServiceMesh究竟解决什么问题》

《什么是Istio,ServiceMesh最流行落地》

 

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的架构设计,官网用了这样一句话:
image.png

逻辑上,Istio分为:

  • 数据平面(data plane)

  • 控制平面(control plane)

这两个词,是Istio架构核心,但又是大家被误导最多的地方。

 

数据平面和控制平面,不是ServiceMesh和Istio第一次提出,它是计算机网络,报文路由转发里很成熟的概念:
image.png

数据平面(data plane):一般用来做快速转发

控制平面(control plane):为快速转发提供必要的信息
image.png

画外音:上两图为路由器架构。

 

它的设计原则是:

  • 在一个路由设备里,转发是最重要的工作,它具备最高的优先级数据平面(data plane)的设计核心就是高效转发,如何在最短的时间里处理最多的包,往往使用高效内存管理、队列管理、超时管理等技术实现在硬件里

  • 控制平面(control plane)则不然,它要实现路由协议,设备管理,IGMP,ARP协议的,它更偏向于控制与应用,往往由软件实现

画外音:

IGMP(Internet GroupManagement Protocol),一个组播协议;

ARP(Address ResolutionProtocol),这个大家比较熟悉,根据IP地址获取MAC地址;

 

Istio的架构核心与路由器非常类似:
image.png

服务(最上面的小红框),通过本地通讯与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)

半吊子英语的程序员,二手的技术文档,真害人,唉。

 

总结
image.png

Istio采用二层架构五大模块,进行微服务ServiceMesh解耦:

  • 数据平面,主要负责高效转发

(1)envoy模块:即proxy;

  • 控制平面,主要负责控制与应用

(2)mixer模块:支持跨平台,标准化API的adapter;

(3)pilot模块:控制与配置envoy的大部分策略;

(4)citadel模块:安全相关;

(5)galley模块:与底层平台(例如:K8S)配置解耦;

 

实施与控制分离,经典的架构设计方法,GOT?

思路比结论重要。

本文转自“架构师之路”公众号,58沈剑提供。

目录
相关文章
|
1月前
|
人工智能 前端开发 JavaScript
前端架构思考 :专注于多框架的并存可能并不是唯一的方向 — 探讨大模型时代前端的分层式微前端架构
随着前端技术的发展,微前端架构成为应对复杂大型应用的流行方案,允许多个团队使用不同技术栈并将其模块化集成。然而,这种设计在高交互性需求的应用中存在局限,如音视频处理、AI集成等。本文探讨了传统微前端架构的不足,并提出了一种新的分层式微前端架构,通过展示层与业务层的分离及基于功能的横向拆分,以更好地适应现代前端需求。
|
25天前
|
监控 安全 Cloud Native
云原生安全:Istio在微服务架构中的安全策略与实践
【10月更文挑战第26天】随着云计算的发展,云原生架构成为企业数字化转型的关键。微服务作为其核心组件,虽具备灵活性和可扩展性,但也带来安全挑战。Istio作为开源服务网格,通过双向TLS加密、细粒度访问控制和强大的审计监控功能,有效保障微服务间的通信安全,成为云原生安全的重要工具。
40 2
|
1月前
|
Kubernetes 安全 微服务
使用 Istio 缓解电信 5G IoT 微服务 Pod 架构的安全挑战
使用 Istio 缓解电信 5G IoT 微服务 Pod 架构的安全挑战
56 8
|
1月前
|
JSON 前端开发 Java
Spring Boot框架中的响应与分层解耦架构
在Spring Boot框架中,响应与分层解耦架构是两个核心概念,它们共同促进了应用程序的高效性、可维护性和可扩展性。
53 3
|
1月前
|
存储 前端开发 API
DDD领域驱动设计实战-分层架构
DDD分层架构通过明确各层职责及交互规则,有效降低了层间依赖。其基本原则是每层仅与下方层耦合,分为严格和松散两种形式。架构演进包括传统四层架构与改良版四层架构,后者采用依赖反转设计原则优化基础设施层位置。各层职责分明:用户接口层处理显示与请求;应用层负责服务编排与组合;领域层实现业务逻辑;基础层提供技术基础服务。通过合理设计聚合与依赖关系,DDD支持微服务架构灵活演进,提升系统适应性和可维护性。
|
3月前
|
Kubernetes 安全 微服务
使用 Istio 缓解电信 5G IoT 微服务 Pod 架构的安全挑战
在5G电信领域,Kubernetes集群中部署微服务至关重要,但也带来了重大的安全挑战。Istio作为一个强大的开源服务网格,能有效地管理这些微服务间的通信,通过其控制平面自动将Sidecar代理注入到各微服务Pod中,确保了安全且高效的通信。Istio的架构由数据平面和控制平面组成,其中Sidecar代理作为Envoy代理运行在每个Pod中,拦截并管理网络流量。此外,Istio支持多种Kubernetes发行版和服务,如EKS等,不仅增强了安全性,还提高了应用性能和可观测性。
77 0
使用 Istio 缓解电信 5G IoT 微服务 Pod 架构的安全挑战
|
3月前
|
存储 消息中间件 JSON
|
4月前
|
运维 Java Docker
业务系统架构实践问题之在某些情况下,将能力代码和业务逻辑严格分层可能是一个挑战问题如何解决
业务系统架构实践问题之在某些情况下,将能力代码和业务逻辑严格分层可能是一个挑战问题如何解决
|
4月前
|
存储 搜索推荐 API
业务系统架构实践问题之分层架构中的四层定位是什么
业务系统架构实践问题之分层架构中的四层定位是什么
135 0
|
14天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
下一篇
无影云桌面