1. 概述

1.1 服务网格（Service Mesh）简介

Service Mesh 是一个专注于处理服务间通信的基础设施层。

云原生应用有着复杂的服务拓扑，而 Service Mesh 保证请求可以在这些拓扑中可靠地穿梭。在实际应用当中，Service Mesh 通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但应用程序不需要知道它们的存在。

在某些方面，服务网格类似于TCP/IP。正如TCP协议栈抽象了在网络端点之间可靠地传递字节的机制一样，服务网格抽象了在服务之间可靠地传递请求的机制。与TCP一样，服务网格不关心实际有效负载或其编码方式，只负责完成从服务A发送到服务B，并且在处理任何故障的同时实现这一目标。

与TCP不同的是，Service Mesh有着更高的目标：为应用运行时提供统一的、应用层面的可见性和可控性。通过每个微服务中的 Sidecar ，Service Mesh 得以将服务间通信从底层的基础设施中分离出来，让它成为整个生态系统的一等公民——它不再是单纯的基础设施，更可以被监控、托管和控制。

1.2 代理(sidecar)–业务和通信分离

在微服务初期( 2015年前 )开发微服务应用的过程中，我们需要重复性地处理一系列基础工作，比如：服务注册、服务发现、得到服务实例后的负载均衡、熔断机制等。

仔细分析上述一系列的重复性工作，我们可以发现，这些工作几乎全部集中在处理各个服务间的通信问题。那么，为何我们不把这些工作从业务逻辑中抽离出来，使其专注于服务间通信，并形成单独的组件呢？

Sidecar 模式，即在微服务中将关于服务通讯的功能抽离出来，并作为一个单独的组件运行在微服务中。这种在微服务中独立负责端对端通信的组件，我们称之为 Sidecar 。这种在微服务中将业务逻辑与服务通信解藕，并分离为两个独立运行组件的做法，正是 Service Mesh 概念的雏形。

Service Mesh 在 Sidecar 模式的基础上更进一步。Service Mesh 的定义——一个专注于处理服务间通信的基础设施层——站在开发者的角度来讲，就是在每一个微服务中将用于通信的部分从业务中彻底解藕，应用程序甚至不需要知道它们的存在。

在 Service Mesh 中，每个微服务至少含有两个组件：一个用于处理业务功能的“应用程序”和一个专职处理服务间通信的“ Sidecar ”( 类似代理 )。

Service Mesh 的愿景是希望开发者再也不需要将精力花费在服务通信上。服务通信由每个微服务的 Sidecar 负责，而 Sidecar 由专门的项目来接管。目前，许多被熟知的项目都可以被我们当作 Sidecar 来运用，比如 Envoy 、 HAProxy 和 Nginx 。

使用了 Service Mesh 之后，开发团队和运维团队就可以更加明确的划清自己的职责范围——开发团队专注于业务的开发，而运维团队只需关注微服务中的 Sidecar 就可以明确地了解到每个微服务的健康情况和各种指标。

2. lstio

目前，由 Google , IBM 和 Lyft 公司共同研发的 Istio 非常火爆。Istio 是 Service Mesh 的一个实现，可以看作是一个“微服务管理框架”，一般配合 Kubernetes 使用。Istio 使用 Envoy 作为 Sidecar，并精细地实现了 Service Mesh 对于上述微服务之间传输的诸多设想，并且添加了许多很棒的额外功能。

2.1 Istio 的设计目标

作为一款 Service Mesh 模式的实现，Istio 最根本的设计目标就是实现 Service Mesh 的设计构想：

将“应用程序”与“网络”解藕
将服务之间、服务与集群外部的网络通讯和安全机制从微服务的业务逻辑中解藕，并作为一个与平台无关的、独立运行的程序，以减少开发和运维人员的工作量。
保障网络环节
应用程序的目标是“将某些东西从A传送到B”，而 Service Mesh 所要做的就是实现这个目标，并处理传送过程中可能出现的任何故障。
提供应用层面的可见性和可控性
通过每个微服务中的 Sidecar ，Service Mesh 得以将服务间通信从底层的基础设施中分离出来，让它成为整个生态系统的一个独立部分——它不再是单纯的基础设施，更可以被监控、托管和控制。

