1.2 Linkerd

2016年年初，原Twitter基础设施工程师William Morgan和Oliver Gould在GitHub上发布了Linkerd项目，并组建了Buoyant公司。同年，起源于Buoyant的新名词Service Mesh面世并迅速获得认可。紧接着，Buoyant官网发表博客连载A Service Mesh for Kubernetes，在渐入佳境的Kubernetes世界中打出了“The services must mesh”的口号，成为Service Mesh的第一批布道者。

Linkerd很好地结合了Kubernetes所提供的功能，以此为基础，在每个Kubernetes Node上都部署运行一个Linkerd实例，用代理的方式将加入Mesh的Pod通信转接给Linkerd，这样Linkerd就能在通信链路中完成对通信的控制和监控。

我们可以将原有的Pod通信理解为如图1-1所示的形式。

图1-1

在笔者看来，Linkerd除了完成对Service Mesh的命名，以及Service Mesh各主要功能的落地，还有以下重要创举：

◎ 无须侵入工作负载的代码，直接进行通信监视和管理；

◎ 提供了统一的配置方式，用于管理服务之间的通信和边缘通信；

◎ 除了支持Kubernetes，还支持多种底层平台。

这些创举在日后也成为Service Mesh的部分基础特性并被沿袭下来。

Linkerd在面世之后，迅速获得用户的关注，并在多个用户的生产环境上成功部署、运行。2017年，Linkerd加入CNCF，随后宣布完成对千亿次生产环境请求的处理，紧接着发布了1.0版本，并且具备一定数量的商业用户，一时间风光无限，一直持续到Istio横空出世。

于2017年5月诞生的Istio给Linkerd带来了巨大的压力。同年12月，Buoyant发布了新的Service Mesh产品Conduit，产品架构从单一的Linkerd部署，变为采用Rust Data Plan结合Go Control Plan的方案，图1-2来自Linkerd官网。

图1-2

相对于Linkerd来说，Conduit是一个更轻、更快的解决方案。然而社区的冷淡反应并未改变，Conduit最终在2018年9月更名为Linkerd 2.0，结束其历史使命。