微信号:infoqchina

介绍:有内容的技术社区媒体

Service Mesh解读:新一代微服务技术新秀

2017-11-19 09:00 William Morgan
作者 | William Morgan
译者 | 月满西楼
原题 | What’s a service mesh? And why do I need one?
来源 | 公众号 EAWorld

Service mesh 是一个专用的基础设施层,功能在于提供安全、快速、可靠的服务间通讯(service-to-service)。一个云原生应用(cloud native application)的构建离不开 Service mesh。

在过去的一年里,Service mesh 已悄然兴起,并成为云堆栈的一个重要组件。 像 Paypal、Lyft、Ticketmaster 和 Credit Karma 这样的高流量公司都在他们的产品应用中添加了 Service mesh。 今年 1 月,Linkerd,作为一个面向云原生应用的开源 Service mesh,成为了云原生计算基金会(CFCF)的官方项目。但到底什么是 Service mesh? 为什么突然受到如此大的关注?

在本文中,我将详细介绍 Service mesh 的定义,并通过过去 10 年里它在应用程序架构中的变化和大家追溯一下 Service mesh 的发展历程。

首先,我将把 Service mesh 与 API 网关、边界代理 edge proxies 和企业服务总线的相关但又截然不同的概念区分开来。 然后,我将介绍 Service mesh 的发展方向,以及在云原生时代, 新一代的微服务开发技术 Service mesh 将带给我们什么样的期待与变化。

什么是 Service mesh?

Service mesh 是用于处理服务间通讯的专用基础设施层。它负责通过复杂的拓扑结构服务来提供可靠的请求传递,这些服务构成了新一代云原生应用程序。事实上,Service mesh 通常是作为一组轻量级高性能网络代理实现的,这些代理与应用程序代码部署在一起,但应用程序本身不需要关心这些。(不过,外界对此尚存在异议)

Service mesh 作为单独层的概念与云原生应用程序的大规模普及有关。 在云原生模型中,单个应用程序可能包含数百个服务 ; 每个服务可能又包含数千个实例 ; 并且这些实例中的每一个都可能处于不断变化的状态,因为它们是由像 Kubernetes 这样的服务协调程序动态调度的。世界上的服务通讯不仅极其复杂,而且是运行时行为(runtime behavior)的一个普遍和基本的组成部分。管理好它对于确保端到端性能和可靠性是至关重要的。

Service mesh 是一个网络模型吗?

Service mesh 是一个网络模型,它是位于 TCP/IP 之上的抽象层。它假定底层的 L3/L4 网络是真实存在的,并且能够点对点地传递字节。(它还假定了这个网络像运行环境的其他方面一样,是不可靠的; 因此,Service mesh 必须能够处理网络故障。)

Service mesh 在某些方面其实是类似于 TCP/IP。就像 TCP 栈抽象出了网络端点之间可靠传递字节的机制一样,Service mesh 在服务之间可靠地传递请求的机制也是抽象的。与 TCP 相同的是,Service mesh 并不关心实际的有效负载,也不关心它的编码问题。应用程序有一个高级目标 (“从 A 到 B 发送一些数据”), Service mesh 的职责,和 TCP 一样,是在这个数据的发送过程中解决故障并圆满完成数据发送。

但与 TCP 不同的是,Service mesh 具有更高的性能,它的使命超越了“仅仅让它可以工作”, 并且有一个更重要的目标: 它提供了统一的、应用广泛的观点,应用程序在运行操作时具有可视性和可控性。Service mesh 的明确目标是将服务通讯从不可见的、隐含的基础设施中抽离出来,在云原生系统中扮演重要的一级成员的角色, 从而可对系统进行监控,管理和控制。

Service mesh/ 服务网格具体能做什么?

在云原生应用中可靠地传递请求可能非常复杂。 像 Linkerd 这样的 Service mesh,通过一系列强大技术来管理这种复杂性: 链路熔断、延迟感知、负载均衡,eventually consistent (“advisory”) 服务发现,服务续约及下线与剔除。这些功能必须协同工作,而这些功能与它们所操作的复杂环境之间的交互作用是非常微妙的。

例如,当通过 Linkerd 工具处理某个服务的请求时,简化的事件时间表如下:

  1. Linkerd 应用动态路由规则来确定请求者所需要的服务。应该将请求发送到生产或 Staging 的服务中吗?还是到本地数据中心或云平台服中?

    还是到正在进行测试的最新版本的或已通过审核的旧有版本的服务中? 所有这些路由规则都是动态可配置的, 并且可以应用到整个系统和任意的流量段中。

  2. 找到了正确的目标之后,Linkerd 从相关的服务发现节点中检索相应的实例池 (这其中可能有好几个)。 如果这些信息与 Linkerd 在实践中所观察到的有所背离,Linkerd 就会决定选择相对正确的信息来源。

  3. Linkerd 根据各种因素选择最有可能返回快速响应的实例,包括所观察到的最近请求的延迟。

  4. Linkerd 尝试将请求发送到实例,记录结果的延迟和响应类型。

  5. 如果实例关闭,无响应或无法处理请求,Linkerd 会在另一个实例上重新尝试该请求 (但只有它知道请求是幂等的情形下 - 即不管操作多少次结果都不变的性质)。

  6. 如果一个实例连续地返回错误,Linkerd 会将其从负载均衡池中择出去,然后再进行周期性的重新尝试 (例如,一个实例可能正在经历一个暂时性的失败)。

  7. 如果请求的截止时间已过,Linkerd 将主动取消请求,不会通过进一步的重新尝试进行加载。

  8. Linkerd 以 metrics 和分布式跟踪的形式捕捉了上述行为的各个方面,这些都被发送到一个集中的 metrics 系统。

