第一部分 基础篇

第1章 Service Mesh简介

在正式介绍Linkerd之前，我们将通过一章的内容了解一下Service Mesh的基本概念：它是如何产生的？能帮助解决微服务架构中什么样的问题？业界已经提供哪些Service Mesh产品？基于本章的介绍，有助于读者理解后续章节内容。

1.1 微服务架构面临的一些挑战

近年来，微服务架构随着云计算技术的快速发展成为许多IT公司开发人员非常追捧和认可的一种架构设计，最主要的原因是微服务架构解决或避免了传统单体架构所面临的一些问题，例如下面这些。

❑ 单体应用代码库庞大，不易于理解和修改，尤其是对新人显得更加明显。

❑ 持续部署困难，由于单体应用各组件间依赖性强，只要其中任何一个组件发生更改，将重新部署整个应用，而频繁的部署将增加服务宕机的风险，因此频繁地进行部署几乎不可能。

❑ 扩展应用困难，单体应用只能从一个维度进行扩展，即很容易通过增加实例副本提供处理能力。另一方面，单体应用各个组件对资源的使用情况需求不同，一些是CPU密集型，另一些是内存密集型，但是不能独立地扩展单个组件。

❑ 阻碍快速开发，随着公司业务的发展，单体服务框架变得更加庞大，更多的部门将会参与系统的开发，但是各个部门又不能独立开发、维护相应的模块，即使其中一个部门完成相应的更新，仍然不能上线，因此需要花费更多时间在部门间协调和统一。还有，需要增加新的功能时，单体应用最初的设计限制开发人员灵活选择开发语言、工具等，导致新功能上线慢。

❑ 迫使开发人员长期专注于一种技术栈，由于单体应用本身设计的原因，后期引入新的技术栈需要遵循最开始的设计，因此存在非常大的局限性、挑战性，否则可能需要重写整个框架。

随着业务的发展，传统单体应用的问题越来越严重，解决和避免这些问题非常必要，而微服务架构正好可以很好地解决或避免部分问题，因此，开发人员也非常乐于拥抱微服务框架，逐渐将传统的单体应用拆分成几十或者几百，甚至更多的微服务，如图1-1所示。还有，云计算技术的快速发展比如容器技术使得开发和落地微服务更加便捷，也使得微服务框架成为业界非常热门的开发框架。

我们暂且不管拆分过程的复杂性及长期性，而重点考虑拆分后由多个微服务构建的复杂系统，系统中各个微服务之间彼此通过网络进行通信，很好地解决了上述问题。但是，微服务是一枚万能银弹吗？拆分成微服务后就万事大吉了吗？很显然，这是不可能的。可以这么说，微服务架构一方面收之桑榆，另一方面又失之东隅，优点与缺点、得与失总是伴随而生。其中最大的挑战便是如何以标准化的方式管理微服务以及如何保证复杂网络环境中微服务间的可靠通信，确保整个系统的最大可用性，提供尽可能高的SLA。其实业界已有很多关于如何在产线运行微服务的经验分享，各家可能大同小异，相差不会太大。下面我们看Uber公司以什么样的方式管理运行在产线上处理成千上万请求的微服务，关于Uber的微服务管理经验，Susan J. Fowler在他的著作《Microservices in Production》中有详细的描述，我们将其总结为七点原则。

❑ 稳定性（Stability）：

● 稳定的部署周期

● 稳定的部署流程

● 稳定的引入和下架应用流程

❑ 可靠性（Reliability）：

● 部署过程可靠

● 尽可能规划、减缓及保护依赖关系的失败

● 可靠的服务路由和发现机制

❑ 扩展性（Scalability）：

● 尽可能地量化系统各种运行时的指标

● 确定系统资源瓶颈和需求

● 精心规划系统的容量计划

● 可扩展的流量处理

● 依赖组件扩展管理

● 可扩展的后端数据存储

❑ 容错及灾难预防（Fault Tolerance and Catastrophe Preparedness）：

● 清楚地确定和规划系统潜在灾难和故障场景

● 避免系统单点故障

● 完善的故障检测及修复流程

● 通过尽可能多、全面的代码测试、负载测试及混沌测试（Chaos Testing）确保服务具有极强的弹性能力

● 谨慎管理系统流量，以备故障发生

● 快速有效地处理线上故障及宕机事件

❑ 性能（Performance）：

