​​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版本。此为新版本特点：

InfoQ独家专访Bouyant的创始人兼首席执行官William Morgan，并谈及了这个里程碑。

InfoQ： Linkerd是什么，为什么微服务和云本地应用程序在通信层需要新的“服务网格”？

Morgan： Linkerd是一个“服务网格”，它是专用于处理时间敏感的服务到服务的通信基础设施层。与传统网格物料相反，服务网格进行请求级别操作。所以我们不谈论数据包或者是字节，我们考虑的是请求导致响应的结果。服务Foo将与服务Bar交流，并且等待它做出响应，当它做到时，Foo将会处理结果，然后将自己的结果中继给它的调用者。如果Bar不及时回应，那么Foo也不得不做出一些反馈。

当然这种请求-响应模式自从网络编程开始便一直存在，但正在改变的是，对于微服务，使用原生云应用程序，每次对应用程序进行调用，这种通信将在应用程序内发生了几十或者几百次。因此，如果有成千上百个的服务，而且每个服务运行数百个实例，并且每秒有数百个请求，那么你最终会遇到一个非常复杂的请求流通过应用程序。而且这个实例可能正在死亡，或者正变得越来越超负荷，又或者被重新安排了所有的时间….总之它变得十分复杂。

服务网格的目标是解耦这个模型的操作复杂性，将其移动到应用程序之外，使应用程序保持纯净。因此程序代码只需要说：“嘿，我是服务Foo，我需要发送请求到服务Bar。”而操作的东西，比如重试、超时、截止日期、负载均衡和服务发现，他们不仅极其难以找到合适的，但关键是找到了合适的之后，应用程序也不会停留太长时间，当然，如果他们不正确，应单独处理。它们是在单独的一层，在那里，他们可以独立于应用程序运行进行管理。

Linkerd以它目前的形式，是一个用户空间代理，因为这是人们最容易使用的。这就像注入了类固醇的HAProxy。但是根本上服务网格概念远远超过了代理模型。