2.2 Istio 的核心功能

Istio 的核心功能有以下五点：

流量管理
Istio 通过 Pilot 所提供的 API 动态地配置所有 Pod 中 Sidecar 的路由规则，进而控制服务间的流量和 API 调用。Istio 简化了断路器、超时和重试等服务级别属性的配置，并且可以轻松设置 A/B 测试、金丝雀部署和基于百分比的流量分割的分阶段部署等重要任务。
安全
Istio 提供给开发人员应用程序级别的安全性。Istio 提供底层安全通信信道，并大规模管理服务通信的认证、授权和加密。使用 Istio ，服务通信在默认情况下是安全的，它允许跨多种协议和运行时一致地实施策略——所有这些都很少或根本不需要应用程序更改。将 Istio 与 Kubernetes 的网络策略结合使用，其优势会更大，包括在网络和应用层保护 Pod 间或服务间通信的能力。
可观察性
Istio 的 Mixer 组件负责策略控制和遥测收集。通过 Istio 的监控功能，可以了解服务性能如何影响上游和下游的功能；其自定义仪表板可以提供对所有服务性能的可视化，从而了解性能如何影响其他进程。
平台独立
Istio 是独立于平台的，旨在运行在各种环境中，包括跨云、内部部署、Kubernetes、Mesos 等。您可以在 Kubernetes 上部署 Istio 或具有 Consul 的 Nomad 上部署。
集成和定制
策略执行组件可以扩展和定制，以便与现有的 ACL、日志、监控、配额、审计等方案集成。

2.2 lstio的整体架构

Istio是一个管控/数据平面分离的完整Service Mesh套件。

数据平面，作为网络代理，主要解决在服务之间可靠地传递请求的问题。
控制平面，主要解决流量管理、安全、可观测性三个方面的问题

Envoy：构成数据平面（其他组件共同构成控制平面）；可被替换为其他代理（e.g. Linkerd, nginMesh）。
Pilot：负责流量管理（Traffic Management），提供平台独立的服务模型定义、API以及实现。
Mixer：负责策略与控制（Policies & Controls），核心功能包括：前置检查、配额管理、遥测报告。
Istio-Auth：支持多种粒度的RBAC权限控制；支持双向SSL认证，包括身份识别、通讯安全、秘钥管理。

3. envoy

对应用程序而言，网络应该是透明的。当网络和应用程序出现故障时，应该能够很容易确定问题的根源。

Envoy 是一款由 Lyft 开源的，使用 C++ 编写的 L7 代理和通信总线。Envoy 本身可以做反向代理和负载均衡，它也是 Istio 数据平面中默认使用的 sidecar。

Envoy 作为一个反向代理，类似于 Nginx，但与 Nginx 不同的是它还会作为一个进程，伴随每个服务一起运行在同一个容器中（在 Kubernetes 中可以作为 Sidecar 与应用容器一起运行在同一个 Pod 中）。

Envoy 包括如下特性：

进程外架构，不侵入应用进程
使用现代版 C++11 代码
L3/L4 filter 架构
HTTP L7 filter 架构
支持 HTTP/2
HTTP L7 routing
支持 gRPC
支持 MongoDB L7
动态配置
最佳可观测性
支持 front/edge proxy
高级负载均衡
健康检查
服务发现
支持 DynamoDB L7

3.1 独立于进程的架构

Envoy 是一个独立进程，设计为伴随每个应用程序服务运行。所有的 Envoy 形成一个透明的通信网格，每个应用程序发送消息到本地主机或从本地主机接收消息，不需要知道网络拓扑，对服务的实现语言也完全无感知，这种模式也被称为 Sidecar。

3.2 L3/L4/L7 架构

