用 Istio 解释微服务和服务网格

作者:Sudip Sengupta

翻译:Bach(才云)

校对:bot(才云)、星空下的文仔(才云)

微服务会将应用程序分解为多个较小的服务组件。与传统的一体化(Monolithic)架构相比,微服务架构将每个微服务视为独立的实体与模块,从根本上有助于简化代码和相关基础架构的维护。应用程序的每个微服务都可以编写在不同的技术堆栈中,并且可以进一步独立地部署、优化和管理。

从理论上讲,微服务体系结构特别有利于复杂的大型应用程序的构建,但实际上,它也被广泛用于小型应用程序的构建。

微服务架构的好处

  • 可以通过不同的技术堆栈开发和部署应用程序中的各个微服务。
  • 每个微服务都可以独立优化、部署或扩展。
  • 更好的故障处理和错误检测。

K8sMeetup

微服务架构的组件

在微服务架构上运行的现代云原生应用程序依赖于以下关键组件:

  • 容器化(通过类似 Docker 的平台):通过将服务分为多个进程进行管理和部署。
  • 编排(通过类似 Kubernetes 的平台):配置、分配、管理服务的系统资源。
  • 服务网格(通过类似 Istio 的平台):通过服务代理网格进行服务间通信,以连接、管理、保护微服务。

以上三个是微服务架构中最重要的组件,这些组件允许云原生堆栈中的应用程序在负载下扩展,甚至在云环境部分故障期间也能执行。

K8sMeetup

微服务架构的复杂性

大型应用程序被分解为多个微服务时,每个微服务都使用不同的技术堆栈(开发语言、数据库等),因此我们需要把这些环境组成一个复杂的体系结构进行管理。尽管已经将每个微服务划分为单独 Docker 容器中运行的多个进程,以此来帮助管理和部署单个微服务,但由于我们必须处理整体系统运行状况、容错和故障点,服务间通信仍然非常复杂。

我们可以通过购物车在微服务架构上工作的例子来进一步了解。这里微服务将与库存数据库、支付网关服务、基于客户访问历史的产品建议算法等有关。尽管从理论上讲,这些服务仍然是独立的微型模块,但它们确实需要彼此交互。

K8sMeetup

为什么我们需要服务网格?

微服务体系结构中服务到服务通信非常重要,那么很明显,通信通道需要确保无故障、安全、高可用性和健壮性。这些是服务网格作为基础结构组件出现的地方,它通过实现多个服务代理来确保服务到服务的通信。服务网格不负责添加新功能,但可以微调不同服务之间的通信。

在服务网格中,与单个服务一起部署的代理可以实现服务之间的通信,这被广泛称为边车(Sidecar)模式。边车模式有着处理服务间通信的重要功能,例如负载均衡、断路、服务发现等。

通过服务网格,我们可以:

  • 维护、配置、保护应用程序中所有或选定微服务之间的通信。
  • 在微服务中配置和执行网络功能,例如网络弹性、负载均衡、网络中断、服务发现等。
  • 网络功能与业务逻辑分离,为单独实体,因此开发人员可以专注于应用程序的业务逻辑,而与网络通信相关的大部分工作都由服务网格来处理。
  • 由于微服务到服务的代理通信始终使用诸如 HTTP1.x/2.x、gRPC 等标准协议,因此开发人员可以使用任何技术来开发单个服务。

K8sMeetup

服务网格架构的组件

业务逻辑

业务逻辑包含了微服务的核心应用程序逻辑、基础代码、应用程序的计算以及服务到服务的集成逻辑。微服务架构的优势就是可以在任何平台上编写业务逻辑,并且业务逻辑完全独立于其他服务。

基本网络功能

基本网络功能包括发起网络请求和连接服务网格代理。尽管微服务中的主要网络功能是通过服务网格来处理的,但是给定的服务必须包含基本网络功能才能与 Sidecar 代理连接。

应用网络功能

与基本网络功能不同,该组件通过服务代理维护和管理关键的网络功能,包括网络中断、负载均衡、服务发现等。

服务网格控制平面

所有服务网格代理都由控制平面集中管理和控制。通过控制平面,我们可以指定身份验证策略、度量标准生成,并在整个网格中配置服务代理。

K8sMeetup

使用 Istio 实施服务网格

尽管有其他服务网格,但 Istio 是最受欢迎的,下面我们看看如何将 Istio 用于云原生应用程序的服务网格架构。

如上文所述,在微服务体系结构中,Istio 会通过形成基础结构层以连接、保护和控制分布式服务之间的通信。Istio 会在每个服务旁边部署一个 Istio 代理(称为 Istio sidecar),但该服务本身的代码很少有更改。所有服务间的流量都定向到 Istio 代理,该代理使用策略控制服务间通信,同时实施部署、故障注入和断路器的基本策略。

Istio 的核心能力

  • 通过身份验证和授权来保护服务间通信。
  • 支持访问控制、配额和资源分配的策略层。
  • 支持 HTTP、gRPC、WebSocket 和 TCP 通信的自动负载均衡。
  • 集群内所有流量的自动指标、日志和跟踪,包括集群的入口和出口。
  • 通过故障转移、故障注入和路由规则配置和控制服务间通信。

Istio 不依赖任何平台,这意味着它可以在多种环境中运行,包括云、本地、Kubernetes 等。Istio 当前支持:

  • Kubernetes 上的服务部署
  • 在 Consul 注册的服务
  • 在单个虚拟机上运行的服务

核心 Istio 组件

用 Istio 解释微服务和服务网格_第1张图片

图像源:istio.io

Istio 服务网格由数据平面(data plane)控制平面(control plane)组成。

  • 数据平面由多个服务代理(通过 Envoy)组成,而微服务之间 Sidecar 通信是通过策略和遥测收集(通过 Mixer)实现。
  • 控制平面通过 Pilot、Citadel 和 Galley 管理和配置 Sidecar 代理之间的通信。Citadel 用于密钥和证书管理。Pilot 将授权策略和安全命名信息分发给代理,主要用于服务发现和服务配置(服务访问规则维护),Pilot 中的 adapter 机制可以适配各种服务发现组件(Eureka、Consul、Kubenetes),最好的是 Kubernetes。Galley 验证规则(Pilot、Mixer、Citadel配置的规则)。

控制平面对数据平面组件进行管理和维护,这形成了 Istio Service Mesh 最重要的层。

原文地址:https://mp.weixin.qq.com/s/xPyXBvp_-e-1ODAapDgWHw

你可能感兴趣的:(用 Istio 解释微服务和服务网格)