微服务和服务网格有什么区别，Istio告诉你

系统管理员 2023-03-03 13:25 39阅读 0赞

> **原文发表于[kubernetes中文社区][kubernetes]，为作者原创翻译 ，原文地址**
> 
> **更多kubernetes文章，请多关注[kubernetes中文社区][kubernetes]**

**目录**

微服务架构的好处

微服务架构的组件

微服务架构的复杂性

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

服务网格架构的组件

微服务的业务逻辑

基本网络功能

应用网络功能

服务网格控制平面

使用Istio实施服务网格

Istio的核心能力

核心Istio组件

--------------------

当组织将应用程序分解为多个较小的服务组件时，即称为**微服务**。与传统的单体应用方式相比，微服务架构将每个微服务视为独立的实体/模块，从根本上有助于简化其代码和相关基础架构的维护。应用程序的每个微服务还可以使用不同的技术编写，还可以独立地部署，优化和管理。

尽管从理论上讲，微服务架构特别有利于复杂的大型应用程序的构建，但是，它也被广泛用于小型应用程序的构建（例如，简单的购物车），还能够满足进一步扩展的需求。

## 微服务架构的好处 ##

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

## 微服务架构的组件 ##

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

*  **容器化**（类似**Docker**的平台）-通过将服务分成多个进程来进行有效的管理和部署。
 *  **编排**（类似**Kubernetes**之类的平台）-用于配置，分配和管理服务的可用系统资源。
 *  **服务网格**（类似**Istio**的平台）-通过服务代理网格进行服务间通信，以连接，管理和保护微服务。

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

## 微服务架构的复杂性 ##

大型应用程序分解为多个微服务时，每个微服务可能使用不同的技术栈（开发语言，数据库等），需要把这些环境来形成一个复杂的体系结构进行管理。尽管Docker容器化通过将每个微服务划分为在单独的容器中运行，来帮助管理和部署单个**微服务**，但是**由于必须处理整体系统运行状况，容错和多个故障点，因此服务间通信仍然非常复杂。**

> 让我们通过购物车如何在微服务架构上工作来了解这一点。这里的微服务有库存服务，支付网关服务，基于客户访问历史的产品建议算法服务等。尽管所有这些服务在理论上都保持为独立的微型模块，但它们确实需要彼此交互。
> 
> 所以， **服务到服务的通信才使微服务成为可能**。

## 为什么我们需要服务网格？ ##

既然你知道了微服务体系结构中服务到服务通信的重要性，那么很明显，通信通道需要保持无故障，安全，高可用性和健壮性。而这恰恰是**服务网格作为基础结构组件出现的地方，它通过实现多个服务代理来确保受控的服务到服务通信**。服务网格负责不同服务之间的通信，而不是添加新功能。

在服务网格中，与单个服务一起部署的代理可以实现服务之间的通信，这被广泛称为**Sidecar模式**。Sidecar（代理）被设计为处理服务间通信的任何功能，例如负载均衡，断路器，服务发现等。

通过服务网格，你可以：

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

## 服务网格架构的组件 ##

### **微服务的业务逻辑** ###

业务逻辑包含微服务的核心应用程序逻辑和基础代码，以及服务到服务的集成逻辑。由于微服务架构的优势，因此可以在任何平台上编写业务逻辑，并且业务逻辑完全独立于其他服务。

### **基本网络功能** ###

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

### **应用网络功能** ###

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

### **服务网格控制平面** ###

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

## 使用Istio实施服务网格 ##

尽管有其他几种服务网格，但最受欢迎的是Istio。我们将使用Istio探索云原生应用程序的Service Mesh架构。

如以上各节所述，在微服务体系结构中， **Istio通过形成基础结构层来实现此目的，以连接，保护和控制分布式服务之间的通信。**Istio 在每个服务旁边部署一个 **Istio代理（称为Istio sidecar）**，而该服务本身的代码更改几乎很少或没有。所有服务间流量都定向到Istio代理，该代理使用策略控制服务间通信，同时实施部署，故障注入和断路器的基本策略。

## Istio的核心能力 ##

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

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

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

## 核心Istio组件 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70][]

Istio服务网格由**数据平面**和**控制平面组成**。

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

控制平面主要是对数据平面组件的管理和维护，因此形成了Istio Service Mesh最重要的层。

--------------------

在本文中，我们了解了服务网格对于微服务体系结构至关重要，以及Istio如何解决服务间的通信。

译文链接： [https://dzone.com/articles/explaining-microservices-and-service-mesh-with-ist][https_dzone.com_articles_explaining-microservices-and-service-mesh-with-ist]

[kubernetes]: https://www.kubernetes.org.cn/
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70]: /images/20230208/6f7e77ec744e4643a7fa0b11dd6f0325.png
[https_dzone.com_articles_explaining-microservices-and-service-mesh-with-ist]: https://dzone.com/articles/explaining-microservices-and-service-mesh-with-ist