llc拓扑（llc拓扑布局 ）〔llc 拓扑〕

原文：Pattern: Service Mesh

作者：Phil Calçado

翻译：雁惊寒

择要 ：本文由简到难地先容 了分布式体系 到服务网格的演化过程，从而让读者对服务网格有一个感性的认识 。以下是译文。

自从几十年前第一次引入分布式体系 这个概念以来 ，出现了很多 原来根本想象不到的分布式体系 利用 案例，但同时也引入了各种各样的新题目 。

当这些体系 还是 比力 少比力 简单 的时间 ，工程师可以通过镌汰 长途 交互的次数来办理 复杂性题目 。处理 惩罚 分布式题目 最安全的方法是尽大概 克制 长途 交互 ，固然 这大概 意味着要在多个体系 上存放重复的逻辑和数据。

行业上的需求推动着我们进步 的步调 ，分布式体系 的构成 从几个大型的中心 电脑发展成为数以千计的小型服务 。在这个新的天下 里，我们必须走出窘境 ，应对新的挑衅 和开放性题目 。起首 ，具体 题目 具体 分析，针对某个题目 给出有针对性的办理 办法 ，然后再提供更先辈 更复杂的办理 方案。随着我们对题目 范畴 越来越认识 、提出的办理 办法越来越好，我们开始将一些最常见的需求总结归纳为模式 、库，以及终极 的平台 。

当我们第一次将电脑联网时 ，发生了什么

由于人们起首 想到的是让两台或多台电脑相互通讯，因此，他们构思出了如许 的东西：

相互 之间可以通讯的两个服务可以满意 终极 用户的一些需求。但这个表示 图显然过于简单 了，缺少了包罗 通过代码操纵 的字节转换和在线路上收发的电信号转换在内的多个层。固然 ，肯定 程度 上的抽象对于我们的讨论是必须 的，但还是 让我们来添加网络协议栈组件以增长 一点细节内容吧：

上述这个修改过的模子 自20世纪50年代以来不停 利用 至今 。一开始，盘算 机很希罕 ，也很昂贵，以是 两个节点之间的每个环节都被经心 制作和维护。随着盘算 机变得越来越自制 ，毗连 的数量 和数据量大幅增长 。随着人们越来越依靠 网络体系 ，工程师们必要 包管 他们构建的软件可以或许 到达 用户所要求的服务质量 。

固然 ，尚有 很多 题目 急需办理 以到达 用户要求的服务质量程度 。人们必要 找到办理 方案让呆板 相互 发现、通过同一条线路同时处理 惩罚 多个毗连 、答应 呆板 在非直连的环境 下相互 通讯 、通过网络对数据包举行 路由、加密流量等等。

在这此中 ，有一种叫做流量控制的东西 ，下面我们以此为例。流量控制是一种防止一台服务器发送的数据包高出 卑鄙 服务器可以遭受 上限的机制 。这是须要 的，由于 在一个联网的体系 中，你至少有两个差别 的、独立的盘算 机 ，相互 之间互不相识 。 盘算 机A以给定的速率向盘算 机B发送字节，但不能包管 B可以连续 地以充足 快的速率 来处理 惩罚 吸取 到的字节。比方 ，B大概 正在忙于并行运行其他任务 ，大概 数据包大概 无序到达 ，而且 B大概 被壅闭 以等待 本应该第一个到达的数据包 。这意味着A不但 不知道B的预期性能，而且还大概 让事变 变得更糟，由于 这大概 会让B过载 ，B如今 必须对全部 这些传入的数据包举行 列队 处理 惩罚 。

一段时间以来，各人 寄盼望 于创建 网络服务和应用程序的开辟 者可以或许 通过编写代码来办理 上面提出的挑衅 。在我们的这个流程控制示例中，应用程序本身 必须包罗 某种逻辑来确保服务不会由于 数据包而过载 。这种重联网的逻辑与业务逻辑一样紧张 。在我们的抽象表示 图中 ，它是如许 的：

荣幸 的是，技能 的发展日新月异，随着像TCP/IP如许 的标准 的横空出世 ，流量控制和很多 其他题目 的办理 方案被融入进了网络协议栈本身 。这意味着这些流量控制代码仍旧 存在，但已经从应用程序转移到了操纵 体系 提供的底层网络层中：

这个模子 相本地 乐成 。险些 任何一个构造 都可以或许 利用 贸易 操纵 体系 附带的TCP/IP协议栈来驱动他们的业务，纵然 有高性能和高可靠性的要求。

当我们第一次利用 微服务时 ，发生了什么

多年以来，盘算 机变得越来越自制 ，而且 到处 可见，而上面提到的网络协议栈已被证明 是用于可靠毗连 体系 的究竟 上的工具集。随着节点和稳固 毗连 的数量 越来越多 ，行业中出现了各种各样的网络体系 ，从细粒度的分布式署理 和对象到由较大但重分布式组件构成 的面向服务的架构 。

如许 的分布式体系 给我们带来了很多 风趣 的更高级别的案例和长处 ，但也出现了几个困难 。此中 一些是全新的 ，但其他的只是我们在讨论原始网络时碰到 困难 的更高版本而已。

