汇付天下钛客头条 | 技术界的瞩目C位 硬核实力不服不行！

相信读到这篇文章的小伙伴们都曾或多或少地听说过Service Mesh，其火热程度不言而喻，在各种技术分享大会上，好多大咖都将Service Mesh誉为“下一代的微服务架构”。

那么，Service Mesh究竟是“何方神圣”？为什么可以获得那么多技术大咖的点赞加持？Service Mesh究竟又能带给我们什么？

今天的这篇文章就将为大家揭开它的神秘面纱，带大家来初步见识一下这位技术界的网红C位担当——Service Mesh。

什么是Service Mesh？

首先让我们了解一下这个名字的由来，在中文里，Service Mesh通常被翻译为“服务网格”，对于“服务”这个词大家都比较熟悉，基本上一切商业活动都离不开“服务”。

企业对外提供的商品可以称为服务（SaaS），企业内部系统所依赖的基础运行平台也可以称为服务（PaaS），甚至企业内的基础设施现在也都被叫做了服务（IaaS）。可以说“一切皆可为服务”。

随着职能分工变得越来越细，所有软件功能的实现基本都是由一系列服务组合而成的。既然理解了一切都是服务，那“网格”这个词也就非常好理解了，所有这些服务天然形成了一个网状结构，“服务网格”可以说是对这种结构一个非常形象的描述。

然而并不是所有网状结构的服务都能被称作“服务网格”，“服务网格”架构还定义了一种特殊的服务部署模式，它要求在每个服务的边缘都部署一个边车服务（Sidecar），这个边车服务相当于一个透明代理，所有的进出流量都通过这个透明代理来转发。在解释什么是透明代理之前，我们先来看看下面这张图：

（图片来源：philcalcado.com）

在这张图中，绿色的方块代表服务，而蓝色方块就是所谓的“透明代理”。在没有这些代理之前，我们不难想象，所有的网络流量都是在绿色的方块间流转，而有了Service Mesh之后，所有的网络流量都是先经过蓝色的透明代理再流转到真正的绿色服务中。

然而所有的流量流转路径和走向都没有变化，也就是对于绿色的服务来说，它们调用服务获得的响应与原来是一模一样的，它们就好像是在打电话时被窃听了一样，是感知不到透明代理的存在的——这也是为什么我们把这些代理称作“透明”代理的原因。

这些蓝色的透明代理通常又被称为“Sidecar（边车）”，边车的原义是指加装在两轮摩托车边上的单轮座椅，而将“边车”这个词应用到服务网格中，则非常形象地说明了透明代理与服务之间的一一对应的关系。同时也说明了透明代理是服务的一个辅助设备，业务的核心仍然是服务本身。

这些蓝色的透明代理所组成的这个抽象平面被称为“数据平面”，数据平面所运行的逻辑通常比较简单，从而能够保证较高的性能，同时数据平面的网络流转方式必须可配置，才能满足复杂的服务治理需求。

因此，在Service Mesh中又提出了控制平面的概念，所有的规则配置都在控制平面完成，数据平面则更多在于执行。如下图所示，控制平面控制了所有数据平面的网络流转。

（图片来源：philcalcado.com）

可以说，应用Service Mesh与否，几乎已成为判断公司是否站在技术前沿的标准之一。Service Mesh就宛若是如今技术界的“网红C位”！

为什么Service Mesh如此受推崇，让我们先来看看应用Service Mesh后，会带来哪些不同——

首先，我们来看看在没有Service Mesh时，是怎么来管理服务的。

我们假设这里说的服务都是分布式部署的，也就是说有多个服务的实例提供同一种服务：如下图所示，服务A有3个实例，当它需要调用服务B的时候会随机（或根据一定的策略）选择服务B的三个实例中的任意一个去调用。

另外，当我们给服务B添加或者减少一个服务实例时，应当去通知服务A所有的变化以确保服务A能正确地调用B提供的服务，这个过程被称为服务注册与发现。服务的注册与发现和刚刚提到的服务选择策略的管理被统称为“服务治理”。

在分布式系统中，服务治理是非常重要的一个环节，在Service Mesh出现之前通常有两种方式来实现服务治理功能——

 集中式服务治理  