● 针对可用性定义合适的SLA

● 服务能快速有效地处理各种任务

● 充分利用系统资源

❑ 监控（Monitoring）：

● 快速准确地记录和跟踪系统运行状态

● 设计良好的仪表盘有助于理解系统运行状态及更加准确地反映服务的健康状态

● 配备有效的、完善的、可操作的运维手册处理各种线上报警

● 实施和维护可执行的oncall轮换机制

❑ 文档（Documentation）

● 维护完整、有效的文档系统，不断积累和更新知识库

● 根据人员、部门组织文档系统，易于查询及理解

从上面内容可知，在管理产线环境运行成百上千的微服务时，主要利用两种手段，其一是完善的、执行力高的流程，其二是技术手段。两者之中，可能某些方面完善的流程胜于技术手段，为系统服务的高可用性保驾护航，提供坚强的后台支持。关于流程建设，这里不作介绍，因为每个公司对流程的制定千差万别，而技术可能更具有普适性，那么在通过技术手段确保微服务的高可用性时，又有哪些技术手段可以提高微服务的可用性呢？由于拆分后的单体应用变成成百上千的分布在不同计算节点，构成一个庞大的分布式系统，它们之间通过网络进行数据通信。说到实现分布式系统的高可用性时，不得不说L Peter Deutsch在Sun Microsystems工作时提出的关于分布式系统的谬误（https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing）：

❑ 网络是可靠的

❑ 网络零延迟

❑ 网络带宽是无限的

❑ 网络是安全的

❑ 网络拓扑一成不变

❑ 系统只有一个管理员

❑ 传输代价为零

❑ 网络是同质的

因此，在构建分布式系统时，最好尽可能地避免这些对分布式系统的错误认识。虽然清楚地认识这些谬误对构建分布式系统非常重要，但是，诸多原因使得构建一个高可用、弹性的分布式系统仍然非常困难，比如：网络不可靠、不可避免的系统依赖组件失败、用户行为的不可预知等。当然，这并不意味着构建高可用、弹性的分布式系统是不可能的。事实上，业界多年的技术积累及经验总结，已经提出很多有助于提高系统可用性和弹性的通用型技术指南，那就是模式。可以说，模式在软件工程中无处不在。以下是一些在构建分布式软件或者普通软件时的常用模式。

❑ 超时（Timeout）：超时使得如果访问下游服务缓慢或失败时，上游服务应快速失败而不是无限或者长时间等待，以此避免级联故障，隔离故障范围。

❑ 重试（Retry）：重试有效地解决访问服务时发生的间隙性故障，有助于减少服务恢复时间。

❑ 熔断（Circuit Breaker）：熔断机制避免将请求继续发送给已经失败或者不健康的下游服务处理，而是等待它们恢复，避免级联故障。

❑ 健壮性测试（Resiliency Testing）：健壮性测试通过人为的方式向系统注入各种可能的故障，模拟网络故障、延迟、依赖组件故障等，以此提前获得一些未知错误并制定相应的处理方案。

❑ 限速节流（Rate-limiting and Throttling）：限速节流限定服务在固定的时间内只处理一定数量的请求，确保系统有足够的能力优雅地处理其他请求，可避免峰值流量导致系统崩溃，与第三方系统集成时可以提供安全保障。

除此以外，还有许多技术可帮助实现分布式系统的高可用性，例如：

❑ 动态服务发现

❑ 负载均衡

❑ 运行时动态路由

❑ 安全通信

❑ 运行时指标及分布式追踪

最后，强烈推荐大家阅读Susan J. Fowler的著作《Microservices in Production》，其中详细介绍如何在产线运行微服务。

接下来我们来看实现分布式系统的高可用性技术实现是如何演进的。

1.2 技术架构演进

当单体应用拆分为微服务后，新的通信模型如图1-2所示。

如图1-2所示，每个微服务由2部分构成。

❑ 业务逻辑：定义如何处理应用业务逻辑。

❑ 网络功能：网络功能部分主要负责服务间的通信，包括上述列出的构建分布式高可用的技术实现，如超时、重试、服务发现、负载均衡等，由于它基于下层网络协议栈实现，因此被称作网络功能。

