Buoyant 发布服务网格 Linkerd 的 1.0 版本

云原生软件公司 Buoyant 发布了 Linkerd （读作“linker-DEE”）的 1.0 版本，这是一个面向云原生微服务应用的开源“服务网格（service mesh）”。Buoyant 首席技术官 Oliver Gould 论述了该版本的重大意义：

对于任何开源项目而言，1.0 版本都是一个有意义的里程碑。就我们而言，这是承认我们的产品有了一个稳定的功能集合，我们的用户可以基于这些功能处理他们最关键的生产流量。同时，这也表明，我们今后将限制破坏配置的修改。

令人不敢相信的是，我们这样一个小项目竟然积累了一群令人惊叹的运营商和开发商。我不断为来自 Linkerd 社区的功能和集成所震惊；没有什么比听到 Linkerd 如何帮助团队完成他们的工作更让人高兴了，而且让他们少一点担心和不确定性。

Buoyant 创始人兼首席执行官 William Morgan 补充道：

随着 Linkerd 达到 1.0 版本，我们很自豪地看到，在长长的采用者名单里，有类似 Paypal、Credit Karma 和 Ticketmaster 这样的公司。像这样高流量、高可靠性的公司正使用 Linkerd 服务网格作为更广泛努力的一部分，和类似 Docker、Kubernetes 这样的基础设施及云原生栈的其他部分一起，为他们的应用程序带来更高层次的可靠性和可扩展性。

Morgan阐述了服务网格的用途以及在云原生栈中有一个服务网格的重要性。 GitHub 上提供了在 Docker 、 Kubernetes 及本机上运行Linkerd 的入门示例。

在2017 年3 月份， Linkerd 一周年之际，Morgan 曾接受过 InfoQ 的独家采访。现在，Morgan 就这个里程碑版本再次接受了 InfoQ 的采访。

InfoQ：请您向我们的读者介绍下该服务网格的愿景。在什么情况下，组织需要这样一个新的抽象来管理服务之间的通信？

Morgan：服务网格是一个处理服务间通信的基础设施层。它是栈中一个提升多服务应用可靠性和安全性的点，它为整个应用提供了一个统一的可视化和控制层。

如果你正在运营单体软件，或者有一个跃点数有限的架构，而它们由专用的客户端库（像一个三层应用）提供了很好的服务，那么可能没有这个也没问题。

但是，如果你正在构建“云原生”应用——现如今，这主要是指使用 Docker、Kubernetes 及微服务——那么，这种跨服务通信是构成应用程序运行时行为的重要部分。你不能忽视它。你必须监控它，你必须能够管控它。你需要一个像 Linkerd 这样的服务网格。

InfoQ：在服务之间最常见的中断类型中，有什么是特定于相对还比较新的、更现代化的微服务和容器架构吗？

Morgan：嗯，对于任何分布式系统而言，其中一个“有趣的”部分是，一个很小的局部故障可以通过很多方式逐步升级为系统故障，也就是臭名昭著的“级联故障”。例如，当发生某种临时故障时，你希望通过请求重试来处理。当然，重试会增加系统的负载。当大量的负载加到软件上，它就开始变慢，最终开始失败——或者变得非常慢，那和故障很难区分开来。因此，你处理失败的方式实际上可能让事情变得更糟糕。一个很小的部分开始变慢，你很快就增加负载，然后它停止运行，然后所有与它相关的一切都开始停止运行。

Linkerd 就是设计用来处理这种情况的。它可以很好地减载，用恰当的方式失败，它能够使用不激化问题的方式重试。它还有其他功能，如安全、优化和探测，但真正让它变得至关紧要的是可靠性。

InfoQ：Linkerd 1.0 版本有什么新增特性？其中最酷的新特性和功能是什么？

Morgan：Linkerd 1.0 新增的一个重要的东西是服务网格 API。服务网格的全部意义不只是到处部署一堆复杂的面向内部的复杂代理，然后说，嘿，我们现在具备了可靠性。服务网格的重点是服务之间的通信，将其移出不可见的隐形基础设施领域，赋予它生态系统一级成员的角色。此外，你希望这个关键的层次是可监控的、托管的、受控的。服务网格 API 就是你实现那些特性的基础。

在 1.0 中，我们还继续扩大和强化了我们和周边生态系统的集成——类似 Kubernetes、 gRPC、Mesos、Consul、Prometheus 和 Zipkin 这样的东西。服务网格是一个胶水层，许多 Linkerd 用户正使用它将 Kubernetes 嵌入到他们已有的基础设施，或者从容地在架构之间迁移服务。

InfoQ：在稳定性和“就绪状态”方面，1.0 版本显然是一个巨大的里程碑。展望未来，在其他期望的功能中，您认为哪些功能区域是 Linkerd 用户最感兴趣的？

Morgan：在我们面前，有一个非常令人兴奋的路线图。目前为止，我们的重点主要是可靠性特性，结果，我们有了两个很棒的构建块——最好的服务度量和以任意方式进行流量路由的能力——两者结合可以实现非常强大的功能，如有原则地在数据中心之间进行故障转移，或者多云 / 混合云，或者基于延迟自动扩展。此外，我们希望进入的领域还包括策略执行、无服务器、计量和多租户计费等等，不胜枚举。

最后，稳定性、性能和资源消耗总是要重点考虑的。我们做了大量的跟踪工作，只为让 Linkerd 更快、更小、更轻量级，尤其是类似 TLS 这样的东西。

InfoQ：Linkerd 在云原生基金会下——一般来说，您怎么看待云原生不断地成长为一种企业趋势？是哪些条件促使企业构建云原生应用程序？在接下来的一两年中，我们有望看到这种趋势对开发人员产生了什么影响？

Morgan：云原生的采用疯狂增长，而且节奏每天还在加快。不妨看下 Docker 或 Kubernetes 的采用率。我认为，对于企业而言，那是不可避免的，因为它与采用云联系在一起。实际上，云原生只是你针对云编写软件时所采用的模式的名称。一旦软件部署到了云上，你就不得不面对这样的现实，你过去拥有的、专有硬件带给你的所有可靠性保障都不复存在。你无法控制硬件、随机故障及其他租户的资源消耗，任何东西任何时候都可能出错。因此，如果你希望应用程序可靠、可扩展，那么在软件层面，所有这些都快发生了。你构建软件的方式确保了软件的可靠性和可扩展性，但你赖以构建的环境却根本不可靠——那就是云原生所关注的。

查看英文原文： Buoyant Releases Version 1.0 of Their Service Mesh, Linkerd