集中式的服务治理引入一个服务治理中间件，由它来统一管理所要调用的服务，上层服务只需与该中间件交互即可。如下图所示：

常见的API网关、负载均衡设备集群、企业服务总线（Enterprise Service Bus, ESB）等使用的就是类似这样的模式。集中式的服务治理方式能很好地将业务与服务治理功能解耦，但它有几点重要不足，分别为配置的复杂性、易产生单点故障及性能的低下。

 集成式服务治理  

与集中式服务治理不同，集成式服务治理以客户端的形式将服务治理的功能集成到了每个服务的实例中，如下图所示：

其中服务端治理服务端主要提供服务注册功能，而服务治理客户端主要实现服务路由的选择。传统的RPC服务采用的就是这种模式。集成式服务治理的优点是高性能，以及能够实现一些复杂的服务治理逻辑，它的主要缺点是客户端与服务高度集成导致升级困难，客户端开发语言与应用服务必须保持一致导致跨语言的调用较为困难等。

 Service Mesh  

上文有过介绍，Service Mesh是通过透明代理的方式来提供服务治理的功能，可以看作是集中式和集成式两种模式的结合。因此，Service Mesh既保持了之前两种模式的优点，又避免了它们的缺点，做到了鱼与熊掌兼得的效果。

总结来看，Service Mesh有三大优势：

1. 使用门槛低，上手简单。

就像之前介绍的那样，透明代理的引入对于业务应用来说完全是透明的，接入Service Mesh甚至不用业务应用改一行代码。

2. 便于运维，支持更大规模集群。

在RPC时代常常会产生由于升级成本高而导致客户端版本参差不齐的现象，对于维护各个客户端版本和升级来说耗时巨大，而Service Mesh完全没有这个问题，可以做到无感统一升级，所有应用都能享受到最新版本的功能。

3. 支持可跨语言调用，可融合多种技术体系。

由于Service Mesh是以代理的形式提供服务，因此做到了与开发语言解耦，任何技术体系下的应用都能接入Service Mesh，融合在一起提供完整的企业服务。

当然，Service Mesh也不是没有缺点，它的主要缺点是资源消耗可能更多以及在性能上有所损失。

然而，随着云计算的发展，资源编排越来越智能，虽然Service Mesh的代理数量增加了但总体计算量并没有增加，因此资源消耗的问题并不突出。至于性能上的损失，主要是相对集成模式来说的，相比集中模式来说，这次网络开销是在本地完成的，在性能上可能还优于集中模式。

与此同时，随着Service Mesh渐渐成为了主流，目前已经有许多项目组（如Cilium项目等）正在研究如何优化本地的网络调用以提高整体性能。并且即使在性能没有优化的情况下，Service Mesh的整体性能也已经能够满足大部分大型企业的要求了。这样看起来，Service Mesh走上服务治理的C位可谓当之无愧！

说回到Service Mesh的起源，其源于Buoyant公司创始人、前Twitter基础设施工程师William Morgan博士在2016年首次提出Service Mesh的概念，Buoyant公司的Linkerd项目，即专注于打造企业生产可用的Service Mesh服务，具备使用简单、性能突出等特点。

这一概念被提出后不久，Google联合IBM共同推出基于云原生服务代理Envoy的Service Mesh实现Istio。

这之后，各大厂商纷纷跟进并推动了这一架构的演进，一些厂商采取了自研的方案，如我们所熟知的华为、美团、唯品会等，也有部分厂商采用了基于Istio、并对其进行部分改造的方法，如蚂蚁金服、腾讯云等。

2019年年报数据显示，汇付天下在科技研发投入上同比增长32%，超过3亿元，公司研发人员占比提升至54%。在数字化转型的战略下，汇付天下业内首家全面应用云原生技术，现已实现弹性可扩展的系统支撑，系统稳定性达到99.995%，日交易承载能力达1亿笔。产品100%成功上线，80%实现自动化测试，研发效率大幅提升。

目前，基于对市场上各类Service Mesh实现方式的大量调研，汇付天下也已开始孵化出符合自身业务需求的Service Mesh方案。

本文由拉卡拉POS机办理中心整理，未经许可不允许任何形式的转载，本文唯一地址:https://www.zipos.cn/saolian/951.html，其他地址不完整的均为抄袭！POS机申请办理请添加客服微信号：