相对于传统的单体应用，网络功能部分可以通过一个中心化的组件来统一实现或者直接嵌入到业务逻辑中，但是在微服务架构中，服务的粒度变得更小，为了实现它们之间的可靠通信，开发人员为每个微服务实现网络功能比实现业务逻辑花费的时间和精力可能更多。最初，开发人员把上述的一些技术手段如负载均衡、服务发现或熔断等跟业务逻辑代码一起封装起来，使得应用具有处理网络弹性的能力。

图1-3中的这种方案非常简单，易于实现，但从软件设计的角度，大家很快发现它有以下缺点。

❑ 耦合性很高，每个应用都需封装负载均衡、服务发现、安全通信以及分布式追踪等功能。

❑ 灵活性差，复用率低下，不同的应用需要重复实现。

❑ 管理复杂，当其中一项如负载均衡逻辑发生变化，需要更新所有服务。

❑ 可运维性低，所有组件均封装在业务逻辑代码中，不能作为一个独立运维对象。

❑ 对开发人员能力要求很高。

关于上述方案，应用已具有处理网络弹性能力，及动态运行环境中处理服务发现、负载均衡等能力，向提供高可用、高稳定性、高SLA应用更进一步，与此同时，你也看到这种模式具有很多缺点。为此，我们是否可以考虑将应用处理服务发现、负载均衡、分布式追踪、安全通信等设计为一个公用库呢？这样使得应用与这些功能具有更低的耦合性，而且更加灵活、提高利用率及运维性，更主要的是开发人员只需要关注公用库，而不是自己实现，更多地关注业务逻辑，从而降低开发人员的负担。这方面很多公司如Twitter、Facebook等走在业界前列，像Twitter提供的可扩展RPC库Finagle、Facebook的C++HTTP框架Proxygen、Netflix的各种开发套件，还有如分布式追踪系统Zipkin，这些库和开发套件的出现大量减少重复实现的工作。对于这种模式如图1-4所示。

虽然相对前一种解决方案，新的方案在耦合性、灵活性、利用率等方面有很大的提升，但是仍然有些不足之处。

❑ 如果将类似Finagle、 Proxygen或者Zipkin的库集成现有的系统中，仍然需要花费大量的时间、人力将其集成到现有生态圈，甚至需要调整现有应用的代码。

❑ 缺乏多语言支持，由于这些库只针对某种语言或者少数几种语言，这使得在一个多技术栈的公司中需要限制开发语言和工具的选择。

❑ 虽然公共库作为一个独立的整体，但在管理复杂性和运维性这些方面仍然有更大的提升空间。

❑ 公共库并不能完全使得开发人员只关注业务代码逻辑，仍然需要对公共库有很深的认识。

显然，没有任何方案能一劳永逸地解决所有的问题，而各种问题驱使技术人员不断地向前演进、发展，探索新的解决方法。那么，针对现在所面临的问题，我们有更好的解决方案吗？答案是肯定的。相信大家对OSI七层模型应该不陌生，OSI定义了开放系统的层次结构、层次之间的相互关系以及各层所包括的可能的任务，上层并不需要对底层具体功能有详细的了解，只需按照定义的准则协调工作即可。因此，我们也可参照OSI七层模型将公用库设计为位于网络栈和应用业务逻辑之间的独立层，即透明网络代理，新的独立层完全从业务逻辑中抽离，作为独立的运行单元，与业务不再直接紧密关联。通过在独立层的透明网络代理上实现负载均衡、服务发现、熔断、运行时动态路由等功能，该透明代理在业界有一个非常新颖时髦的名字：Service Mesh。率先使用这个Buzzword的产品恐怕非Buoyant的Linkerd（https://linkerd.io/）莫属了，随后Lyft也发布了他们的Service Mesh实现Envoy（https://github.com/envoyproxy/envoy），之后Istio（https://istio.io/）也迎面赶上，成为Service Mesh领域非常热门的一个项目。新的模式如图1-5所示。

在这种方案中，Service Mesh作为独立运行层，它很好地解决了上述所面临的挑战，使应用具备处理网络弹性逻辑和提供可靠交互请求的能力。它使得耦合性更低、灵活性更强，跟现有环境的集成时间和人力代价更小，也提供多语言支持、多协议支持，运维和管理成本更低。最主要的是开发人员只需关注业务代码逻辑，而不需要关注业务代码以外的其他功能，即Service Mesh对开发人员是透明的。

1.3 什么是Service Mesh

说到Service Mesh，我们不得不提到Service Mesh的发起人、先驱者，Buoyant公司的CEO William Morgan，他对Service Mesh的定义如下。

