简介1.1 Service Mesh简介

来阿里技术的引言：

随着云原生时代的来临，微服务架构与容器化部署模式越来越流行，从原来的新潮词汇慢慢演变成为现代IT企业的技术标配。曾经被认为理所当然的巨无霸单体应用，被拥抱了微服务的架构师们精心拆分成了一个又一个小而独立的微服务，接着再被拥抱了容器化的工程师们打包成了自带依赖的Docker镜像，最后通过某种神秘的DevOps流水线持续运送到前线 —— 也就是无人不知的 —— 风暴降生·谷歌之子·打碎镣铐者·云时代操作系统·Kubernetes —— 之中部署和运行。

听上去似乎一切都很美好？显然不是，这世上永远没有免费的午餐。所有美好的东西都会有它的阴暗面，微服务也不例外：

原来只需要部署和管理单个应用，现在一下裂变成了好几个，运维管理成本成倍上升。

原来各个模块之间的交互可以直接走应用内调用（进程间通信），现在都给拆分到了不同进程甚至节点上，只能使用复杂的RPC通讯。

难道辛辛苦苦落地了微服务，只能一边在老板面前强撑着“没问题，一切安好”，另一边默默忍受着研发与运维的私下抱怨？显然也不是。对于以“偷懒”著称的程序员们，办法总是比困难多。比如上面第1个问题，云原生所倡导的DevOps和容器化，就是一剂几乎完美的解药：通过自动化的CI/CD流水线，多应用的集成构建部署变得更加快捷；通过Docker镜像和K8s编排，多应用的资源调度运维管理也变得不那么痛苦。至于第2个问题，那就该看本文的主角 —— Service Mesh（服务网格），是如何力挽狂澜，近乎完美地解决微服务之间的通讯问题了。

Service Mesh用于描述组成应用程序的微服务及其之间的交互。

随着服务数量的增加和复杂性的增加，扩展和管理变得越来越困难。因此Service Mesh可以为微服务架构提供服务发现，负载均衡，故障恢复，指标和监视。

Service Mesh 通常还能够满足更复杂的需求，例如A/B测试，金丝雀发布，速率限制，访问控制和端到端身份验证。

总结：Service Mesh 提供了一种轻松创建服务网络的方式，该网络具有负载均衡，服务到服务的身份验证，监视等功能，而微服务代码更改很少或没有更改。

Linkerd是市场上第一个Service Mesh，但是Istio使Service Mesh更受欢迎。这两个项目都是Service Mesh最前沿的项目。

1.1.1Service Mesh的诞生1.1.1.1微服务的利与弊

微服务带来的好处：

1）单一职责：拆分后的单个微服务，通常只负责单个高内聚自闭环功能，因此很易于开发、理解和维护。

2）架构灵活：不同微服务应用之间在技术选型层面几乎是独立的，可以由选择最适合的技术栈。

3）部署隔离：相比巨无霸单体应用，单个微服务应用的代码和产物体积大大减少，更容易持续集成和快速部署；同时，通过进程级别的隔离，也不再像单体应用一样只能同生共死，故障隔离效果显著提升。

4）独立扩展：单体应用时代，某个模块如果存在资源瓶颈（e.g. CPU/内存），只能跟随整个应用一起扩容，白白浪费很多资源。微服务化后，扩展的粒度细化到了微服务级别，可以更精确地按需独立扩展。

微服务带来的问题：

1）如何找到服务的提供？微服务通讯必须走远程过程调用（HTTP/REST本质上也属于RPC），当其中一个应用需要消费另一个应用的服务时，无法再像单体应用一样通过简单的进程内机制（e.g. Spring的依赖注入）就能获取到服务实例；你甚至都不知道有没有这个服务方。

2）如何保证远程调的可靠性?既然是RPC，那必然要走IP网络，而我们都知道网络（相比计算和存储）是软件世界里最不可靠的东西。虽然有TCP这种可靠传输协议，但频繁丢包、交换机故障甚至电缆被挖断也常有发生；即使网络是好的，如果对方机器宕机了，或者进程负载过高不响应呢？