当然, 这只是 Linkerd 的简化版本,Linkerd 还可以发起和终止 TLS,执行协议升级,动态转移流量,并在数据中心之间进行失效转移!

Linkerd Service mesh 管理服务到服务间的通讯,并将其与应用程序代码进行剥离。

需要注意的是,这些功能旨在兼顾应用实例(Point)的快速恢复能力和应用(application)的快速恢复能力。对于大型分布式系统来说,无论其架构如何,都有一个典型的特征:很容易出现局部的小故障,这些小故障最终可能会演变为整个系统的灾难性故障。 Service mesh 必须被设计成能够通过减少负载和在底层系统接近其极限时让其快速失效来防止这些恶化演变。

为什么说使用 Service mesh 是非常有必要的?

Service mesh 最终并不是引入一项新功能,而是功能定位的转变。Web 应用程序总是必须管理服务间通信的复杂性。要想了解 Service mesh 模型的起源, 我们可以追溯过去 15 年以来的这些应用程序的发展历程。

你可以思考下 2000 年的中型 web 应用程序的典型架构: 三层应用程序。 在这个模型中,应用程序逻辑、web 服务逻辑和存储逻辑都是单独的一层。 层之间的通信虽然复杂,但这种复杂性是限定在一定范围内,因为毕竟只有两个跳转。这里没有“网格”,但是在每个层的代码中处理的跳转之间有通信逻辑。

当这种架构方式在面对应用程序内部逻辑越来越复杂化的情形时,它就开始崩溃了。 像 Google、Netflix 和 Twitter 这样的公司无时无刻都面临着巨大的流量需求,它们实现了云原生方案的前身: 应用层被分解成许多服务 (有时称为“微服务”),层级间则形成了一个拓扑结构。 在这些系统中,广义的通讯层突然变得相关起来, 但通常以“胖客户端”的库集(library)形式出现, 比如 twitter 的 Finagle,Netflix 的 Hystrix,以及 Google 的 Stubby 就是这样的例子。

从很多方面上来讲,像 Finagle, Stubby 和 Hystrix 这些库集其实是 Service mesh 的雏形。虽然它们受其周围环境的细节影响,并且需要使用特定的语言和框架,但是它们是用于管理服务到服务间通信的专用基础设施,并且 (在开源 Finagle 和 Hystrix 库集的情形下) 可以在其公司之外使用。

到了云原生应用时期, 云原生模型本身结合了许多小型服务的微服务方法和两个额外的因素: 容器 (例如 Docker),它提供了资源隔离和依赖关系管理,以及一个编排层 (例如 Kubernetes),它将底层硬件抽象出了一个同质池。

这三个组件支持应用程序在负载下可弹性伸缩的自然机制, 并能够处理云平台环境中存在的部分故障。

但面对数百个服务或数千个实例,和随时在重新安排实例的编排层,单个请求经由服务拓扑的路径可能非常复杂, 而由于容器使每个服务用不同的语言写入处理变得更容易了,库集方法也就不再可行了。

这种复杂性和关键性的结合,激发了对服务到服务间通信的专用基础层的需求,这个专用层与应用程序代码分离出来,并能够捕捉底层环境的高度动态特性。就是这一专用层我们称之为 Service mesh。

Service mesh 的未来发展

在云原生系统中,Service mesh 的运用正在迅速增长,而未来,还有一条广阔的,令人兴奋的发展路线图等着我们去探索。无服务器计算(例如亚马逊的 Lambda)的要求直接适用于 Service mesh 的命名和链接模型,并且是它在云原生系统中角色的自然扩展。

服务身份和访问策略的作用在云原生环境中仍然很新鲜,Service mesh 在此很好的扮演着重要的角色。最后,Service mesh,就像在它之前的 TCP/IP 一样,将继续被推进运用到底层基础设施层中。 正如 Linkerd 从 Finagle 这样的系统演化而来,Service mesh 的当前化身是一个独立的用户空间代理,必须明确地添加到云堆栈中,并且将继续发展。

小    结

Service mesh 是云堆栈的一个关键组件。 Linkerd 发布至今虽然才一年多点,但已成为云原生计算基金会(CFCF)的主要成员,并拥有一个活跃的用户群体。其中的用户包括像 Monzo 这样的初创公司,他们正在颠覆英国的银行业;和 Paypal、Ticketmaster 和 Credit Karma 这样的大型知名互联网公司;以及像 Houghton Mifflin Harcourt 这样的拥有数百年业务的公司。

Linkerd 开源社区的用户每天都在证明并分享 Service mesh 模型的价值。同时我们也在致力于打造令人惊叹的出色产品, 并在持续壮大和活跃我们的社区,一个强者云集、不可思议的开源社区!你还犹豫什么呢,加入我们吧!

原文链接:

https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/

期望得到更多优质技术干货,欢迎扫描群助手小波波二维码,与近万名技术人一起在 eaworld 社群参与定期微课、视频分享、探讨关于微服务、DevOps 实践等技术内容。入群暗号:1119


 
InfoQ 更多文章 为什么程序员的世界有对错,产品经理的没有? Q新闻丨阿里重启维护Dubbo;Go语言成2017增长最快语言;WebAssembly 已被所有主流浏览器支持 哥们儿,你用什么编程语言? 阿里巴巴运维体系变迁史 我是北漂程序员,没有假装在生活丨二叉树视频
猜您喜欢 C++程序员看过来,你会为了性能而牺牲代码简洁性吗? 笑谈设计模式(尾篇) Android如何实现毛玻璃效果之Android高级模糊技术 好玩的Python彩蛋 致歉:关于[Ruby 程序员]发布博文侵权一事!