在90年代，Peter Deutsch和他在Sun公司的同事工程师们撰写了“分布式盘算 的八大错误”一文，此中 列出了人们在利用 分布式体系 时通常会做出的一些假设。Peter以为 ，这些假设在更原始的网络架构或理论模子 中大概 是真实的，但在当代 天下 中是不创建 的：

网络是可靠的

耽误 为零

带宽是无穷 的

网络是安全的

拓扑是稳固 的

有一个管理员

传输本钱 为零

网络是同构的

各人 把上面这个列表斥为“谬论”，因此 ，工程师们不能忽视这些题目 ，必须明白 地处理 惩罚 这些题目 。

为了处理 惩罚 更复杂的题目 ，必要 转向更加分散的体系 （我们通常所说的微服务架构） ，这在可操纵 性方面提出了新的要求。 之前我们已经具体 讨论了一些内容，但下面则列出了一个必须要处理 惩罚 的东西：

盘算 资源的快速提供

根本 的监控

快速摆设

易于扩展的存储

可轻松访问边沿

认证与授权

标准 化的RPC

因此，只管 数十年前开辟 的TCP/IP协议栈和通用网络模子 仍旧 是盘算 机之间相互通讯的有力工具，但更复杂的架构引入了另一个层面的要求 ，这再次必要 由在这方面工作的工程师来实现。

比方 ，对于服务发现和断路器，这两种技能 已用于办理 上面列出的几个弹性和分布式题目 。

汗青 每每 会重演 ，第一批基于微服务构建的体系 依照 了与前几代联网盘算 机雷同 的战略 。这意味着落实上述需求的责任落在了编写服务的工程师身上。

服务发现是在满意 给定查询条件的环境 下主动 查找服务实例的过程，比方 ，一个名叫Teams的服务必要 找到一个名为Players的服务实例 ，此中 该实例的environment属性设置为production 。你将调用一些服务发现进程 ，它们会返回一个满意 条件的服务列表。对于更会合 的架构而言，这是一个非常简单 的任务 ，可以通常利用 DNS 、负载均衡 器和一些端标语 的约定（比方 ，全部 服务将HTTP服务器绑定到8080端口）来实现。而在更分散的环境 中，任务 开始变得越来越复杂 ，从前 可以通过盲目信托 DNS来查找依靠 关系的服务如今 必须要处理 惩罚 诸如客户端负载均衡 、多种差别 环境 、地理位置上分散的服务器等题目 。假如 之前只必要 一行代码来分析 主机名，那么如今 你的服务则必要 很多 行代码来处理 惩罚 由分布式引入的各种题目 。

断路器是由Michael Nygard在其编写的“Release It ”一书中引入的模式。我非常喜好 Martin Fowler对该模式的一些总结：

断路器背后的根本 思绪 非常简单 。将一个受掩护 的函数调用包罗 在用于监督 故障的断路器对象中。一旦故障到达 肯定 阈值，则断路器跳闸，而且 对断路器的全部 后续调用都将返回错误 ，并完全不担当 对受掩护 函数的调用。通常，假如 断路器发生跳闸，你还必要 某种监控警报。

这些都黑白 常简单 的装备 ，它们能为服务之间的交互提供更多的可靠性 。然而，跟其他的东西一样，随着分布式程度 的进步 ，它们也会变得越来越复杂。体系 发生错误的概率随着分布式程度 的进步 呈指数级增长，因此纵然 简单 的事变 ，如“假如 断路器跳闸 ，则监控警报”，也就不那么简单 了。一个组件中的一个故障大概 会在很多 客户端和客户端的客户端上产生连锁反应，从而触发数千个电路同时跳闸 。而且 ，从前 大概 只需几行代码就能处理 惩罚 某个题目 ，而如今 必要 编写大量的代码才华 处理 惩罚 这些只存在于这个新天下 的题目 。

究竟 上，上面举的两个例子大概 很难精确 实现，这也是大型复杂库 ，如Twitter的Finagle和Facebook的Proxygen，深受欢迎 的缘故起因 ，它们能克制 在每个服务中重写雷同 的逻辑。

大多数采取 微服务架构的构造 都依照 了上面提到的谁人 模子 ，如Netflix 、Twitter和SoundCloud 。随着体系 中服务数量 的增长 ，他们发现了这种方法存在着各种弊端 。

纵然 是利用 像Finagle如许 的库，项目团队仍旧 必要 投入大量的时间来将这个库与体系 的其他部分 连合 起来 ，这是一个代价非常高的困难 。根据我在SoundCloud和DigitalOcean的履历 ，我估计在100-250人规模的工程师构造 中，必要 有1/10的职员 来构建模子 。偶然 ，这种代价很轻易 看到，由于 工程师被分配到了专门构建工具的团队中，但是更多的时间 ，这种代价是看不见的，由于 它表现 为在产物 研发上必要 耗费 更多的时间。