传统的网络代理，要么在 HTTP 层工作，要么在 TCP 层工作。在 HTTP 层的话，你将会从传输线路上读取整个 HTTP 请求的数据，对它做解析，查看 HTTP 头部和 URL，并决定接下来要做什么。随后，你将从后端读取整个响应的数据，并将其发送给客户端。但这种做法的缺点就是非常复杂和缓慢，更好的选择是下沉到 TCP 层操作：只读取和写入字节，并使用 IP 地址，TCP 端口号等来决定如何处理事务，但无法根据不同的 URL 代理到不同的后端。Envoy 支持同时在 3/4 层和 7 层操作，以此应对这两种方法各自都有其实际限制的现实。

3.3 gRPC 支持

gRPC[1] 是一个来自 Google 的 RPC 框架，它使用 HTTP/2 作为底层多路复用传输协议。Envoy 完美支持 HTTP/2，也可以很方便地支持 gRPC。

3.4 特殊协议支持

Envoy 支持对特殊协议在 L7 进行嗅探和统计，包括：MongoDB[2]、DynamoDB[3] 等。

4. 参考

浅谈 Service Mesh: 其定义、起源、出现背景和设计理念及作用
K8s为何需要Istio？较为深入地讨论 Istio——其历史发展、设计理念、核心功能原理及运行流程
正确入门Service Mesh：起源、发展和现状
envoy 中文参考文档

ServiceMash服务网格--理解lstio/envoy相关推荐

【服务网格架构】Envoy 部署类型
Envoy可用于各种不同的场景,但是在跨基础架构中的所有主机进行网格部署时,它是最有用的.本节介绍三种推荐的部署类型,其复杂程度越来越高. 服务到服务服务到出口监听器服务到服务入口监听器可选的外 ...
Beyond Istio OSS——Istio服务网格的现状与未来
作者:宋净超(Jimmy Song),原文地址:https://jimmysong.io/blog/beyond-istio-oss/ 本文根据笔者在 GIAC 深圳 2022 年大会上的的演讲< ...
服务网格 ASM 年终总结：最终用户如何使用服务网格？
01 背景 Aliware 阿里云服务网格 ASM 于 2020 年 2 月公测,近 2 年的时间,已有大量用户采用其作为生产应用的服务治理平台.阿里云服务网格 ASM 基于开源 Istio 构建.同 ...
基于Istio的高级流量管理一（为什么需要服务网格？深入理解Envoy）
文章目录一.微服务架构的演变二.Istio服务网格简介 1.服务网格架构 1.ServiceMesh提供哪些能力? 2.Istio服务网格 3.Istio架构演进三.深入理解数据平面Envoy ...
关于lstio服务网格介绍
以下图片为演变过程个人理解的服务网格一句话代理,业务逻辑和网络功能拆分服务网格的功能 1.负载均衡 2.服务发现 3.熔断降级 4.动态路由 5.故障注入 6.错误重试 7.安全通信 8.和语言 ...
Envoy Proxy的多面性：边缘网关、服务网格和混合网桥
在美国西雅图召开的首届EnvoyCon大会上,来自Pinterest.Yelp和Groupon的工程师们展示了他们目前的Envoy Proxy用例.最重要的信息是,Envoy Proxy似乎离实现他们 ...
微软开源基于 Envoy 的服务网格 Open Service Mesh
原文地址:https://techcrunch.com/2020/08/05/microsoft-launches-open-service-mesh/ Open Service Mesh(OSM)是 ...
apache kafka_使用Apache Kafka，Kubernetes和Envoy，Istio，Linkerd的服务网格和云原生微服务...
apache kafka 微服务架构不是免费的午餐 ! 微服务需要解耦,灵活,操作透明,数据感知和弹性. 过去几年的大多数材料仅讨论具有紧密耦合且不可扩展的技术(如REST / HTTP)的点对点体系 ...
使用Apache Kafka，Kubernetes和Envoy，Istio，Linkerd的服务网格和云原生微服务
微服务架构不是免费的午餐 ! 微服务需要解耦,灵活,操作透明,数据感知和弹性. 过去几年的大多数材料仅讨论具有紧密耦合且不可扩展的技术(如REST / HTTP)的点对点体系结构. 这篇博客文章介绍了 ...

ServiceMash服务网格--理解lstio/envoy