Istio究竟是干嘛的?

本文涉及的产品
网络型负载均衡 NLB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
简介: Istio强调了它提供的五项关键特性。

ServiceMesh(2)
上一篇介绍了《ServiceMesh究竟解决什么问题?》,当微服务架构体系越来越复杂的时候,需要将“业务服务”和“基础设施”解耦,将一个微服务进程一分为二:
image.png

一个进程实现业务逻辑,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?
image.png

看了上图就容易懂了,biz和proxy相生相伴,就像摩托车(motor)与旁边的车厢(sidecar)。未来,sidecar和proxy就指微服务进程解耦成两个进程之后,提供基础能力的那个代理进程。

 

Istio这么牛逼,它的核心架构如何呢?

且听下回分解。

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

目录
相关文章
|
10月前
|
机器学习/深度学习 人工智能 算法
【AI系统】AI系统架构的组成
本文概述了AI系统的组成,从AI训练与推理框架、AI编译与计算架构到AI硬件与体系结构,详细介绍了各层的功能与技术细节。同时,探讨了AI系统生态的广泛领域,包括核心系统软硬件、AI算法和框架以及更广泛的生态组成部分,强调了在模型训练、推理、安全与隐私等方面的技术挑战与解决方案。
1980 2
|
前端开发 计算机视觉
InstantStyle,无需训练,风格保留文生图
InstantStyle 是一个通用框架,它采用两种简单但有效的技术来实现风格和内容与参考图像的有效分离。
|
运维 监控 Cloud Native
云原生时代的运维策略:从反应式到自动化
在云计算的浪潮下,运维领域经历了翻天覆地的变化。本文将带你领略云原生时代下的运维新风貌,探索如何通过自动化和智能化手段,实现从传统的反应式运维向主动、智能的运维模式转变。我们将一起见证,这一变革如何助力企业提升效率,保障服务的连续性与安全性,以及运维人员如何适应这一角色的转变,成为云原生时代的引领者。
216 9
|
11月前
|
运维 Linux
Linux查找占用的端口,并杀死进程的简单方法
通过上述步骤和命令,您能够迅速识别并根据实际情况管理Linux系统中占用特定端口的进程。为了获得更全面的服务器管理技巧和解决方案,提供了丰富的资源和专业服务,是您提升运维技能的理想选择。
654 1
|
网络协议
LabVIEW中如何在网络上使用远程VI服务器
LabVIEW中如何在网络上使用远程VI服务器
197 2
|
设计模式 缓存 Devops
微服务架构最强讲解,那叫一个通俗易懂!
微服务架构(Microservice Architecture)是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的
29672 2
微服务架构最强讲解,那叫一个通俗易懂!
|
Ubuntu Linux Windows
串口模拟工具实现测试
串口模拟工具实现测试
357 0
|
存储 数据采集 Prometheus
基于 OPLG 从 0 到 1 构建统一可观测平台实践
随着软件复杂度的不断提升,单体应用架构逐步向分布式和微服务的架构演进,整体的调用环境也越来越复杂,仅靠日志和指标渐渐难以快速定位复杂环境下的问题。对于全栈可观测的诉求也变得愈加强烈,Traces、Metrics 和 Logs 的连接也愈发紧密。
基于 OPLG 从 0 到 1 构建统一可观测平台实践
|
机器学习/深度学习 运维 自然语言处理
从 “香农熵” 到 “告警降噪” ,如何提升告警精度?
ARMS 智能降噪功能依托于 NLP 算法和信息熵理论建立模型,从大量历史告警事件中去挖掘这些事件的模式规律。当实时事件触发后,实时为每一条事件打上信息熵值与噪音识别的标签,帮助用户快速识别事件重要性。
从 “香农熵” 到 “告警降噪” ,如何提升告警精度?

热门文章

最新文章