第二个题目 是，上面的设置限定 了可用于微服务的工具、运行时和语言。用于微服务的库通常是为特定平台编写的，无论是编程语言还是 像JVM如许 的运行时 。假如 开辟 团队利用 了库不支持的平台 ，那么通常必要 将代码移植到新的平台。这浪费了原来 就很短的工程时间。工程师没办法再把重点放在核心 业务和产物 上，而是不得不花时间来构建工具和底子 架构。那就是为什么一些像SoundCloud和DigitalOcean如许 的中型企业以为 其内部服务只需支持一个平台，分别是Scala大概 Go 。

这个模子 末了 一个值得讨论的题目 是管理方面的题目 。库模子 大概 对办理 微服务架构需求所需功能的实现举行 抽象 ，但它本身 仍旧 是必要 维护的组件。必须要确保数千个服务实例所利用 的库的版本是雷同 的或至少是兼容的，而且 每次更新都意味着要集成、测试和重新摆设 全部 服务，纵然 服务本身 没有任何改变 。

下一个逻辑上的步调

雷同 于我们在网络协议栈中看到的那样 ，大规模分布式服务所需的功能应该放到底层的平台中。

人们利用 高级协议（如HTTP）编写非常复杂的应用程序和服务，乃至 无需思量 TCP是怎样 控制网络上的数据包的。这种环境 就是微服务所必要 的，那些从事服务开辟 工作的工程师可以专注于业务逻辑的开辟 ，从而克制 浪费时间去编写本身 的服务底子 办法 代码或管理整个体系 的库和框架 。

将这个想法连合 到我们的图表中，我们可以得到如下所示的内容：

不幸的是，通过改变网络协议栈来添加这个层并不是一个可行的任务 。很多 人的办理 方案是通过一组署理 来实现。这个的想法是 ，服务不会直接毗连 到它的卑鄙 ，而是让全部 的流量都将通过一个小小的软件来透明地添加所需功能 。

在这个范畴 第一个有记录 的进步利用 了边三轮（sidecars）这个概念。“边三轮”是一个辅助进程 ，它与主应用程序一起运行，并为其提供额外的功能。在2013年 ，Airbnb写了一篇有关Synapse和Nerve的文章，这是“边三轮 ”的一个开源实现 。一年后，Netflix推出了Prana ，专门用于让非JVM应用程序从他们的NetflixOSS生态体系 中受益。在SoundCloud，我们构建了可以让遗留的Ruby程序利用 我们为JVM微服务构建的底子 办法 的“边三轮”。

固然 有这么几个开源的署理 实现，但它们每每 被计划 为必要 与特定的底子 架构组件共同 利用 。比方 ，在服务发现方面，Airbnb的Nerve和Synapse假设了服务是在Zookeeper中注册，而对于Prana ，则应该利用 Netflix本身 的Eureka服务注册表 。

随着微服务架构的日益遍及 ，我们近来 看到了一波新的署理 海潮 ，它们足以机动 地顺应 差别 的底子 办法 组件和偏好。 这个范畴 中第一个广为人知的体系 是Linkerd ，它由Buoyant创建出来，源于他们的工程师先前在Twitter微服务平台上的工作。很快，Lyft的工程团队公布 了Envoy的发布，它依照 了雷同 的原则 。

Service Mesh

在这种模式中 ，每个服务都配备了一个署理 “边三轮”。由于这些服务只能通过署理 “边三轮 ”举行 通讯 ，我们终极 会得到雷同 于下图的摆设 方案：

Buoyant的首席实行 官威廉·摩根表现 ，署理 之间的互连形成了服务网格。 2017年初 ，威廉写下了这个平台的界说 ，并称它为服务网格：

服务网格是用于处理 惩罚 服务到服务通讯 的专用底子 办法 层 。它负责通过复杂的服务拓扑来可靠地转达 哀求 。实际 上，服务网格通常被实现为与应用程序代码一起摆设 的轻量级网络署理 矩阵 ，而且 它不会被应用程序所感知。

这个界说 最强大 的地方大概 就在于它不再把署理 看作是孤立的组件，并承认 它们本身 就是一个有代价 的网络 。

随着微服务摆设 被迁徙 到更为复杂的运行时中去，如Kubernetes和Mesos ，人们开始利用 一些平台上的工具来实现网格网络这一想法。他们实现的网络正从相互 之隔断 离的独立署理 ，转移到一个符合 的而且 有点会合 的控制面上来。

来看看这个鸟瞰图，实际 的服务流量仍旧 直接从署理 流向署理 ，但是控制面知道每个署理 实例 。控制面使得署理 可以或许 实现诸如访问控制和度量网络 如许 的功能，但这必要 它们之间举行 相助 ：

近来 公布的Istio项目是这类体系 中最闻名 的例子。

完全明白 服务网格在更大规模体系 中的影响还为时尚早，但这种架构已经凸显出两大上风 。起首 ，不必编写针对微服务架构的定制化软件 ，即可让很多 小公司拥有从前 只有大型企业才华 拥有的功能，从而创建出各种风趣 的案例。第二，这种架构可以让我们终极 实现利用 最佳工具或语言举行 工作的空想 ，而且 不必担心每个平台的库和模式的可用性 。