3）如何降低服务调的延迟？网络不只是不可靠，还有延迟的问题。虽然相同系统内的微服务应用通常都部署在一起，同机房内调用延迟很小；但对于较复杂的业务链路，很可能一次业务访问就会包括数十次RPC调用，累积起来的延迟就很可观了。

4）如何保证服务调的安全性？网络不只是不可靠和有延迟，还是不安全的。互联网时代，你永远不知道屏幕对面坐的是人还是狗；同样，微服务间通讯时，如果直接走裸的通讯协议，你也永远不知道对端是否真的就是自己人，或者传输的机密信息是否有被中间人偷听。

1.1.1.2 各大厂重复造轮子问题

为了解决上述微服务引入的问题，最早那批吃螃蟹的工程师们，开始了各自的造轮子之旅：

1）服务发现（Service Discovery）：解决“我想调用你，如何找到你”的问题。

2）服务熔断（Circuit Breaker）：缓解服务之间依赖的不可靠问题。

3）负载均衡（Load Balancing）：通过均匀分配流量，让请求处理更加及时。

4）安全通讯：包括协议加密（TLS）、身份认证（证书/签名）、访问鉴权（RBAC）等。

重复造轮子带来的问题：

1）需要编写和维护量非功能性代码，如何集中精力专注业务创新?

2）服务通讯逻辑与业务代码逻辑混在一起，动不动还会遇到点匪夷所思的分布式bug。

1.1.1.3 微服务框架

各种高质量、标准化、解决了共享和复用问题的精品轮子应运而生，比如包括 Apache Dubbo、Spring Cloud、Netflix OSS、gRPC 等等。

微服务框架的问题：

1）并非完全透明：程序员们仍然需要正确理解和使这些库，上手成本和出错概率依然很高。

2）限制技术选择：使用这些技术后，应用很容易就会被对应的语和框架强绑定（vendor-lock）。

3）维护成本高：库版本升级，需要牵连应一起重新构建和部署；麻烦且易出故障。

1.1.1.4 Service Mesh诞生

Service Mesh 的诞生，彻底解决了上述所有问题。简单来说，Service Mesh 就是通过 Sidecar模式和分层思想，将上述类库和框架要干的事情从应用中彻底剥离了出来，并统一下沉到了基础设施层。

1.1.2什么是Service Mesh

2016年9月29日，Buoyant公司内部一次关于微服务的分享会上，“Service Mesh” ，这个接下来几年占据各种云原生头条的 buzz word（不得不说，起名真是门艺术，Micro-Services -> Service Mesh，承前启后和顺其自然，顾名思义：把微服务的各个service（服务）节点，用一张mesh（网格）连接起来。就这样，原本被拆散得七零八落的微服务们，又被 Service Mesh 这张大网紧密得连接到了一起；即使依然天各一方（进程间隔离），但也找回了当年一起挤在单体应用内抱团撒欢的亲密感（通信更容易）），就这么被造出来了。

从时间点上来看，Service Mesh是先有落地发布版本，然后再有这个名字和概念的。而不是先从某个PPT提出概念，然后才有落地的。

1.1.2.1 定义

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.（William Morgan）

服务网格是一种用来处理服务间通讯的一层专用基础设施（中间件）。它负责在组成现代化云原生应用的复杂服务拓扑间可靠的分发请求。在实践中，服务网格通常实现为一组轻量级网络代理，这些代理与应用程序代码一起部署，而这对应用程序来说是透明无感知的。（威廉·摩根）

定义中的几个关键点解读：

1）Service Mesh 不是用来解决业务领域问题的，而是一层专门的基础设施（中间件）

2）Service Mesh 的定位很简单也很清晰，就是用来处理服务与服务之间的通讯。

3）Service Mesh 的愿景就是让服务间的请求传递变得可靠。

4）从一开始就是为现代化的云原生应用而生，瞄准了未来的技术发展趋势。

5）典型方式都是通过一组轻量级的网络代理，在应用无感知的情况下偷偷就把这事给干了。

6）这些网络代理一定是跟应用部署在一起，否则，如果应用与代理之间的通讯也不可靠。

形象概括图

