架构演进的两大方向,一个是 Serverless,另一个是什么?

阅读数:548 2019 年 11 月 24 日 23:24

架构演进的两大方向,一个是Serverless,另一个是什么?

在《沉寂多年,无服务器爆发,其硬核是什么?》一文中,我们就什么是无服务器技术,它是如何发展的,它的优点、缺点是什么,对企业的价值在哪里进行了梳理。本文讲讲 Service Mesh。在架构领域,Service Mesh 和 Serverless 一样,是非常重要的一个方向。
这么说吧,掌握了 Service Mesh,你就选择了一条未来技术框架的道路。至于这条道路会怎么发展,还要再观察。这篇文章将解释什么是 Service Mesh,为什么需要 Service Mesh,以及 Service Mesh 的现状如何。

初识 Service Mesh

Service Mesh 很新,最早在 2016 年 9 月 29 日由开发 Linkerd 的 Buoyant 公司提出。

时间回到 2016 年 10 月,Alex Leong 开始在 Buoyant 公司的官方博客中连载一系列关于“A Service Mesh for Kubernetes”的文章。

随着 2017 年 Linkerd 加入 CNCF,Service Mesh 开始大规模出现在各个技术论坛上,Service Mesh 在国内被翻译为“服务网格” 。

那么到底什么是 Service Mesh 呢?目前比较公认的定义是 Buoyant 的 CEO William Morgan 在博客中给出的具体描述,如下:

架构演进的两大方向,一个是Serverless,另一个是什么?架构演进的两大方向,一个是Serverless,另一个是什么?

现在,Service Mesh 逐步发展为一个独立的基础设施层。
在 Cloud Native 架构下,单个应用程序可能由数百个服务组成;每个服务可能有数千个实例;并且这些实例中的每一个实例都可能处于不断变化的状态,因为它们是由诸如 Kubernetes 之类的资源调度系统动态调度的。这个世界中的服务通信不仅非常复杂,而且是运行时的普遍行为之一,管理它对于确保端到端的性能和可靠性至关重要。

Sidecar 的比喻从何而来?

业内也有类似“Sidecar”的说法。这个概念很形象,就是我们以前在战争影片中看到的那种挎斗车。

在模式库中,Sidecar 被这样描述:

将应用程序的组件部署到单独的进程或容器中以提供隔离和封装。这种模式还可以使应用程序由异构组件和技术组成。

这种模式被命名为 Sidecar,因为它类似于连接到摩托车的辅助车。在该模式中,辅助车被附加到父应用程序并为应用程序提供支持功能。辅助车也与父应用程序共享相同的生命周期,与父进程一起被创建和推出。

解释了这么多,一句话来说的话,那就是:Service Mesh 帮助应用程序在海量服务、复杂的架构和网络中建立稳定的通信机制,业务所有的流量都转发到 Service Mesh 的代理服务中。

不仅如此,Service Mesh 还承担了微服务框架所有的功能,包括服务注册发现、负载均衡、熔断限流、认证鉴权、缓存加速等。不同的是,Service Mesh 强调的是通过独立的进程代理的方式,除此之外,还承担了上报日志、监控的责任。Service Mesh 架构如下。

架构演进的两大方向,一个是Serverless,另一个是什么?

轻量、自治促进不断发展

Service Mesh 的出现是由微服务架构推动的,随着一个应用被拆分为几百个甚至几万个应用,服务治理面临巨大的挑战。这个时候,微服务框架出现,例如,Finagle、Dubbo、SpringCloud、Netflix OSS 等。这些框架都是基于客户端负载均衡直连的方式,此方案的优势是性能高、应用性好,如 Spring Cloud。

归根结底,在微服务架构中,我们要解决的问题是,让开发人员感觉不到微服务之间的通信。当服务数量越来越多,升级微服务框架变得越来越复杂的时候,你不可能要求微服务框架一直不变,而且是没有 bug 的。在技术更新如此之快的年代,就更不可能了。

