到底谁才需要Service Mesh?

本文是Service Mesh系列第1篇

随着云原生时代的来临，使用微服务架构的朋友们开始听到一个新的技术名词——Service Mesh（现在来说已经不算新了）。

对于一项新技术的学习，总归绕不过两个问题：

• 它是什么？
• 为什么需要它？

本文将围绕这两个问题进行展开，期望对Service Mesh有一个综述性的了解。

最后，引发一个核心的思考：

• 到底谁才需要Service Mesh?

1、什么是ServiceMesh

Service Mesh 在国内被翻译「服务网格」。

目前比较公认的是Buoyant公司的CEO William Morgan给出的定义:

Service Mesh是用于处理服务到服务通信的专用基础架构层。Cloud Native有着复杂的服务拓扑，它负责可靠地传递请求。实际上，Service Mesh通常作为一组轻量级网络代理实现，这些代理与应用程序代码部署在一起，应用程序无感知。

这个定义看起来有些复杂，我们抽取其中的关键词，可能会更加清晰一些：

• 服务到服务通信的基础架构层（定位）
• 在复杂的服务拓扑中，可靠地传递请求（目标）
• 轻量级网络代理实现（实现）
• 应用程序无感知（特点）

从定位、目标、特点来看，我们联想到了什么呢？

没错，就是 TCP/IP协议！

对于云原生下的微服务，Service Mesh就是等同于 TCP/IP协议 一样的 基础设施，负责服务之间的网络调用、路由管理、限流和监控等。

使用了Service Mesh，我们就不需要在应用程序编写时，去关注服务间调用的框架适配、升级等问题，比如Spring Cloud、Dubbo等。就像我们过去编写应用程序时一样，基本不会再关注TCP/IP这一层的问题。

另外，从实现角度来看，这个轻量级的网络代理实现，往往以Sidecar（边车）来称呼（其实就是Proxy）。

我们看下Service Mesh的架构。

（图片来自​​https://philcalcado.com/2017/08/03/pattern_service_mesh.html​​）

「服务网格」分为两个核心部分：

• 数据平面。以Sidecar作为数据平面节点，对应用来说完全透明，所有流量进出都会经过Sidecar。
• 控制平面。集中式的控制平面，提供统一的上层运维入口，所有的Sidecar代理组件通过和控制平面交互进行网络拓扑策略的更新和单机数据的汇报。

2、为什么需要ServiceMesh

一项新技术的产生与引入，必然是为了解决已有的问题。引入Service Mesh的原因，也是为了解决已有微服务框架存在的问题。

为了更深刻地理解Service Mesh解决的问题，我们结合Phil Calçado的文章《Pattern: Service Mesh》，梳理下服务开发模式和Service Mesh技术的演化过程。

1）原始通信时代 1.0

在原始通信时代（TCP协议出现前），服务需要自己处理网络通信所面临的丢包、乱序、重试等一系列Flow Control问题。所以在业务逻辑代码之外，还需要考虑对网络传输问题进行处理。

2）原始通信时代 2.0

为了解决这种业务无关的通过网络传输问题，TCP/IP协议出现，并将这部分Flow Control问题“下沉”到操作系统层面。业务开发不再需要关注网络传输问题，可以专注于业务逻辑开发。

3）微服务的服务治理1.0

随着微服务架构的推广，单体服务逐渐向分布式系统发展，服务间调用变得越来越复杂。

这时候，微服务架构下的 “Flow Control”问题不断出现，包括 服务注册与发现、限流、熔断等等。所以，在业务逻辑代码中，我们又需要开发一些模块解决这类业务无关的问题。

4）微服务的服务治理2.0 —— 微服务框架

为了解决微服务架构下的通用通信问题，各种微服务框架开始出现，Spring cloud、Dubbo等框架都是为了解决这类通用问题而产生。

这些框架通过客户端依赖包的形式，向业务开发屏蔽了包括 服务注册与发现、限流、熔断等等处理逻辑，只需要简单的配置，就能完成比较健壮的微服务架构。

5）微服务的服务治理3.0 —— Service Mesh