每个微服务所处的主机（host）或容器组（pod）中都会部署一个代理软件，用于代理微服务应用实例之间的RPC调用。对于应用而言，这一切都是无感知的：它还是照常发起自己的RPC调用，只是不再需要关心对端服务方的地址，因为服务发现都由代理节点负责了。

1.1.2.2 SideCar（边车模式）

在Service Mesh架构中，服务框架的功能都集中实现在SideCar里，并在每一个服务消费者和服务提供者的本地都部署一个 SideCar，服务消费者和服务提供者只管自己的业务实现，服务消费者向本地的 SideCar 发起请求，本地的 SideCar 根据请求的路径向注册中心查询，得到服务提供者的可用节点列表后，再根据负载均衡策略选择一个服务提供者节点，并向这个节点上的 SideCar 转发请求，服务提供者节点上的 SideCar 完成流量统计、限流等功能后，再把请求转发给本地部署的服务提供者进程，从而完成一次服务请求。

边车就像一个服务的 Agent，这个服务所有对外的进出通讯都通过这个 Agent 来完成。这样，我们就可以在这个 Agent 上做很多文章了。如上图，边上的人可以专注的做自己的事情，而sidercar负责处理开车相关的事情，实现业务和通用功能的分离。但是，我们需要保证的是，这个 Agent 要和应用程序一起创建，一起停用。

1.1.2.3 分层概念

Service Mesh 主要由两部分组成，一部分是 Data Plane（SideCar），负责服务之间请求的转发；一部分是 Control Plane，负责具体的服务治理。

1.1.3 Service Mesh的主流实现1.1.3.1 Linkerd

背后公司是Buoyant，开发语使用Scala，2016年115日初次发布，2017年123日加入CNCF，2018年51发布1.4.0版本。

Linkerd 是一个轻量级、安全优先的 Kubernetes 服务网格。它的创建流程快到让人难以置信（据称在 Kubernetes 安装只需要 60 秒），这是大多数开发者喜闻乐见的。Linkerd 并没有采用基于 Envoy 的构建方案。而是使用了一个基于 Rust 的高性能代理 linkerd2-proxy，这个代理是专门为 Linkerd 服务网格编写的。

Linkerd 由社区驱动，是 100% 的 Apache 许可开源项目。它还是 CNCF 孵化项目。Linkerd 始于 2016 年，维护者也花了不少时间去解决其中的缺陷。

1.1.3.2 Conduit

背后公司也是Buoyant，开发语言使用Rust和Go，2017年12月5日初次发布，2018年427日发布0.4.1版本。

作为Istio的挑战者，Conduit的整体架构与Istio类似也明确区分了管控平面和数据平面，但同时它还具备如下关键特性：

1）轻量快速：Conduit的数据平面是基于原生的Rust语言编写，非常轻量、快速和安全（Rust相比C/C++的最大改进点就是安全性）。单个代理的实际内存消耗（RSS）小于10mb，延迟的p99分位点小于1ms，基本相当于能为应用程序提供免费（无额外开销）的Service Mesh功能。

2）安全保障：Conduit构建之初就考虑了云原生环境的安全性，包括Rust语言内存安全性、默认TLS加密等。

3）端到端可见性：Conduit可以自动测量和聚合服务的成功率、延迟与请求容量数据，让开发者在无需变更应用代码就能获取到服务的完整行为视图。

4）Kubernetes增强：Conduit为K8s集群添加了可靠性、可见性和安全性，同时给予了开发者对自己应用程序运行时行为的完全控制。

1.1.3.3 Envoy

背后公司是Lyft，开发语言使用C++ 11，2016年9月13日初次发布，2017年914日加CNCF，2018年3月21日发布1.6.0版本。

1.1.3.4 Istio

Istio是基于 Envoy 构建的一个可扩展的开源服务网格。开发团队可以通过它连接、加密、管控和观察应用服务。

Istio 于 2017 年开源，开发语言使用Go，2017年5月10日初次发布，2018年3月31日发布0.7.1版本。Lyft 在 2017 年把 Envoy 捐赠给了 CNCF。

目前 IBM、Google、Lyft 仍在对其进行持续维护升级。

