什么是服务网格
服务网格近年来有很高的话题度，背后的原因是什么？
2017年底，非侵入式的 Service Mesh 技术从萌芽到走向了成熟。
Service Mesh 又译作“服务网格”，作为服务间通信的基础设施层。
如果用一句话来解释什么是 Service Mesh，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。
微服务已经成为一种灵活快速的开发方式。然而，随着微服务数量成倍数地增长，开发团队开始遇到了部署和扩展性上的问题。
容器和 Kubernetes 这样的容器编排系统 ，将运行时和服务一起打包进镜像，调度容器到合适的节点，运行容器。这个方案可以解决开发团队遇到的不少问题。然而，在这个操作流程中仍存在短板：如何管理服务间的通信。
在采用服务网格的场景下，以一种和应用代码解耦的方式，增强了应用间统一的网络通信能力。服务网格扩展了集群的管理能力，增强可观测性、服务发现、负载均衡、IT 运维监控及应用故障恢复等功能。
服务网格概览
服务网格一直有很高的热度。正如 Linkerd 的作者 William Morgan 所提到的：“服务网格本质上无非就是和应用捆绑在一起的用户空间代理。” 此说法相当简洁，他还补充道，“如果你能透过噪音看清本质，服务网格能给你带来实实在在的重要价值。”
Envoy 是许多服务网格框架的核心组件，是一个通用的开源代理，常被用于 Pod 内的 sidecar 以拦截流量。也有服务网格使用另外的代理方案。
若论具体服务网格方案的普及程度，Istio 和 Linkerd 获得了更多的认可。也有其它可选项，包括 Consul Connect，Kuma，AWS App Mesh和OpenShift。下文会阐述9种服务网格提供的关键特性。
Service Mesh 的来龙去脉：
从最原始的主机之间直接使用网线相连
网络层的出现
集成到应用程序内部的控制流
分解到应用程序外部的控制流
应用程序的中集成服务发现和断路器
出现了专门用于服务发现和断路器的软件包/库，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，这时候还是集成在应用程序内部
出现了专门用于服务发现和断路器的开源软件，如 Netflix OSS、Airbnb 的 synapse 和 nerve
最后作为微服务的中间层 Service Mesh 出现
Service Mesh 有如下几个特点：
应用程序间通讯的中间层
轻量级网络代理
应用程序无感知
解耦应用程序的重试/超时、监控、追踪和服务发现
1、Istio
Istio 是基于 Envoy 构建的一个可扩展的开源服务网格。开发团队可以通过它连接、加密、管控和观察应用服务。Istio 于 2017 年开源，目前 IBM、Google、Lyft 仍在对其进行持续维护升级。Lyft 在 2017 年把 Envoy 捐赠给了 CNCF。
Istio 花了不少时间去完善增强它的功能特性。Istio 的关键特性包括负载均衡、流量路由、策略创建、可度量性及服务间认证。
Istio 有两个部分组成：数据平面和控制平面。数据平面负责处理流量管理，通过 Envoy 的 sidecar 代理来实现流量路由和服务间调用。控制平面是主要由开发者用来配置路由规则和观测指标。
Istio 观测指标是细粒度的属性，其中包含和服务行为相关的特定数据值。下面是个样例：
request.path: xyz/abc request.size: 234 request.time: 12:34:56.789 04/17/2017 source.ip: [192 168 0 1] destination.service.name: example
与其他服务网格相比，Istio 胜在其平台成熟度以及通过其 Dashbaord
着重突出的服务行为观测和业务管理功能，然而也因为这些高级特性和复杂的配置流程，Istio 可能并不如其它一些替代方案那样容易上手。
istio的特性：
istio 提供一种简单的方式来为已部署的服务建立网络，该网络具有负载均衡、服务间认证、监控等功能，而不需要对服务的代码做任何改动。想要让服务支持istio，只需要在您的环境中部署一个特殊的 sidecar 代理，使用 istio 控制平面功能配置和管理代理，拦截微服务之间的所有网络通信：
HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡。
通过丰富的路由规则、重试、故障转移和故障注入，可以对流量行为进行细粒度控制。
可插入策略层和配置 API，支持访问控制、速率限制和配额。
对出入集群入口和出口中所有流量的自动度量指标、日志记录和跟踪。
通过强大的基于身份的验证和授权，在集群中实现安全的服务间通信。
istio 旨在实现可扩展性，满足各种部署需求。
istio优势：
集群规模可视性：在故障状况出现时，运营人员需要利用多种工具以始终关注集群运行状况并分析微服务状态图表。
弹性与效率：在开发微服务时，运营人员需要假设网络本身处于不可靠状态。运营人员能够利用重试、负载均衡、流量控制（HTTP/2）以及断路补偿等方式解决由网络可靠性低下所造成的各类常见故障模式。Istio 项目则提供一种统一方法以配置上述功能，使得运营人员能够更为轻松地运作高弹性水平服务网格。
开发人员生产力：Istio 项目能够确保开发人员专注于利用已选择的编程语言构建服务功能，从而极大提升其生产能力。
政策驱动型运营：Istio 项目能够授权具有不同职能的团队以实现独立运作。
默认安全：分布式计算当中经常存在着大量网络安全问题。Istio 项目允许运营人员利用 TLS 连接以认证并保护各服务之间的所有通信，而不会给开发人员或者运营人员带来由证书管理造成的额外负担。其安全框架与新的 SPIFFE 规范保持一致，事实上谷歌公司一直在内部广泛使用类似的保障性系统。
增量化采用：在设计 Istio 项目时充分考虑到网络内所运行各服务的透明性，允许团队随着时间推移逐步采用 Istio 提供的各项功能。
2、Linkerd
Linkerd是Buoyant公司2016年率先开源的高性能网络代理，是业界的第一款Service Mesh框架。其主要用于解决分布式环境中服务之间通信面临的一些问题，如网络不可靠、不安全、延迟丢包等问题。
按照官网的说法，Linkerd 是一个轻量级、安全优先的 Kubernetes 服务网格。它的创建流程快到让人难以置信（据称在 Kubernetes 安装只需要 60 秒），这是大多数开发者喜闻乐见的。Linkerd 并没有采用基于 Envoy 的构建方案。而是使用了一个基于 Rust 的高性能代理 linkerd2-proxy，这个代理是专门为 Linkerd 服务网格编写的。
Linkerd 由社区驱动，是 100% 的 Apache 许可开源项目，它还是 CNCF 孵化项目。Linkerd 始于 2016 年，维护者也花了不少时间去解决其中的缺陷。
使用 Linkerd 服务网格，应用服务可以增强其可靠性、可观测性及其在 Kubernetes 上部署的安全性。举个例子，可观测性的增强可以帮助用户解决服务间的延迟问题。使用 Linkerd 不要求用户做很多代码调整或是花费大量时间写 YAML 配置文件。可靠的产品特性和正向的开发者使用回馈，使得 Linkerd 成为服务网格中一个强有力的竞争者。
Linkerd使用Scala语言编写，运行于JVM，底层基于Twitter的Finagle库，并对其做了相应的扩展。最主要的是Linkerd具有快速、轻量级、高性能等特点，每秒以最小的延迟及负载处理万级请求，易于水平扩展。除此之外，还有以下功能：
支持多平台：可运行于多种平台，比如Kubernetes、DC/OS、Docker，甚至虚拟机或物理机。
无缝集成多种服务发现工具。
支持多协议，如gRPC、HTTP/1.x、HTTP/2，甚至可通过linkerd-tcp支持TCP协议。
支持与第三方分布式追踪系统Zipkin集成。
灵活性、扩展性高，可通过其提供的接口开发自定义插件。
目前，Linkerd和Linkerd2并行开发，其情况如下：
Linkerd：Linkerd使用**Scala语言编写**，运行于JVM，底层基于Twitter的Finagle库，并对其做了相应的扩展。
Linkerd2：使用Go语言和Rust语言完全重写了Linkerd，专门用于Kubernetes。
3、Consul Connect
Consul Connect 是来自 HashiCorp 的服务网格，专注于路由和分段，通过应用级的 sidecar 代理来提供服务间的网络特性。Consult Connect 侧重于应用安全，提供应用间的双向 TLS 连接以实现授权和加密。
Consult Connect 独特的一点是提供了两种代理模式。一种是它内建的代理，同时它还支持 Envoy 方案。Connect 强调可观测性，集成了例如 Prometheus 这样的工具来监控来自 sidecar 代理的数据。Consul Connect 可以灵活地满足开发者使用需求。比如，它提供了多种方式注册服务：可以从编排系统注册，可以通过配置文件，通过 API 调用，或是命令行工具。
Consul Connect 的特性，使网络管理变得与规模无关，并且您不需要显著修改应用程序来保护传输中的数据。Connect 允许工程师具有更简单的网络拓扑，并可以在分布式应用环境中维护网络性能。
Consul Connect 让网络管理更简单:
Sidecar 代理: 将TLS通信带到您的服务中，不依赖任何应用程序，也不需要修改应用程序。
Service Access Graph: 让操作员对于有操作权限的服务通信可进行集中的，与规模无关的控制。
Consul Connect 更安全:
自动流量加密：具有相互的TLS和低信任的姿。
证书管理： 在不会中断服务的情况下使用内置的证书颁发机构（CA）提供生成、分发和rotates证书的功能。
虽然对性能影响很小，但是使用Consul的新的本地集成能力（允许用户在没有代理的情况下构建连接管理）可以减轻这种影响。
4、Kuma
Kuma 来源于 Kong，自称是一个非常好用的服务网格替代方案。Kuma 是一个基于 Envoy 的平台无关的控制平面。Kuma 提供了安全、观测、路由等网络特性，同时增强了服务间的连通性。Kuma 同时支持 Kubernetes 和虚拟机。
Kuma 让人感兴趣的一点是，它的企业版可以通过一个统一控制面板来运维管理多个互相隔离独立的服务网格。这项能力可以满足安全要求高的使用场景。既符合隔离的要求，又实现集中控制。
Kuma 也是相对容易安装的一个方案。因为它预先内置了不少策略。这些策略覆盖了常见需求，例如路由，双向 TLS，故障注入，流量控制，加密等场景。
Kuma 原生兼容 Kong，对于那些已经采用 Kong API 管理的企业组织，Kuma 是个非常自然而然的候选方案。
5、Maesh
Maesh 是来自 Containous 的容器原生的服务网格，标榜自己是比市场其它服务网格更轻量级更易用的方案。和很多基于 Envoy 构建的服务网格不同，Maesh 采用了 Traefik， 一个开源的反向代理和负载均衡器。
Maesh 并没有采用 sidecar 的方式进行代理，而是在每个节点部署一个代理终端。这样做的好处是不需要去编辑 Kubernetes 对象，同时可以让用户有选择性地修改流量，Maesh 相比其他服务网格侵入性更低。Maesh 支持的配置方式：在用户服务对象上添加注解或是在服务网格对象上添加注解来实现配置。
实际上，SMI 是一种新的服务网格规范格式，对 SMI 的支持 Maesh 独有的一大亮点。随着 SMI 在业界逐渐被采用，可以提高可扩展性和减缓供应商绑定的担忧。
Maesh 要求 Kubernetes 1.11 以上的版本，同时集群里安装了 CoreDNS/KubeDNS。这篇安装指南演示了如何通过 Helm v3 快速安装 Maesh。
helm repo add maesh https://containous.github.io/maesh/charts helm repo update helm install maesh maesh/maesh
6、ServiceComb-mesher
Apache 软件基金会形容旗下的 ServiceComb-mesher “是一款用 Go 语言实现的高性能服务网格”。Mesher 基于一个非常受欢迎的 Go 语言微服务开发框架 Go Chassis[4] 来设计实现。因此，它沿袭了 Go Chassis 的一些特性如服务发现、负载均衡、错误容忍、路由管理和分布式追踪等特性。
Mesher 采用了 sidecar 方式；每个服务有一个 Mesher sidecar 代理。开发人员通过 Admin API 和 Mesher 交互，查看运行时信息。Mesher 同时支持 HTTP 和 gRPC，可快速移植到不同的基础设施环境，包括 Docker、Kubernetes、虚拟机和裸金属机环境。
7、Network Service Mesh（NSM）
Network Service Mesh（NSM）是一款专门为 telcos 和 ISPs 设计的服务网格。它提供了一层级用以增强服务在 Kubernetes 的低层级网络能力。NSM 目前是 CNCF 的沙箱项目。
根据 NSM 的文档说明，“经常接触 L2/L3 层的网络运维人员抱怨说，适合他们的下一代架构的容器网络解决方案几乎没有”。
因此，NSM 在设计时就考虑到一些不同使用场景，尤其是网络协议不同和网络配置混杂的场景。这使得 NSM 对某些特殊场景具备相当吸引力，例如边缘计算、5G 网络和 IOT 设备等场景。NSM 使用简单直接的 API 接口去实现容器和外部端点的之间的通信。
和其他服务网格相比，NSM 工作在另一个不同的网络层。VMware 形容 NSM“专注于连接”。GitHub 的文档演示了 NSM 是如何与 Envoy协同工作的。
8、AWS App Mesh
AWS APP Mesh 为开发者提供了“适用于不同服务的应用层的网络”。它接管了服务的所有网络流量，使用开源的 Envoy 代理去控制容器的流量出入。AWS App Mesh 支持 HTTP/2 gRPC。
AWS App Mesh 对于那些已经将容器平台深度绑定 AWS 的公司而言，会是相当不错的服务网格方案。AWS 平台包括 AWS Fargate，Amazon Elastic Container Service，Amazon Elastic Kubernetes Service（EKS），Amazon Elastic Compute Cloud（EC2），Kubernetes on EC2，包括 AWS App Mesh 不需要付额外费用。
AWS App Mesh 和 AWS 生态内的监控工具无缝兼容。这些工具包括 CloudWatch 和 AWS X-Ray，以及一些来自第三方供应商的工具。因为 AWS 计算服务支持 AWS Outposts，AWS App Mesh 可以和混合云和已经部署的应用良好兼容。
AWS App Mesh 的缺点可能是使得开发者深度绑定了单一供应商方案，相对闭源，可扩展性缺失。
9、OpenShift Service Mesh by Red Hat
OpenShift 是来自红帽的一款帮助用户“连接、管理、观测微服务应用”的容器管理平台。OpenShift 预装了不少提升企业能力的组件，也被形容为企业级的混合云 Kubernetes 平台。
OpenShift Service Mesh 基于开源的 Istio 构建，具备 Isito 的控制平面和数据平面等特性。OpenShift 利用两款开源工具来增强 Isito 的追踪能力和可观测性。OpenShift 使用 Jaeger 实现分布式追踪，更好地跟踪请求是如何在服务间调用处理的。
另一方面，OpenShift 使用了 Kiali 来增强微服务配置、流量监控、跟踪分析等方面的可观测性。
10、Conduit
Conduit 是 Rust 语言开发的超轻量级 service mesh。
Conduit 的目标是成为最快、最轻、最简单并且最安全的 Service Mesh。他使用 Rust 构建了快速、安全的数据平面，用 Go 开发了简单强大的控制平面，总体设计围绕着性能、安全性和可用性进行。
Conduit 是让微服务安全可靠的下一代 Service Mesh。他能透明的管理服务之间的通信，自动提供可测性、可靠性、安全性和弹性的支持。还是跟 Linkerd 相仿，他的数据平面是在应用代码之外运行的轻量级代理，控制平面是一个高可用的控制器。然而和 Linkerd 不同的是，Conduit 的设计更加倾向于 Kubernetes 中的低资源部署。
Conduit 的特性：
轻量高速：Conduit 代理只需要不到 10 MB 实际内存（RSS），p99 延迟在分毫秒以内。
安全：Rust 的内存使用相当安全，同时还缺省使用了 TLS，Conduit 的安全性与生俱来。
最小化：Conduit 的特性集被设计为尽量的最小化和可编排，便于使用 gRPC 插件进行定制。
易用性：内置有聚合的服务指标，强大的客户端工具（想想看，微服务界的 tcpdump），Conduit 为运维人员提供了新的强大的工具来对付生产环境的微服务。
如何选择
正如文中所提到的，可供选择的服务网格方案有很多，同时还有新的方案在涌现。
当然，每一种方案在技术实现上都略有不同。选择一款合适的服务网格，主要考虑的因素包括，你能接受它带来多大的侵入性，它的安全性如何，以及平台成熟度等。
目前比较流行的 Service Mesh 开源软件有 Linkerd、Envoy 和 Istio，而最近 Buoyant（开源 Linkerd 的公司）又发布了基于 Kubernetes 的 Service Mesh 开源项目 Conduit。以下几点可以帮助 DevOps 团队选择一款适合他们场景的服务网格：
是否依赖Envoy。Envoy 有一个活跃的社区生态。开源，同时是许多服务网格的底座。Envoy 具备的丰富特性使得其成为一个很难绕过的因素。
具体使用场景。服务网格为微服务而生。如果你的应用是一个单体的庞然大物，那你在服务网格上的投入可能达不到预期的收益。如果不是所有应用都部署在 Kubernetes，则应该优先考虑平台无关的方案。
现有容器管理平台。有些企业已经使用了特定供应商的生态来解决容器编排问题，例如 AWS 的 EKS，红帽的 OpenShift，Consul。沿袭原有的生态，可以继承并拓展原有的特性。而这些可能是开源方案所不能提供的。
所在行业。许多服务网格不是为特定行业专门设计的。Kuma 统一管理多个隔离服务网格的能力可能更适用于收到高度管制的金融行业。底层网络 telcos 和 ISPs 则更应该考虑 Network Service Mesh。
对可视化的要求。可观测性是服务网格的核心能力之一。考虑进一步定制和更深度能力的团队应该优先考虑 Istio 或 Consul。
是否遵循开发标准。遵循开发标准使得你的平台更具备前瞻性和可扩展性。这使得企业会倾向于采用支持 SMI 的方案，Maesh 或其他基金会孵化的项目如 Linkerd。
是否重视用户体验。考虑运维人员的易用性是评判新工具的关键指标。这方 Linkerd 似乎在开发者中间口碑不错。
团队准备。评估你的团队所具备的资源和技术储备，在技术选型时决定你们适合用基于 Envoy 的 Istio，或是供应商抽象封装的方案，例如 OpenShift。
这些考虑因素没有覆盖到全部场景。此处仅是抛砖引玉，引起读者的思考。希望读完上面所列的服务网格清单，和相关的决策因素之后，你们的团队能找到新的方法去改善微服务应用的网络特性。
相关阅读：
Istio项目名称的由来 https://www.amd5.cn/atang_4803.html
2021年11款最佳的开源Kubernetes工具 https://www.amd5.cn/atang_5082.html
七款VPN开源工具介绍 https://www.amd5.cn/atang_4348.html
二十多款开源的服务器监控软件，你用过几款? https://www.amd5.cn/atang_4712.html