❑ 专用基础设施层：独立的运行单元。

❑ 包括数据平面和控制平面：数据平面负责交付应用请求，控制平面控制服务如何通信。

❑ 轻量级透明代理：实现形式为轻量级网络代理。

❑ 处理服务间通信：主要目的是实现复杂网络中服务间通信。

❑ 可靠地交付服务请求：提供网络弹性机制，确保可靠交付请求。

❑ 与服务部署一起，但服务感知不到：尽管跟应用部署在一起，但对应用是透明的。

图1-6更加清晰地告诉我们Service Mesh控制层和数据层在微服务架构中所处位置、服务间通信模式以及提供的各种功能。

1.4 Service Mesh的功能

Service Mesh作为透明代理，它可以运行在任何基础设施环境，而且跟应用非常靠近，那么，Service Mesh能做什么呢？

❑ 负载均衡：运行环境中微服务实例通常处于动态变化状态，而且经常可能出现个别实例不能正常提供服务、处理能力减弱、卡顿等现象。但由于所有请求对Service Mesh来说是可见的，因此可以通过提供高级负载均衡算法来实现更加智能、高效的流量分发，降低延时，提高可靠性。

❑ 服务发现：以微服务模式运行的应用变更非常频繁，应用实例的频繁增加或减少带来的问题就是如何精确地发现新增实例以及避免将请求发送给已不存在的实例变得更加复杂。Service Mesh可以提供简单、统一、平台无关的多种服务发现机制，如基于DNS、K/V键值对存储的服务发现机制。

❑ 熔断：动态的环境中服务实例中断或者不健康导致服务中断可能会经常发生，这就要求应用或其他工具具有快速监测并从负载均衡池中移除不提供服务实例的能力，这种能力也称熔断，以此使得应用无需消耗更多不必要的资源不断地尝试，而是快速失败或者降级，甚至这样可避免一些潜在的关联性错误。而Service Mesh可以很容易实现基于请求和连接级别的熔断机制。

❑ 动态路由：随着服务提供商以提供高稳定性、高可用性以及高SLA服务为主要目标，为了实现所述目标，出现各种应用部署策略尽可能从技术手段达到无服务中断部署，以此避免变更导致服务的中断和稳定性降低，例如Blue/Green部署和Canary部署，但是实现这些高级部署策略通常非常困难。关于应用部署策略，可参考Etienne Tremel（https://thenewstack.io/deployment-strategies/）的文章，他对各种部署策略做了详细的比较。而如果运维人员可以轻松地将应用流量从staging环境切换到产线环境，一个版本切换到另外一个版本，或者从一个数据中心到另外一个数据中心进行动态切换，甚至可以通过一个中心控制层控制多少比例的流量被切换。那么Service Mesh提供的动态路由机制和特定的部署策略如Blue/Green部署结合起来，实现上述目标将更加容易。

❑ 安全通信：无论何时，安全在整个公司、业务系统中都有着举足轻重的位置，也是非常难以实现和控制的部分。而微服务环境中，不同的服务实例间通信变得更加复杂，那么如何保证这些通信是在安全、有授权的情况下进行就非常重要。通过将安全机制如TLS加解密和授权实现在Service Mesh上，不仅可以避免在不同应用上的重复实现，而且很容易在整个基础设施层更新安全机制，甚至无需对应用做任何操作。

❑ 多语言支持：由于Service Mesh作为独立运行的透明代理，很容易支持多语言。

❑ 多协议支持：同多语言支持一样，实现多协议支持也非常容易。

❑ 指标和分布式追踪：Service Mesh对整个基础设施层的可见性使得它不仅可以暴露单个服务的运行指标，而且可以暴露整个集群的运行指标。

❑ 重试和最后期限：Service Mesh的重试功能避免将其嵌入到业务代码，同时最后期限使得应用允许一个请求的最长生命周期，而不是无休止的重试。

对这些功能，概括起来，即Service Mesh使得微服务具有下列性能。

❑ 可见性（visiblity）：运行时指标、分布式跟踪。

❑ 可管理性（manageablity）：服务发现、负载均衡、运行时动态路由。

❑ 健壮性（resilience）：超时重试、请求最后期限、熔断机制。

❑ 安全性（security）：服务间访问控制、TLS加密通信。

1.5 业界Service Mesh产品