1.1.3.5 Consul Connect

Consul Connect 是来自 HashiCorp 的服务网格，专注于路由和分段，通过应用级的 sidecar 代理来提供服务间的网络特性。Consult Connect 侧重于应用安全，提供应用间的双向 TLS 连接以实现授权和加密。

Consult Connect 独特的一点是提供了两种代理模式。一种是它内建的代理，同时它还支持 Envoy 方案。Connect 强调可观测性，集成了例如 Prometheus 这样的工具来监控来自 sidecar 代理的数据。

Consul Connect 可以灵活地满足开发者使用需求。比如，它提供了多种方式注册服务：可以从编排系统注册，可以通过配置文件，通过 API 调用，或是命令行工具。

1.1.3.6 Kuma

Kuma 来源于 Kong，自称是一个非常好用的服务网格替代方案。Kuma 是一个基于 Envoy 的平台无关的控制平面。Kuma 提供了安全、观测、路由等网络特性，同时增强了服务间的连通性。Kuma 同时支持 Kubernetes 和虚拟机。

Kuma 让人感兴趣的一点是，它的企业版可以通过一个统一控制面板来运维管理多个互相隔离独立的服务网格。这项能力可以满足安全要求高的使用场景。既符合隔离的要求，又实现集中控制。

Kuma 也是相对容易安装的一个方案。因为它预先内置了不少策略。这些策略覆盖了常见需求，例如路由，双向 TLS，故障注入，流量控制，加密等场景。

Kuma 原生兼容 Kong，对于那些已经采用 Kong API 管理的企业组织，Kuma 是个非常自然而然的候选方案。

注：Kong是一个在Nginx中运行的Lua应用程序，可以通过lua-nginx模块实现，Kong不是用这个模块编译Nginx，而是与OpenRestry一起发布，OpenRestry已经包含了lua-nginx-module，OpenRestry是Nginx的一组扩展功能模块。Kong是一个Api Gateway，通过插件的形式提供负载均衡，日志记录，身份验证，速率限制，转换等功能。Kong可以很轻松扩展功能，模块化，可以运行在任何基础设施上。

1.1.3.7 Maesh

Maesh 是来自 Containous 的容器原生的服务网格，标榜自己是比市场其它服务网格更轻量级更易用的方案。和很多基于 Envoy 构建的服务网格不同，Maesh 采用了 Traefik， 一个开源的反向代理和负载均衡器。

Maesh 并没有采用 sidecar 的方式进行代理，而是在每个节点部署一个代理终端。这样做的好处是不需要去编辑 Kubernetes 对象，同时可以让用户有选择性地修改流量，Maesh 相比其他服务网格侵入性更低。Maesh 支持的配置方式：在用户服务对象上添加注解或是在服务网格对象上添加注解来实现配置。

实际上，SMI 是一种新的服务网格规范格式，对 SMI 的支持 Maesh 独有的一大亮点。随着 SMI 在业界逐渐被采用，可以提高可扩展性和减缓供应商绑定的担忧。

Maesh 要求 Kubernetes 1.11 以上的版本，同时集群里安装了 CoreDNS/KubeDNS。这篇安装指南[3]演示了如何通过 Helm v3 快速安装 Maesh。

1.1.3.8 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、虚拟机和裸金属机环境。

1.1.3.9 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 的文档[5]演示了 NSM 是如何与 Envoy协同工作的。

1.1.3.10 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 的缺点可能是使得开发者深度绑定了单一供应商方案，相对闭源，可扩展性缺失。

1.1.3.11 OpenShift Service Mesh by Red Hat

OpenShift 是来自红帽的一款帮助用户“连接、管理、观测微服务应用”的容器管理平台。OpenShift 预装了不少提升企业能力的组件，也被形容为企业级的混合云 Kubernetes 平台。

OpenShift Service Mesh 基于开源的 Istio 构建，具备 Isito 的控制平面和数据平面等特性。OpenShift 利用两款开源工具来增强 Isito 的追踪能力和可观测性。OpenShift 使用 Jaeger 实现分布式追踪，更好地跟踪请求是如何在服务间调用处理的。

