有了微服务和云原生，为什么还要懂Service-Mesh？

最新推荐文章于 2024-09-16 12:43:04 发布

带你一起提升

最新推荐文章于 2024-09-16 12:43:04 发布

阅读量956

点赞数 9

分类专栏： 2024年程序员面试文章标签：云原生微服务架构

本文链接：https://blog.csdn.net/m0_60388292/article/details/136723539

版权

2024年程序员面试专栏收录该内容

15 篇文章 0 订阅

订阅专栏

因此，对于一些需要通过微服务改造提升业务敏捷性，但没有相应技术能力的中小团队来说，可以借助Service Mesh提供的完善微服务基础设施，加速微服务的落地。

语言无关的通信和链路治理

功能上，Service Mesh并没有提供任何新的特性和能力，Service Mesh提供的所有通信和服务治理能力在Service Mesh之前的技术中均能找到，比如Spring Cloud就实现完善的微服务RPC通信和服务治理支持。Service Mesh改变的是通信和服务治理能力提供的方式，通过将这些能力实现从各语言业务实现中解耦，下沉到基础设施层面，以一种更加通用和标准化的方式提供，屏蔽不同语言、不同平台的差异性，这样不仅有利于通信和服务治理能力的迭代和创新，业务使用的时候也会更加方便。

Service Mesh避免了多语言服务治理上的重复建设，通过Service Mesh语言无关的通信和服务治理能力，助力多语言技术栈的效率提升。

通信和服务治理的标准化

微服务治理层面，Service Mesh是标准化、体系化、无侵入的分布式服务治理平台。
标准化方面，Sidecar成为所有微服务流量通信的约束标准，同时Service Mesh的数据平面和控制平面也通过标准协议进行交互。
体系化方面，从全局考虑，提供多维度立体的微服务可观测能力（Metric、Trace、Logging），并且提供体系化的服务治理能力，比如限流、熔断、安全、灰度等；最为重要的是，Service Mesh通过透明无侵入的方式提供全面的服务治理能力，对微服务本身不会带来直接影响。

通过标准化，带来一致的服务治理体验，减少多业务之间由于服务治理标准不一致带来的沟通和转换成本，提升全局服务治理的效率。

Service Mesh的基本模式

根据Service Mesh的发展历程和使用方式，我们可以把Service Mesh划分为两个模式。

Sidecar模式

在Service Mesh发展早期，Service Mesh以Sidecar的形态存在。Sidecar模式下，网络代理服务在微服务旁边，为微服务提供通信和链路治理功能。因此，数据平面代理服务也经常被简称为Sidecar。

此时，只有数据平面的网络代理服务没有控制平面，和外部基础设施服务的交互直接在网络代理服务中进行。

Sidecar模式可以看作是第一代Service Mesh，代表有早期的Linkerd和Envoy。

第一代Service Mesh通过采用Sidecar模式，通过将通信和通信链路治理功能从微服务中剥离出来，实现了通信基础设施的下沉和服务化，这里也体现了架构解耦的思想，通过解耦减少了微服务的负担。

第二代Service Mesh模式

Sidecar模式的Service Mesh有一个突出的问题，将通信和通信链路治理的所有功能都放到这个代理服务中，导致数据平面代理很重，并且由于承载了太多的特性和功能，使得数据平面代理的更新和修改特别频繁，频繁的更新和升级会导致代理服务出问题的概率增大，影响代理服务的稳定性。同时，Service Mesh模式下，数据平面代理承载了微服务通信的全部流量，对稳定性要求极高，这个服务的任何故障都会对整个系统的稳定性产生很大的影响。为了解决上述频繁升级和稳定性之间的矛盾，将策略和配置决策逻辑从代理服务中脱离出来，形成了独立的控制平面，这就是第二代Service Mesh。

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。