当前，业界主要有以下Service Mesh相关产品。

1.5.1 Linkerd

Linkerd是Buoyant公司2016年率先开源的高性能网络代理程序，是业界的第一款Service Mesh产品，甚至可以说Linkerd的诞生即Service Mesh时代的开始，其引领后来Service Mesh的快速发展。其主要用于解决分布式环境中服务之间通信面临的一些问题，比如网络不可靠、不安全、延迟丢包等问题。Linkerd使用Scala语言编写，运行于JVM，底层基于Twitter的Finagle库，并对其做相应的扩展。最主要的是Linkerd具有快速、轻量级、高性能等特点，每秒以最小的时延及负载处理万级请求，易于水平扩展，经过产线测试及验证，可运行任何平台的产线级Service Mesh工具。Linkerd除了具有上述所阐述的Service Mesh的功能外，还具有下列功能。

❑ 支持多平台，可运行于多种平台，比如Kubernetes、DC/OS、Docker甚至虚拟机或者物理机。

❑ 无缝集成多种服务发现工具。

❑ 支持多协议，如gRPC、HTTP/2、HTTP/1.x，甚至可通过linkerd-tcp支持TCP协议。

❑ 支持与第三方分布式追踪系统Zipkin。

❑ 灵活性、扩展性高，可通过其提供的接口开发自定义插件。

根据上述关于Service Mesh的定义，Service Mesh由数据平面和控制平面构成，事实上，Linkerd本身是数据平面，负责将数据路由到目标服务，同时保证数据在分布式环境中传输是安全、可靠、快速的。另外，Linkerd还包括控制平面组件Namerd，通过控制平面Namerd实现中心化管理和存储路由规则、中心化管理服务发现配置、支持运行时动态路由以及暴露Namerd API管理接口。

除此之外，据不完全统计，超过50家公司在产线使用Linkerd，应该是目前产线使用最多的Service Mesh产品。还有，Linkerd是CNCF官方支持的项目之一。

1.5.2 Envoy

同Linkerd一样，Envoy也是一款高性能的网络代理程序，于2016年10月份由Lyft公司开源，为云原生应用而设计，可作为边界入口，处理外部流量，当然，也作为内部服务间通信代理，实现服务间可靠通信。Envoy的实现借鉴现有产线级代理及负载均衡器，如Nginx、HAProxy、硬件负载均衡器及云负载均衡器的实践经验，同时基于C++编写及Lyft公司产线实践证明，Envoy性能非常优秀、稳定。Envoy既可用作独立代理层运行，也可作为Service Mesh架构中数据平面层，因此通常Envoy跟服务运行在一起，将应用的网络功能抽象化，Envoy提供通用网络功能，实现平台及语言无关。作为Service Mesh工具，Envoy除了支持上述Service Mesh的功能外，还有下列功能。

❑ 大规模负载下，Envoy保证P99延时非常低。

❑ 优先支持HTTP/2和gRPC，同时支持Websocket和TCP代理。

❑ API驱动的配置管理方式，支持动态管理、更新配置以及无连接和请求丢失的热重启功能。

❑ L3/L4层过滤器形成Envoy核心的连接管理功能。

❑ 通过与多种指标收集工具及分布式追踪系统集成，实现运行时指标收集，分布式追踪，提供整个系统及服务的运行时可见性。

❑ 内存资源使用率低，sidecar是Envoy最常用的部署模式。

目前，Envoy已经在Lyft及其他公司如腾讯、Stripe、Twilio等运行于产线，还有，Envoy社区非常活跃，你可从社区及一些其他厂商，比如Turbine Labs（https://www.turbinelabs.io/）获得商业支持。另外，Envoy也被用于实现API Gateway如Ambassador（https://www.getambassador.io/）及Kubernetes的Ingress Controller如Contour（https://github.com/heptio/contour）。当然，基于Envoy实现的另一款Service Mesh工具Istio可能更广为人知。而且Envoy也是CNCF官方支持的项目之一。

1.5.3 Istio