另一方面，OpenShift 使用了 Kiali 来增强微服务配置、流量监控、跟踪分析等方面的可观测性。

1.1.4 Service Mesh存在的问题1.1.4.1边车问题（sidecar ）

Kubernetes 服务网格解决方案要求你在每一个应用 Pod 上添加一个代理 sidecar 容器，如 Envoy 或 Linkerd-proxy。这是正确的：即使在一个非常小的环境中，比如说有 20 个服务，每个服务运行五个 Pod，分布在三个节点上，你也有 100 个代理容器。无论代理的实现多么小和有效，这种纯粹的重复都会耗费资源。每个代理使用的内存与它需要能够通信的服务数量有关。即使在我们的小环境中，在三个节点上有 100 个代理，这种优化配置仍然需要每个节点 2GB 左右。

更多hop，更多问题：在非服务网格世界中，通信问题通常是客户端或服务器的故障。如果服务A从服务B获取HTTP 5XX响应，则可以查看代码并为B记录日志，以了解为什么会发生这种情况。而在服务网格世界中，这些响应可能来自B、B主机上的代理或A主机上的代理。现在，您不能只在一个地方看，而必须在三个地方都看。这意味着调试过程更慢且更乏味。

1.1.4.2 Service Mesh 拉长了网络请求的轨迹

在一套标准的云原生环境里，你的流量可能需要先经过这么几个步骤：集群外的负载均衡器 → 集群网关 → Service Mesh 的 Ingress → Sidecar → 业务服务而且，后续链路每多一个业务服务，都会额外流经一个 Sidecar。即便如此多的基础设施名义上是为了保障业务稳定性，但每一个节点，也都同样会带来额外的隐患，需要我们考虑性能，考虑高可用，考虑响应时间。

由于请求需要在出站和入站的时候，各经过一次代理，那么延时会增加。

1.1.4.3额外的维护复杂度（Scope is N2）

伴随着基础设施的厚度提升，势必会带来额外的维护复杂度。在云原生时代，你的一段 Java 代码不再只需要一套 JRE 环境就可以接受来自世界各地的请求。你可能还需要一套 Kubernetes ，有一堆配置文件，然后它们会帮你启动有一个叫 Sidecar 的代理，以及一些你从未考虑过但已经存在在那里的进程。虽然随着技术的发展，你甚至感受不到它们的存在，但它们始终是在的，而且，它们也可能坏掉。ServiceMesh的基础设施层定位使得其实践复杂度对集群环境的理解要求更高，一定程度上抬高了落地门槛，也加大了维护难度。

假设您有N个服务，并且想要以某种方式更新所有服务，例如，将库替换为较新的版本。通常，这将涉及O（N）个更新和O（N）可能出错的事情。但是，在推出服务网格时，您正在进行O（N2）更新，因为您正在更改（并可能破坏）每对服务的通信方式。 这意味着，即使只提供少量的服务，也有很多事情可能会出错（并且会出错）。服务A与B进行通信可能很好，而B与C进行通信可能很好，但是A至C链接有时可能出于某些奇怪的原因而超时，这需要花费数天时间进行调试。如果您在一家拥有数十项服务的公司中，那么N2效果可能是巨大的-为进行大量工作和调试工作做好准备。

大多数服务网格仅在代理上使用加密来代理链接，而不在代理上使用加密。但是，这些代理到代理的链接通常会出现很多问题，并且无法轻松地在线检查每个请求的详细信息，从而使调试变得更加困难。

许多服务网格的基础代理，它具有数不清的可以调整以影响其行为的配置项。这意味着我们想要更好地使用服务网格，必须深入理解代理。

1.2 Istio简介

Istio 是一个由谷歌、IBM 与 Lyft 共同开发的开源项目，旨在提供一种统一化的微服务连接、安全保障、管理与监控方式。Istio 项目能够为微服务架构提供流量管理机制，同时亦为其它增值功能（包括安全性、监控、路由、连接管理与策略等）创造了基础。这款软件利用久经考验的 Lyft Envoy 代理进行构建，可在无需对应用程序代码作出任何改动的前提下实现可视性与控制能力。Istio 项目是一款强大的工具，可帮助 CTO/CIO 们立足企业内部实施整体性安全、政策与合规性要求。

