服务网格Service Mesh和Istio

文章目录

服务网格(Service Mesh)

服务网格是一种用于处理微服务架构中服务间通信的网络基础架构。它通过在应用程序的每个服务之间插入代理(通常称为Sidecar代理),来实现服务间通信的控制和管理。这种方式将通信逻辑从应用程序代码中解耦出来,使得开发人员可以专注于业务逻辑而无需担心网络通信的复杂性。

在服务网格中,代理负责管理流量、执行负载均衡、实现故障处理和实现安全策略。这些代理形成了一个网格,因此被称为"服务网格"。

服务网格技术的优势在于它提供了诸如请求重试、超时处理、流量控制、A/B测试等功能,这些功能在大规模微服务架构中尤为重要。此外,服务网格还提供了可观测性和监控的能力,使得开发团队可以更好地理解和调试整个应用程序的运行状况。

Service Mesh主要解决的问题就希望开发人员对于业务的聚焦,对于开发人员透明,可以更加专注业务逻辑的实现而不必关注非业务功能。

市场上三种服务网格解决方案

目前,Linkerd、Istio和Envoy是市场上三种受欢迎的服务网格解决方案。

轻量级易上手 功能丰富 部署难度 高性能
Linkerd 轻量 功能相对较少 容易 一般
Istio 学习成本高 功能丰富、基于Envoy可扩展
Envoy 学习成本高 功能丰富、可扩展

在功能、性能、部署难度和社区支持等方面,Istio、Linkerd和Envoy各有优势和局限性。对于大规模和复杂的应用场景,Istio可能是一个更好的选择,因为它提供了丰富的功能和强大的扩展性。Istio的功能涵盖了流量管理、策略制定、故障注入等方面,适用于复杂的微服务架构。并且,Istio有着庞大的社区支持,可以获取到大量的文档、教程和问题解答,有利于开发人员学习和使用。

对于小规模的应用或资源受限的环境,Linkerd可能更合适,因为它轻量且易于部署。Linkerd作为一款轻量级的服务网格解决方案,以其简单的部署和对边车模式的支持而备受欢迎。虽然其功能相对较少,但在边车模式下可以无侵入地集成到现有的应用程序中。

对于性能要求较高的场景,Envoy可能是更好的选择。Envoy作为一款高性能的代理和通信中间件,被广泛用于服务网格架构。它具备出色的性能和可扩展性,适用于对性能要求较高的场景。

在选择合适的服务网格解决方案时,开发团队应该综合考虑应用的规模、复杂性、性能需求和团队的技术水平,并根据实际情况做出明智的选择。没有一种解决方案适用于所有场景,因此需要根据具体需求来进行权衡和取舍。

原文链接:https://blog.csdn.net/qq_44866828/article/details/131928692

服务网格的特征

现在,让我们了解服务网格可以为我们提供的一些功能。请注意,实际功能列表取决于服务网格的实现。但是,总的来说,我们应该在所有实现中都期望其中大多数功能。

我们可以将这些功能大致分为三类:流量管理,安全性和可观察性。

流量管理

服务网格的基本特征之一是流量管理。这包括动态服务发现和路由。尤其影子流量和流量拆分功能,这些对于实现金丝雀发布和A/B测试非常有用。

由于所有服务之间的通信都是由服务网格处理的,因此它还启用了一些可靠性功能。例如,服务网格可以提供重试,超时,速率限制和断路器。这些现成的故障恢复功能使通信更加可靠。

安全性

服务网格通常还处理服务到服务通信的安全性方面。这包括通过双向TLS(mTLS)强制进行流量加密,通过证书验证提供身份验证以及通过访问策略确保授权。

服务网格中还可能存在一些有趣的安全用例。例如,我们可以实现网络分段,从而允许某些服务进行通信而禁止其他服务。而且,服务网格可以为审核需求提供精确的历史信息。

可观察性

强大的可观察性是处理分布式系统复杂性的基本要求。由于服务网格可以处理所有通信,因此正确放置了它可以提供可观察性的功能。例如,它可以提供有关分布式追踪的信息。

服务网格可以生成许多指标,例如延迟,流量,错误和饱和度。此外,服务网格还可以生成访问日志,为每个请求提供完整记录。这些对于理解单个服务以及整个系统的行为非常有用。

Istio简介

Istio是最初由IBM,Google和Lyft开发的服务网格的开源实现。它可以透明地分层到分布式应用程序上,并提供服务网格的所有优点,例如流量管理,安全性和可观察性。

它旨在与各种部署配合使用,例如本地部署,云托管,Kubernetes容器以及虚拟机上运行的服务程序。尽管Istio与平台无关,但它经常与Kubernetes平台上部署的微服务一起使用。

从根本上讲,Istio的工作原理是以Sidcar的形式将Envoy的扩展版本作为代理布署到每个微服务中:

实际上Istio 就是 Service Mesh 架构的一种实现,服务之间的通信(比如这里的 Service A 访问 Service B)会通过代理(默认是 Envoy)来进行。

而且中间的网络协议支持 HTTP/1.1,HTTP/2,gRPC 或者 TCP,可以说覆盖了主流的通信协议。代理这一层,称之为数据平面。