根据Istio的官方介绍，Istio为一款开源的为微服务提供服务间连接、管理以及安全保障的平台软件，支持运行在Kubernetes、Mesos等容器管理工具，但不限于Kubernetes、Mesos，其底层依赖于Envoy。Istio提供一种简单的方法实现服务间的负载均衡、服务间认证、监控等功能，而且无需应用层代码调整。其控制平面由Mixer、Pilot及Citadel组成，数据平面由Envoy实现，通常情况下，数据平面代理Envoy以sidecar模式部署，使得所有服务间的网络通信均由Envoy实现，而Istio的控制平面则负责服务间流量管理、安全通信策略等功能。由于其底层是Envoy, Envoy支持的各种功能以及Service Mesh要求的功能Istio均支持，除此之外还有以下功能。

❑ 完善的流量管理机制，如故障注入。

❑ 增强服务间安全保障，如服务身份认证，密钥管理和基于RBAC的访问控制策略。

❑ 支持多平台部署。

相对Linkerd和Envoy, Istio在2017年5月才发布，目前处于快速开发及迭代过程中，很多功能还不是很稳定。在本书定稿时，其最新版本是0.8，但仍然不推荐运行于产线。不过Istio社区非常活跃，而且有Google、IBM、Lyft及其他公司如RedHat的大力支持及推广，相信后期无论是在产品本身性能、稳定性等还是社区生态圈的开发中都会发展得很好。

1.5.4 Conduit

Conduit（https://conduit.io/）于2017年12月发布，作为由Buoyant继Linkerd后赞助的另一个开源项目。Conduit旨在彻底简化用户在Kubernetes使用服务网格的复杂度，提高用户体验，而不是像Linkerd一样针对各种平台进行优化。Conduit的主要目标是轻量级、高性能、安全并且非常容易理解和使用。同Linkerd和Istio, Conduit也包含数据平面和控制平面，其中数据平面由Rust开发，使得Conduit使用极少的内存资源，而控制平面由Go开发。Conduit依然支持Service Mesh要求的功能，而且还包括以下功能。

❑ 超级轻量级及极快的性能，亚毫秒级P99延迟。

❑ 专注于支持Kubernetes平台，提高运行在Kubernetes平台上服务的可靠性、可见性及安全性。

❑ 支持gRPC、HTTP/2和HTTP/1.x请求及所有TCP流量。

Conduit以极简主义架构，以零配置理念为中心，旨在减少用户与Conduit的交互，实现开箱即用。作为Buoyant公司的第二款Service Mesh软件，其设计依据Linkerd在产线的实际使用经验而设计，其设计目标即专为解决用户管理产线环境运行的分布式应用程序所面临的挑战，并以最小复杂性作为设计基础。

Conduit当前版本是0.4.2，正处于不断开发的过程中，目前不建议在产线中使用。

1.5.5 Linkerd、Envoy、Istio及Conduit比较

下面我们对上述各种Service Mesh产品进行简单的比较汇总，见表1-1所示，以便大家更加直观地了解各种产品所支持的功能，选择合适产品实现自己的需求。

1.5.6 我们需要Service Mesh吗

前面我们已经讲述了Service Mesh带来的各种好处，可以解决各种问题。作为下一代微服务的风口，Service Mesh可以使得快速转向微服务或者云原生应用，以一种自然的机制扩展应用负载，解决分布式系统不可避免的部分失败，捕捉分布式系统动态变化，完全解耦于应用等。而Buoyant公司CEO William Morgan在文章《What's a service mesh? And why do I need one? 》（https://blog.buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/）中详细介绍了Service Mesh可以解决什么问题，以及为什么我们需要Service Mesh。因此，我相信Service Mesh将在微服务或者云原生应用领域闯出一番天地。

1.6 总结

本章我们主要通过阐述单体应用的一些问题，从而引申出使用微服务架构解决单体应用所面临的问题。但是，微服务架构并不是万能银弹，并不能解决所有问题。而引入微服务架构后又面临如何确保产线运行的微服务的高可用性、高稳定性以及微服务间的可靠通信问题，其中微服务间的通信问题是微服务架构中最具挑战性的技术问题。在解决服务间通信问题时，从最开始把微服务的网络功能与业务逻辑紧密构建成一体，到将网络功能抽象为公用库，以及到通过独立运行的Service Mesh作为解决服务间通信的主要手段。然后我们介绍了什么是Service Mesh, Service能做什么以及当前业界已有哪些Service Mesh的产品，最后我们对不同Service Mesh产品做了详细的比较，以帮助大家选择适合自己需求的Service Mesh产品。从下一章开始，我们将详细介绍目前业界在产线环境运行最多的Service Mesh产品—Linkerd。