Istio是对Service Mesh的产品化实践，帮助微服务实现了分层解耦。

优势与特性2.1优势

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

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

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

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

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

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

2.1.1集群规模可视性

在故障状况出现时，运营人员需要利用多种工具以始终关注集群运行状况并分析微服务状态图表。Istio 项目能够监控与应用程序及网络活动相关的数据，利用 Prometheus 与 Grafana 对这部分数据加以渲染，而后将相关指标与日志记录发送至任何收集、聚合与查询系统当中以实现功能扩展。Istio 项目亦利用 Zipkin 追踪分析性能热点并对分布式故障模式加以诊断。

2.1.2弹性与效率

在开发微服务时，运营人员需要假设网络本身处于不可靠状态。运营人员能够利用重试、负载均衡、流量控制（HTTP/2）以及断路补偿等方式解决由网络可靠性低下所造成的各类常见故障模式。Istio 项目则提供一种统一方法以配置上述功能，使得运营人员能够更为轻松地运作高弹性水平服务网格。

2.1.3开发人员生产力

Istio 项目能够确保开发人员专注于利用已选择的编程语言构建服务功能，从而极大提升其生产能力。另外，Istio 项目则负责以统一化方式处理弹性与网络挑战。开发人员无需将解决方案的分布式系统问题解决机制引入编写的代码当中。Istio 项目还能够支持 A/B 测试、金丝雀部署以及故障注入等常用功能，旨在进一步提高生产效率。

2.1.4政策驱动型运营

Istio 项目能够授权具有不同职能的团队以实现独立运作。其将集群运营人员与功能开发人员进行周期性剥离，从而在无需更改代码的前提下提升安全性、监控能力、扩展性与服务拓扑水平。运营人员能够精确控制生产流量中各个子集的路由方式，从而匹配新的服务版本。另外，运营人员还能够在流量中注入故障或者提高延迟水平，用以测试服务见长的弹性 ; 同时设置速率限制以防止服务过载。Istio 项目还可用于强制执行合规性要求，例如在服务之间定义 CL 以确保仅具备授权的服务间可相互通信。

2.1.5默认安全

分布式计算当中经常存在着大量网络安全问题。Istio 项目允许运营人员利用 TLS 连接以认证并保护各服务之间的所有通信，而不会给开发人员或者运营人员带来由证书管理造成的额外负担。其安全框架与新的 SPIFFE 规范保持一致，事实上谷歌公司一直在内部广泛使用类似的保障性系统。

2.1.6增量化采用

在设计 Istio 项目时充分考虑到网络内所运行各服务的透明性，允许团队随着时间推移逐步采用 Istio 提供的各项功能。采用方可以先从启用集群范围内可视性起步，并在 Istio 在环境中的表现感到满意后根据实际需要启用其它功能。

2.1.7整合和定制

Istio 的策略实施组件可以扩展和定制，与现有的 ACL、日志、监控、配额、审查等解决方案集成。

2.2 核心特性2.2.1流量管理

Istio 简单的规则配置和流量路由允许您控制服务之间的流量和 API 调用过程。Istio 简化了服务级属性（如熔断器、超时和重试）的配置，并且让它轻而易举的执行重要的任务（如 A/B 测试、金丝雀发布和按流量百分比划分的分阶段发布）。

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

2.2.2安全

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

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

2.2.3可观察性

Istio 健壮的追踪、监控和日志特性让您能够深入的了解服务网格部署。通过 Istio 的监控能力，可以真正的了解到服务的性能是如何影响上游和下游的；而它的定制 Dashboard 提供了对所有服务性能的可视化能力，并让您看到它如何影响其他进程。

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

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

2.2.4平台支持

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

1)Kubernetes 上的服务部署

2)基于 Consul 的服务注册

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

3、架构与组件3.1架构

简图

详图

逻辑上Istio分为数据平面(data pane)和控制平面(control pane)：

1）数据平面用于有一些智能代理组成，微服务之间的网络通信。

