Buoyant 是一家云服务公司，宣布了 Linkerd (发音为“linker-DEE”) 的一周年纪念日，这是一个基于微服务的原生云应用程序的开源“服务网格”项目。诚如公告所述：
在 20 世纪 90 年代，TCP/IP 协议之类网络通信的转变，使得全行业从主机转移到客户机 / 服务器结构，Linkerd 作为下一代云应用的基础网络层，受到越来越多的采用，使得企业能够在不牺牲可靠性的情况下将其计算架构从单片应用转移到了微服务。
Linkerd 通过自动化负载均衡、服务发现和运行时恢复能力为微服务提供可靠性。
Linkerd 于 2016 年 2 月发布 0.1.0 版本，由前 Twitter 工程师 William Morgan ，现任 Buoyant 首席执行官和 Oliver Gould （Buoyant 现任首席技术官）创建。Linkerd 建立在 Finagle 之上 ，是“一个与协议无关的、用于 JVM 的异步 RPC 系统，这使它可以简单地在 Java、Scala 或者任何 JVM 托管语言中构建强大的客户端和服务器”，部署在 Twitter 的生产环境中。
下图演示了 Linkerd 如何被部署成应用程序实例的服务网格：
Buoyant 最近发布了 Linkerd 的 0.9.0 版本。此为新版本特点：
- 改进管理仪表板
- 改进对 Prometheus 指标的支持
- 简化路由器名称
InfoQ 独家专访 Bouyant 的创始人兼首席执行官 William Morgan，并谈及了这个里程碑。
InfoQ：你在 Buoyant 目前的职责是什么？或者说，你每天都在做什么？
William Morgan：我是首席执行官，这意味着在一家工程繁忙的公司，比如 Buoyant，我需要花费大部分时间在公司，而这只是为了跟上工程师的进程。他们的工作是做出优秀的产品，而我的工作是在他们身边，为他们建立一个良好的公司，可以用来支持他们，并且将他们所创造出的东西的价值转化为外部世界所能够欣赏到的。
InfoQ：你能告诉读者更多关于贵公司的信息吗?
Morgan：我们为原生云环境构建开源操作可靠性软件。我们的使命是使各地的公司能够构建安全且有弹性的任务关键型应用程序。我们是一家重型工程公司，与推特、谷歌、微软和雅虎等公司积累了许多集体经验，工程师团队（特别是 SREs 和 DevOps 的工作人员）需要可靠、安全地运维他们的应用程序，我们要利用这些集体经验使他们可以做到这一点。我们过去也是一直都保持电话在线的，即使因为一些愚蠢的原因，也必须要在凌晨 3 点醒来，所以我们的目标是尽量减少这种情况。在此，也向我们随叫随到的工程师们表示感谢。
InfoQ： Linkerd 是什么，为什么微服务和云本地应用程序在通信层需要新的“服务网格”？
Morgan： Linkerd 是一个“服务网格”，它是专用于处理时间敏感的服务到服务的通信基础设施层。与传统网格物料相反，服务网格进行请求级别操作。所以我们不谈论数据包或者是字节，我们考虑的是请求导致响应的结果。服务 Foo 将与服务 Bar 交流，并且等待它做出响应，当它做到时，Foo 将会处理结果，然后将自己的结果中继给它的调用者。如果 Bar 不及时回应，那么 Foo 也不得不做出一些反馈。
当然这种请求 - 响应模式自从网络编程开始便一直存在，但正在改变的是，对于微服务，使用原生云应用程序，每次对应用程序进行调用，这种通信将在应用程序内发生了几十或者几百次。因此，如果有成千上百个的服务，而且每个服务运行数百个实例，并且每秒有数百个请求，那么你最终会遇到一个非常复杂的请求流通过应用程序。而且这个实例可能正在死亡，或者正变得越来越超负荷，又或者被重新安排了所有的时间…. 总之它变得十分复杂。
服务网格的目标是解耦这个模型的操作复杂性，将其移动到应用程序之外，使应用程序保持纯净。因此程序代码只需要说：“嘿，我是服务 Foo，我需要发送请求到服务 Bar。”而操作的东西，比如重试、超时、截止日期、负载均衡和服务发现，他们不仅极其难以找到合适的，但关键是找到了合适的之后，应用程序也不会停留太长时间，当然，如果他们不正确，应单独处理。它们是在单独的一层，在那里，他们可以独立于应用程序运行进行管理。
Linkerd 以它目前的形式，是一个用户空间代理，因为这是人们最容易使用的。这就像注入了类固醇的 HAProxy。但是根本上服务网格概念远远超过了代理模型。
InfoQ：你能告诉我们读者一些关于你在推特上使用 Finagle 的经验，以及 Linkerd 是如何构建在 Finagle 上的（在推特上，经常被称为帮助杀死“ Fail Whale”的关键技术之一）？
Morgan： Finagle 是 Twitter 如何击败 Fail Whale 的一个重要部分（我会说“击败”而不是“杀死”，因为我喜欢想象鲸鱼自由地游来游去，不去骚扰别人，而不是到处贪婪地吞噬）。 Twitter 决定将“巨石”分成许多不同的服务。我们当时没有“微服务”这个词，但这真的是我们正在做的。而且 Finagle 启动十分简单，它将成为我们用来调用从一个服务到另一个服务的库。几乎 Twitter 上的每一个服务端都使用 Finagle 客户端与另一个服务端进行通信，并且使用 Finagle 服务端接受请求。所以 Finagle 被放置在每个请求的两端。
事实证明，Twitter 在早期存在的正常运行时间和可靠性的大量问题都是由服务间彼此交互的方式所造成的。所以 Finagle 是我们可以解决所有问题的地方。随着时间的推移，Finagle 获得了负载均衡、服务发现、重试逻辑、断路、路由和命名抽象等一系列好东西。从 Finagle 的角度看来，它几乎就像是 Twitter 是一堆 Finagle 控制着的连接，但在它们之间有一些凌乱的应用程序代码。
而且很多运维经验已经在 Finagle 中实现了。Twitter 会以新颖的方式走下去，在 Finagle 中实现对根本问题的容错，并如此往复下去。所以随着时间的变化，Finagle 变得非常成熟，能够处理各种奇怪的边缘情形。因为这是分布式系统的模式，它们是由 1% 的正常操作和 99% 的奇怪边缘情形组成的。
InfoQ： 在你的 Linkerd 的最早时期中，你提出过一些目标，要向世人展示 Finagle 的能量。那么 Linkerd 将如何扩展 Finagle，使这些抽象的服务沟通更容易为主流企业所利用？
Morgan：这最大的区别就是，Linkerd 将 Finagle 包装成一个独立的代理，你只需要运行它，而不必了解其如何实现的细节。它不关心你的服务使用什么语言或服务器框架。Finagle 是一个库，所以如果你在用 JVM，你实际上就只能使用它了。但 Linkerd 却可以在任何地方使用。
另一个区别是 Linkerd 给你的仅仅只是一个运维模型。而 Finagle 具有两个模型：一个编程模型和一个运维模型。并且编程模型是非常优雅，具有表现力的，它是 RCP 调用的函数式编程，它让你写出漂亮的代码、神奇的代码、最好的代码。但我们把这些都扔掉了，我们只是给你运维的东西。事实上，我们努力地工作是为了让你使用 Linkerd 时不必深入了解 Finagle，而不是口头表达“嘿，它的基础可是有够可靠、强大，比如 Twitter、 Soundcloud 和 Pinterest 和一些其他公司。”
InfoQ：Linkerd 之于微软服务器，已经比作了使 TCP 能够转向客户端 - 服务端的方式。你觉得这么比合理吗？
Morgan：这个比较当然合理。好比我在一件连帽衫里看见自己是 Vint Cerf。哦，当然这只是一个理想化的比较。但是机会是存在的。首先，它是一个抽象层。TCP 允许网络编程人员说：“嘿，从这里到那里发送这些字节，不需要考虑数据包的丢失或重复，也不需要考虑关于路由、关于流控制、关于多个应用可能共享相同 IP 地址的事实”。类似地，Linkerd 允许应用程序员说：“嘿，将这个请求从这里发送到那里，不必担心超时、期限传播、服务发现和跨多个端点的平衡的问题以及重试或者断路的状况。”
更广泛地说，有一个巨大的，全行业范围内的变化正发生在应用程序的架构上。这就是整个“原生云”转型。公司正在将 Docker 、Kubernetes 和微服务转移到云本地堆栈上，但他们真的没有选择的余地。这只是一个时间的问题；他们预计运营的规模将会越来越大，但是这些虚拟化硬件真的缺乏可靠性语义；他们真的都需要在产品上同时快速迭代。这些情况都会促进原生云的建立。
而这种巨大的转变，在这样一个基本的层次上，类似于从主型机转移到客户端 - 服务端的行为，使得整个行业围绕 TCP/IP 构建。围绕网络硬件的整个行业是从 20 世纪 80 年代的转变开始被创建的，比如 Cisco 这样的公司。类似的事情现在正在发生，将堆栈向上移一点。所以这就是我们的秘密计划：成为微服务中的 Cisco。
InfoQ： Linkerd 在什么案例中很重要？
Morgan： 任何系统都需要多个服务，并且性能和可靠性都是至关重要的，其 SLA 正在运行的系统是 Linkerd 的一个候选者。Linkerd 最早的很多采用者都是付款处理器和银行，比如 Monzo 和 Zooz ，他们正在云计算平台上构建基础设施，并且真正关注可靠性问题。停机的每一秒时间都是金钱损失。事务已经通过系统准确地附加上了金钱。这就是 Linkerd 真正擅长的用例。
InfoQ：能和我们说说关于 Linkerd 路线图的情况吗。自从它第一次被推出之后，在过去一年之间增加了什么，并且你将如何扩展其功能？
Morgan：是的，性能和资源消耗一直是我们正在努力解决的事情。我们希望 Linkerd 更小、更快、更轻。我们有一些及其酷炫的秘密，而且我们也正在努力将其实现，我真的很兴奋，因为我们很快就能将之公之于众了。 我们也还需要在工作中支持更多的协议，并支持原始 TCP。当然，为了更紧密地与我们原生云的兄弟连接，特别是与 Kubernetes 的集成，现在很容易就可以将 Linkerd 嵌入到 Kubernetes 中，但是将来会有一些东西使它完成得更容易。
最后，我们认为，诸如 gRPC 和 HTTP/2 之类的多路复合协议将是未来大规模分布式系统的明显选择。Linkerd 已经对这些协议提供了巨大的支持，我们也将继续投入。
资源
有关 Linkerd 的更多信息，请访问以下资源：
查看英文原文： Open Source Linkerd Project Celebrates First Anniversary in Quest to Become TCP/IP of Microservices
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论