控制平面做了进一步的细分,分成了 Pilot、Citadel 和 Galley,它们的各自功能如下:

  • Pilot:为 Envoy 提供了服务发现,流量管理和智能路由(AB 测试、金丝雀发布等),以及错误处理(超时、重试、熔断)功能。
  • Citadel:为服务之间提供认证和证书管理,可以让服务自动升级成 TLS 协议。
  • Galley:Galley 是 Istio 的配置验证、提取、处理和分发组件。它负责将其余的 Istio 组件与从底层平台(例如 Kubernetes)获取用户配置的细节隔离开来。

数据平面会和控制平面通信,一方面可以获取需要的服务之间的信息,另一方面也可以汇报服务调用的 Metrics 数据。

Istio提供了什么功能服务 ?

通过负载均衡、服务间的身份验证、监控等方法,Istio 可以轻松地创建一个已经部署了服务的网络,而服务的代码只需很少更改甚至无需更改。通过在整个环境中部署一个特殊的 sidecar 代理为服务添加 Istio 的支持,而代理会拦截微服务之间的所有网络通信,然后使用其控制平面的功能来配置和管理 Istio,这包括:

  • 为 HTTP、gRPC、WebSocket 和 TCP 流量自动负载均衡。

  • 通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制。

  • 可插拔的策略层和配置 API,支持访问控制、速率限制和配额。

  • 集群内(包括集群的入口和出口)所有流量的自动化度量、日志记录和追踪。

  • 在具有强大的基于身份验证和授权的集群中实现安全的服务间通信。

Istio 为可扩展性而设计,可以满足不同的部署需求。

原文链接:https://blog.csdn.net/bxg_kyjgs/article/details/125599452

Istio体系结构由数据平面和控制平面组成。此外,还有几个使Istio起作用的核心组件。

Istio 核心特性

Istio 以统一的方式提供了许多跨服务网络的关键功能。

流量管理

Istio 简单的规则配置和流量路由允许您控制服务之间的流量和 API 调用过程。

Istio 简化了服务级属性(如熔断器、超时和重试)的配置,并且让它轻而易举的执行重要的任务(如 A/B 测试、金丝雀发布和按流量百分比划分的分阶段发布)。

有了更好的对流量的可视性和开箱即用的故障恢复特性,就可以在问题产生之前捕获它们,无论面对什么情况都可以使调用更可靠,网络更健壮。

安全

Istio 的安全特性解放了开发人员,使其只需要专注于应用程序级别的安全。

Istio 提供了底层的安全通信通道,并为大规模的服务通信管理认证、授权和加密。有了 Istio,服务通信在默认情况下就是受保护的,可以让您在跨不同协议和运行时的情况下实施一致的策略------而所有这些都只需要很少甚至不需要修改应用程序。

Istio 是独立于平台的,可以与 Kubernetes(或基础设施)的网络策略一起使用。但它更强大,能够在网络和应用层面保护pod到 pod 或者服务到服务之间的通信。

可观察性

Istio 健壮的追踪、监控和日志特性让您能够深入的了解服务网格部署。

通过 Istio 的监控能力,可以真正的了解到服务的性能是如何影响上游和下游的;而它的定制 Dashboard 提供了对所有服务性能的可视化能力,并让您看到它如何影响其他进程。

Istio 的 Mixer 组件负责策略控制和遥测数据收集。它提供了后端抽象和中介,将一部分 Istio 与后端的基础设施实现细节隔离开来,并为运维人员提供了对网格与后端基础实施之间交互的细粒度控制。

所有这些特性都使您能够更有效地设置、监控和加强服务的 SLO。当然,底线是您可以快速有效地检测到并修复出现的问题。

平台支持

Istio 独立于平台,被设计为可以在各种环境中运行,包括跨云、内部环境、Kubernetes、Mesos 等等。您可以在 Kubernetes 或是装有 Consul 的 Nomad 环境上部署 Istio。Istio 目前支持:

  • Kubernetes 上的服务部署

  • 基于 Consul 的服务注册

  • 服务运行在独立的虚拟机上

Istio运行在kubernetes平台是最佳的选择,所以我们先搭建kubernetes环境。

相关推荐
梅见十柒1 小时前
wsl2中kali linux下的docker使用教程(教程总结)
linux·经验分享·docker·云原生
运维&陈同学3 小时前
【zookeeper01】消息队列与微服务之zookeeper工作原理
运维·分布式·微服务·zookeeper·云原生·架构·消息队列
O&REO3 小时前
单机部署kubernetes环境下Overleaf-基于MicroK8s的Overleaf应用部署指南
云原生·容器·kubernetes
运维小文4 小时前
K8S资源限制之LimitRange
云原生·容器·kubernetes·k8s资源限制
wuxingge13 小时前
k8s1.30.0高可用集群部署
云原生·容器·kubernetes
志凌海纳SmartX14 小时前
趋势洞察|AI 能否带动裸金属 K8s 强势崛起?
云原生·容器·kubernetes
锅总14 小时前
nacos与k8s service健康检查详解
云原生·容器·kubernetes
BUG弄潮儿15 小时前
k8s 集群安装
云原生·容器·kubernetes
Code_Artist15 小时前
Docker镜像加速解决方案:配置HTTP代理,让Docker学会科学上网!
docker·云原生·容器
何遇mirror15 小时前
云原生基础-云计算概览
后端·云原生·云计算