2）控制平面负责对智能代理进行管理和配置。

3.2 组件3.2.1 Envoy（数据平面）

Envoy是Lyft用C ++语言编写的高性能代理，它可以代理Service Mesh中所有服务的所有入站和出站流量。它作为Sidecar代理部署。

通常sidecar具有以下功能：

（1）服务发现(discovery)

（2）负载均衡(load balancing)

（3）故障恢复(failure recovery)

（4）服务度量(metrics)

（5）服务监控(monitoring)

（6）A/B测试(A/B testing)

（7）灰度发布(canary rollouts)

（8）限流限速(rate limiting)

（9）访问控制(access control)

（10）身份认证(end-to-end authentication)

Envoy提供以下功能：

1）动态服务发现

2）负载均衡

3）TLS安全传输

4）HTTP/2和gRPC代理

5）断路器(Circuit breakers)

6）健康检查

7）百分比分流路由，按百分比分配流量

8）故障注入(Fault injection)

9）系统度量，丰富的指标

在较新的Istio版本中，Sidecar代理也承担了了一部分Mixer的工作。在早期版本的Istio（<1.6）中，需要使用Mixer从服务网格收集数据信息

3.2.2 Mixer（控制平面）

Mixer的一些核心能力是：

（1）跨平台，作为其他组件的adapter，实现Istio跨平台的能力；

（2）和Envoy通讯，实时各种策略

（3）和Envoy通讯，收集各种数据

Mixer组件是Istio服务网格中的“调音师”，既负责落实各种流量策略（如访问控制、限速），也负责对流量进行观测分析（如日志、监控、追踪）。这些能力都是通过前文提到的Envoy Filter Chain扩展机制实现：Mixer会分别在“请求路由前”（Pre-routing）扩展点和“请求路由后”（Post-routing）扩展点挂载自己的Filter实现。

Mixer的设计核心在于“插件化”，这种模型使得Istio能够适配各种复杂的主机环境，以及后端基础设施。

3.2.3 Pilot

Pilot为Sidecar代理、流量管理功能和弹性伸缩提供服务发现。它将控制流量行为的高级路由规则转换为envoy的配置。

Pilot作为非常重要的控制平面组件，其核心能力是：

（1）为Envoy提供服务发现能力；

（2）为Envoy提供各种智能路由管理能力，例如A/B测试，灰度发布；

（3）为Envoy提供各种弹性管理能力，例如超时，重试，断路策略；

Pilot的设计核心在于“标准化”，它会将各种流控的控制命令转化为Envoy能够识别的配置，并在运行时，将这些指令扩散到所有的Envoy。Pilot将这些能力抽象成通用配置的好处是，所有符合这种标准的Envoy都能够接入到Pilot来。潜台词是，任何第三方可以实现自己的proxy，只要符合相关的API标准，都可以和Pilot集成。

3.2.4 Citadel

Citadel通过内置的身份和凭据管理实现了用户身份验证。以及服务到服务的访问控制。总之，这是一个和安全相关的组件。

3.2.5 Galley

Galley在Istio中配置验证规则（Pilot、Citadel配置的规则）。它是一个配置获取、校验、处理、分发的组件，它的设计核心在于“解耦”，它将“从底层平台（例如：K8S）获取用户配置”与Istio解耦开来。

4、Istio与Linkerd对比4.1 Linkerd介绍

Linkerd是一个开源的轻量级服务网格。由于在2.0版本中完全用Rust语言重写（1.0使用scala编写），以使其超轻便且高性能，它能够提供运行时调试，可观察性的能力

4.1.1 架构

4.1.2 控制平面(Control Plane)

控制平面提供核心功能。它聚合数据，提供面向用户的API。以下是控制平面(Control Plane)的组件(Components)。

1）控制器( Controller)：它由一个公共API容器组成，该容器提供CLI和仪表板的API。

2）目标( Destination) ：数据平面(Data Plane)中的每个代理都将调用此组件(Components)以查找将请求发送到哪个位置。它可以配置路由指标，重试和超时信息。