微服务框架虽然能解决通用化的服务治理问题，但是在实践中也存在一定的弊端：

• 客户端依赖包的形式，注定了与开发语言强绑定。比较主流的微服务框架基本是Java实现的，如果业务架构中存在其他语言的服务，就比较难享受同样的便利。而针对不同语言都开发一套微服务框架，又是比较高成本且难以维护的事情。被微服务框架限定了开发语言，那显然不是一个好的事情。
• 客户端依赖包的形式，注定了业务需要关注依赖包的升级与适配。一些复杂项目依赖包众多，经常需要处理包冲突的问题，令人头大。同时，框架库的升级也无法对服务透明，必须推进业务去完成，业务开发同学和框架维护同学都很疲惫，sigh~~

如果能像TCP/IP一样，将服务治理“下沉”，彻底与应用服务解耦，那就能解决上述问题了。

所以，以Linkerd，Envoy，NginxMesh为代表的Sidecar模式的Service Mesh产品应运而生。它们将微服务通信的通用问题，服务注册发现、限流、熔断、监控等功能，单独抽出了Sidecar服务，完全接管了服务间的网络通信，并且独立运行，与业务应用彻底解耦。这样就解决了传统客户端模式微服务框架的痛点。

而后，istiol为代表的Service Mesh产品，在Sidecar模式之基础上（istio中的sidecar采用了Envoy），又引入了统一的控制平面，方便进行管理与维护更新。

至此，相信我们对“为什么需要Service Mesh”有了深刻的认识，正是基于上述的演进历史，才有了现在的微服务的服务治理方案Service Mesh。

3、谁需要ServiceMesh

既然Service Mesh这么好，是不是可以无脑上呢？就实际情况来看，不是的。

为什么呢？

Service Mesh在服务治理上，其实并没有更多的“功能性”新特性，比较吸引人的基础特性包括：

• 天然的云原生组件
• 能够独立升级与演进
• 语言无关性

但在一个相对成熟的生产环境中，就目前来看，无论是Dubbo、spring cloud 或者是 自研的微服务框架，都已经相对成熟了，治理能力都比较完善，很少需要去升级或者扩展。

尤其是在服务注册与发现的核心功能不变情况下，一些扩展升级基本不需要所有后端服务都去升级适配。

那么基于“能够独立升级与演进” 的特性就不是那么有说服力了，至少是没有那么大的“业务价值”去驱动的。

那么到底谁才适合引入Service Mesh？

1）云原生基础的新企业（新生产线）

一切从零开始，就基于云原生技术栈的新企业，是非常适合直接引入Service Mesh的 。

云原生天然的服务注册发现、服务治理、云原生可观测，统统围绕Service Mesh展开，业务开发将能更好地专注于业务迭代，而不再需要关注这些业务无关的基础架构的迭代。

当然，一些深入了解云原生技术栈的基础架构维护者是必不可少的。

2）技术栈多样化的成熟企业

那对于一个相对成熟的企业来说，微服务框架、配置中心、全链路追踪系统等，都已经比较成熟，治理能力都比较完善，很少需要去升级或者扩展。

因此，要引入Service Mesh，大部分是基于「技术栈多样化」的需求。

所谓「技术栈多样化」，包括：

• 业务场景特性不同。比如web项目使用Java、后台高性能计算服务使用go/c++、业务请求量波动剧烈的业务使用Faas、前端微服务使用nodejs等。
• 一些特殊的招聘需求。

「技术栈多样化」带来的复杂架构，给传统微服务框架带来了巨大挑战，客户端模式（语言强绑定）的微服务框架已经无法满足这样的复杂需求了。

因此，在云原生架构下，Service Mesh的「语言无关性」的特点，给予了异构应用程序的更多可行性，让用户可以快速的编排出复杂环境、复杂依赖关系的应用程序。

4.小结

本文围绕“什么是Service Mesh”、“为什么需要Service Mesh”两个主题，对ServiceMesh进行了综述性的分享。

最后，根据生产落地中的实际情况，思考了真正适合Service Mesh落地的场景。

期望能对大家有所启发。

文章转载自公众号：阿丸笔记