因此,微服务框架的部分功能开始逐步向服务端移动,希望客户端可以尽量“薄”,但是客户端不可能无限制的“薄”,剩余部分仍然比较“厚”。

因为使用客户端更像一种交付的模式,不容易变更,控制力较差,而 Service Mesh 则从业务进程集成客户端的方式演进为独立进程的方式,也就是说,原本的客户端变成了一个独立进程。对这个独立进程升级、运维要比绑在一起强得多。

微服务架构更强调去中心化、独立自治、跨语言,但是通常微服务框架限制了这一点,不可能为每种语言都实现一种框架,要么都用一种语言,要么实现多种语言的框架。而 Service Mesh 通过独立进程的方式进行了隔离,可以低成本实现跨语言。

随着 Docker 及 Kubernetes 的崛起,微服务的部署模式开始发生转变,越来越趋向于轻量级,越来越强调隔离自治。每个服务独立占用一个容器,将服务、依赖包、操作系统、监控运维所需的代理打包成一个镜像。这种模式促成了 Service Mesh 的发展,让 Service Mesh 实现起来更容易。否则开发人员需要额外维护 Service Mesh 进程,就非常麻烦了。

主流框架的弊病和优势

目前 Service Mesh 的框架如雨后春笋般快速涌现,以下几个框架是目前为止被提到次数最多的。

先驱者如 Linkerd,被誉为业界第一个 Service Mesh 项目,但由于很多功能被后续框架所取代,发展有限。现在最流行的是 Envoy,它在性能和资源消耗上表现得非常出色,被 Istio 收编之后, 专注于数据平面。最值得注意的是 Istio,因为它的背后是 Google 和 IBM。从 0.3 版本开始支持非 Kubernetes 平台,并可以独立运行。

当然业内还有其他一些框架,由于暂时没有投入到生产环境,进展有限,可以关注一下,比如 Conduit 、nginMesh 等。

就拿 Istio 来说,虽然它的架构思想被很多人认同,功能也很多,但是 Istio 的问题仍然较多,可用性较差,几乎没有生产级的案例。有点像当初 Kubernetes 刚刚研发出来的感觉,也许随着技术的不断发展会成为 Service Mesh 的未来,毕竟当前很多公司都在跟随这个框架。

先谨慎观察 未来可期

实际上,如果在一个小公司,Service Mesh 的优势并不是十分明显。例如小公司很少会考虑采用多语言,因为多一种语言就意味着要花费额外的精力进行维护,所以到目前为止,大多数公司在后端只使用一两种语言。

另外,微服务框架相对来说比较稳定,就如同 Spring Framework 一样,不会轻易进行不兼容的升级,只要保持好节奏,问题不会太多。因此,像 Netflix 这样的公司,基本上还是沿用类似 Spring Cloud 模式的。

Service Mesh 对业务开发人员友好,但是基础设施层的研发会更复杂,需要依赖更多的服务、组件,否则将带来极大的架构、运维复杂度。对于很多公司来说,门槛稍高,且需要投入成本。

百度内部业务也很早就开始了基于 Service Mesh 思想的微服务实践,并自研了 BMesh 框架,大大降低了 Service Mesh 的实施和维护成本,并解决其自身的性能问题。基于这些内部实践,百度智能云 CNAP 产品目前已经邀测推出了非侵入式微服务解决方案,为客户提供可商用的基于 Service Mesh 的微服务监控、追踪和治理平台。
目前来看,在没有成熟起来以前,Service Mesh 并不具备压倒性的优势。但未来随着微服务的进一步快速普及,Service Mesh 作为重要的架构演进方向值得关注。

本文转载自公众号 AIOps 智能运维(ID:AI_Ops)。

原文链接:

https://mp.weixin.qq.com/s/z8-_68EvyoW0u2D27gOiUA

评论

发布