3）身份( Identity)：它提供了一个证书颁发机构( Certificate Authority)，该证书颁发机构接受来自代理的CSRs请求并返回身份签名的证书。它也提供了mTLS功能。

4）代理注入器( Proxy Injector) ：它是一个准入控制器，用于查找带有（linkerd.io/inject: enabled）注释并更改pod信息添加一个具备代理功能的initContainer容器。

5）服务配置文件验证器( Service Profile Validator ) ：这也是一个准入控制器，用于在保存新的服务配置文件之前对其进行验证。

6）点击( Tap ) ：它从CLI或仪表板接收请求，以实时监视请求和响应，以提供应用程序中的可观察性。

7）Web ：提供Web仪表板。

8）Grafana ：Linkerd通过Grafana提供开箱即用的仪表板。

9）Prometheus ：它通过/metrics在4191端口上抓取代理端点数据来收集和存储所有Linkerd指标。

4.1.2 数据平面(data Plane)

Linkerd数据平面(Data Plane)由轻量级代理组成，这些轻量级代理作为sidecar容器部署。在Pod的初始化阶段注入代理（请参见上面的代理注入器）。自从2.x完全在Rust中重写以来，该代理非常轻便且性能出色。这些代理拦截每个Pod之间的通信，以提供检测和加密（TLS），而无需更改应用程序代码。

代理功能主要有：

1）HTTP，HTTP2和任意TCP协议的透明，零配置代理。

2）自动为HTTP和TCP流量导出Prometheus指标。

3）透明的零配置的WebSocket代理。

4）自动，可感知延迟的7层负载均衡。

5）非HTTP流量的自动4层负载均衡。

4.2 特性对比

特征

Istio

Linkerd

易于安装

各种配置选项和灵活性可能会使团队不知所措

开箱即用的配置，安装相对容易

平台

Kubernetes，虚拟机

Kubernetes

支持的协议

gRPC，HTTP/2，HTTP/1.x，Websocket和所有TCP流量

gRPC，HTTP/2，HTTP/1.x，Websocket和所有TCP流量

入口控制器

Envoy，Istio网关本身

Linkerd本身不提供入口功能

多集群和扩展支持

通过各种配置选项支持多集群部署，并可以在Kubernetes集群外部扩展网格

从2.8版本开始，多群集部署趋于稳定。

Service Mesh接口（SMI）兼容性

通过第三方CRD（CustomResourceDefinition）

本机用于流量拆分和指标，不用于流量访问控制

监控功能

功能丰富

功能丰富

追踪支持

Jaeger, Zipkin

支持OpenCensus的所有后端

路由功能

各种负载均衡算法（Round-Robin, Random Least Connection）， 支持基于百分比的流量拆分，支持基于报头和路径的流量拆分

支持EWMA负载均衡算法，通过SNI支持基于百分比的流量拆分

弹性

断路器，重试和超时，故障注入，延迟注入

无断路器，无延迟注入支持

安全

mTLS支持所有协议，可以使用外部CA证书/密钥，支持授权规则。

除TCP之外，还支持mTLS，可以使用外部CA /密钥，但尚不支持授权规则

性能

在最新的1.6版本中，Istio的资源占用量越来越大，延迟得到了改善。

Linkerd的设计非常轻巧，根据某些第三方基准测试，它比Istio快3-5倍。

企业支援

不适用于OSS版本。如果您将Google的GKE与Istio结合使用，或者将Red Hat OpenShift与Istio作为Service Mesh使用，则可能会得到各个供应商的支持。

开发了Linkerd OSS版本的Buoyant提供了完整的企业级工程，支持和培训

Service Mesh的未来

虽然Service Mesh存在一些问题，但是这丝毫不影响Service Mesh的发展。比如Istio，每个版本功能都在演进：

1）逐步增强对VM的支持

2）恢复单体设计，降低部署和维护的复杂度

3）自动管理证书

4）提供一系列debug工具

5）envoy支持wasm扩展

6）envoy支持 delta xds，降低推送配置的大小

7）通过ebpf降低proxy带来的性能延迟

Service Mesh正处于快速发展中，相信在云原生的时代里，Service Mesh作为一种非侵入的微服务框架，一定大有作为。