ServiceMesh的前世今生

栏目:云苍穹知识作者:金蝶来源:金蝶云社区发布:2024-09-23浏览:1

ServiceMesh的前世今生

背景

  在谈ServiceMesh前,先来看看微服务架构是如何演进的。如下图:

                                               (图1)

单体架构:所有功能放在一个项目工程,虽然实现很快,但维护成本很高,扩展困难。


垂直架构:将原来的大项目拆成一个个单体结构的项目。项目的复杂度有所降低,且单个项目的技术可单独发展,但项目之间的接口比较单一(多为数据库同步),扩展仍困难。


SOA架构:将重复公共的功能抽取为组件,以服务的方式给各个系统提供服务,企业服务总线(ESB)实现了不同服务之间的通信与整合。提高了开发效率 以及系统的可重用性,可维护性。但是服务之间的接口协议不固定,繁琐,系统与服务的边界也比较模糊,不利于维护。


微服务架构:服务拆分的更细,可以更精确的针对服务做方案,服务之间一般采取Restful进行通讯,比中心化的企业服务总线(ESB)更容易维护,产品迭代周期短,能快速适应和验证市场。但同时,微服务的数量变多,服务治理的成本陡增,给团队带来很大挑战。


服务治理的几个阶段

  微服务架构带来的好处确实是很多,但服务之间高度依靠网络通信来进行基本的数据交换。而众所周知,网络通信的特点是不可靠,不安全,带宽有限,网络有延迟,传输也有成本。微服务架构带来趋势的必然是服务数量的大幅度上升(如图2),那么这么多微服务,服务间的网络通信该如何管理?

        (图2)

  服务间的网络通信管理,也即我们常说的服务治理,通常意义上包含 服务注册/发现,服务路由,弹性能力(如熔断,限流,超时),访问安全(如https,网络策略),可观察性(如监控,日志,调用链追踪)等。服务治理也经历了几个阶段。


第一阶段:控制逻辑和业务逻辑高度耦合

特点:控制服务间通信的逻辑 和业务本身的逻辑耦合在一起,且各个服务都需要重复实现。


第二阶段:控制逻辑抽取成公共库

特点:控制服务间通信的逻辑单独抽取成一个公共库,避免了各个服务重复造轮子,但这个公共库还是和各业务逻辑耦合在一起。


第三阶段:代理模式

特点:控制逻辑不仅独立出来,而且成为了一个单独的代理。如现在常见的nginx等,自带熔断,限流和安全访问等功能。但都相对比较简单,针对更复杂的场景难以支持,如流量镜像,双向https,复杂的灰度等,且这些代理本身又是集中式,与微服务本身推崇的分布式的理念是相违背的。


第四阶段:sidecar模式

特点:控制逻辑不仅成为了一个单独的代理,而且是分布式,每个微服务旁边都会对应一个代理,代理接管了进出该微服务的所有流量。


第五阶段:servicemesh出现

  servicemesh的出现也经历了2个阶段,第一代只有数据面,也就是只有代理(典型的如envoy,linkerd)。第二代servicemesh在数据面的基础上,加入了控制面,典型的如istio,控制面用来下发规则给数据面,数据面用来干具体的活(istio里面的数据面就是envoy)。


servicemesh定义

  根据Linkerd CEO William Morgan定义,Service Mesh是用于处理服务间通信的基础设施层。

通俗一点讲,可以将它比作是应用程序或者说微服务间的 TCP/IP,负责服务之间的网络调用、限流、熔断和监控等等。


servicemesh主要功能

包括4部分:流量控制,策略,网络安全,可观察性。

流量控制:路由,流量转移,超时重试,熔断,故障注入,流量镜像。

策略:限流,黑白名单。

网络安全:授权和身份认证。

可观察性:监控指标,日志,调用链追踪。

详细的描述,以后会在istio技术分享中逐一介绍。


servicemesh与k8s的关系

kubernetes

  • 解决容器编排与调度问题

  • 本质上是管理应用的生命周期(调度器)

  • 给与servicemesh支持和帮助


servicemesh

  • 解决服务间网络通信问题

  • 本质上是管理服务网络通信(通过代理)

  • 是对kubernetes网络功能方面的扩展和延伸


  从上面可以看出,servicemesh是k8s的网络功能的扩展和延伸,和k8s达到了天人合一的境界,是谷歌力推的最新的服务治理方式。


servicemesh与api网关的关系

apigw

  • 处理南北向流量

  • 暴露服务到外部

  • 将外部服务映射到内部资源


servicemesh

  • 处理东西向流量

  • 管理和处理服务间的网络通信

  • 专注于代理内部服务


从上图可以看出,apigw和servicemesh的应用场景和侧重点都是不同的。


servicemesh产品发展史

  上面介绍了servicemsh的背景,定义,主要特性以及和k8s,api网关的关系,相信大家对servicemesh的整体有了个大概的了解。既然servicemesh号称是下一代微服务架构,那么基于servicemesh的产品有哪些呢?

  servicemesh自从2016年以来,各大公司相继发布了servicemesh的产品,其中以2018年谷歌,ibm,lyft联合发布的istio最为出名,而且现在也已成为了事实的标准。


  国内的servicemesh产品也有磅礴的发展,其中以蚂蚁金服公司自己研发的数据面MOSN为典型代表,且都有自己的实践和落地。

  公有云提供的的servicemesh服务,主流厂商都已经推出了相应产品且已商用化。

公司服务网格产品服务网格产品发布时间
awsAWS App Mesh全自研2019.10

谷歌云

Traffic Director、Anthos Service Mesh

支持托管和非托管

2019.3

阿里云服务网格(ASM)托管控制面2020.7
华为云应用服务网格(ASM)支持托管和非托管2020.7
腾讯云腾讯云服务网格(TCM)支持托管和非托管2020.10


结束语

   servicemesh以其优异的跨语言,服务治理逻辑与业务逻辑彻底解耦,且是分布式的服务治理思想,深受欢迎,国内外互联网巨头公司都在第一时间之内进行了布局并试图抢占技术制高点。各大云厂商也都推出了相应的servicemesh服务,国内的各大互联网公司也在具体业务应用上进行了落地和实践。从上所知,servicemesh成为下一代微服务架构的趋势已经非常明显。对于servicemesh,今天,您,心动了吗?


ServiceMesh的前世今生

背景 在谈ServiceMesh前,先来看看微服务架构是如何演进的。如下图: ...
点击下载文档
确认删除?
回到顶部
客服QQ
  • 客服QQ点击这里给我发消息