下载掌阅APP，畅读海量书库
立即打开
Linkerd是云原生软件公司Buoyant推出的开源项目，是全球范围内第一个完善的Service Mesh项目，也是第一个将Service Mesh技术广泛用于生产环境，是当之无愧的Service Mesh技术开山鼻祖。Buoyant和Linkerd最早开始不断地宣扬Service Mesh技术理念，构建Service Mesh技术体系并成功推向市场，对Service Mesh技术的发展和壮大起到至关重要的作用，加速了Service Mesh技术的落地。
介绍Linkerd之前先介绍一下和Linkerd渊源颇深的Fingle。Fingle是Twitter开源的支持高并发、高可用的服务治理框架，Finagle除了支持广泛应用的基于请求/答复的RPC协议之外，还集成了如Thrift、Redis、Memcached、MySQL等多种协议，Finagle聚焦统一的、协议无关的服务集成和服务治理功能集成。Fingle经过长期的生产环境验证，已经非常成熟稳定，在JVM系得到广泛应用，基于Finagle可以方便快捷地搭建微服务。
Linkerd建立在Finagle之上，由前Twitter工程师William Morgan（Buoyant首席执行官）和Oliver Gould（Buoyant首席技术官）创建，初衷是将Finagle强大的RPC集群通信与服务治理能力标准化和产品化，摆脱JVM系的限制，提供给更多的用户使用。
Linkerd作为下一代云应用的基础网络层，通过自动化负载均衡、服务发现和运行时恢复能力等诸多特性，使得企业能够在不牺牲可靠性的情况下将其计算架构平滑地从单体服务转移到微服务架构，Linkerd提供如下主要特性。
1） 高性能、高扩展性的集群通信能力 。每秒以最小的时延及负载处理万级数量的请求，Linkerd 2.0的数据平面当前大小仅为10MB左右，并且99.9%的请求耗时小于1ms；部署方便，业务代码和配置不需要任何修改，特别方便水平扩展。
2） 支持多种服务发现方式，并且扩展非常方便 。支持各种服务发现机制，如基于文件（File-based）、ZooKeeper、Consul及Kubernetes；增加自定义的服务发现机制比较方便，扩展性强。
3）强大的负载均衡算法支持。推荐使用基于感知时延的负载均衡算法，通过实时统计数据RPC延迟、要处理请求队列大小决定如何分发请求，反馈实时性强，能够根据当前的实时压力情况调整负载；内置多种负载均衡算法，可以根据实际场景灵活选用。
4）完善的多协议支持。支持HTTP 2.0、HTTP 1.1、gRPC、Thrift多种协议。
5）动态路由。针对HTTP协议，支持多种路由策略；支持动态路由机制，可以通过动态修改路由规则实现蓝绿部署、金丝雀部署、流量迁移等；
6）内置完善的log/Metric/Trace。Linkerd通过收集服务间通信的各种统计数据，构建起强大的仪表盘，具体包含每个服务当前的运行状态，请求的成功率，系统的实时拓扑等。
7）多平台支持。Linkerd通过收集服务间通信的各种统计数据，构建起强大的仪表盘，具体包含每个服务当前的运行状态，请求的成功率，系统的实时拓扑等。
Linkerd诞生后，以其简单易用的使用方式和强大的服务治理能力，一段时间内成为Service Mesh技术领域的旗帜和标杆，当然Linkerd自身也有不少缺点，其中最突出的问题就是： Linkerd的部署模型过重 ，设计过程中很少考虑有限资源情况下基于Sidecar模式的Kubernetes部署方式，制约了Linkerd的进一步发展；加上面对后起之秀Lstio/Envoy强大的竞争压力，Buoyant给出的答案是利用Linkerd已经超过18个月的生产级Service Mesh经验，快速推出功能完备又可以在低资源环境下运行的Service Mesh，为了不给Linkerd生产环境下的众多用户带来困扰，Buoyant决定启动一个和Linkerd并列的全新项目，这就是Conduit。
Conduit的目标是成为最快、最轻、最简单并且最安全的Service Mesh。Conduit使用Rust构建了快速、安全的数据平面，用Go开发了简单强大的控制平面，总体设计围绕着性能、安全性和可用性进行。同时与Linkerd支持Kubernetes、Mesos等多个调度平台不同，Conduit更为聚焦，只提供对Kubernetes的支持。
在分别运维了两个项目仅仅7个月之后，Buoyant团队觉得Conduit“配得上Linkerd这个名字”，因此Conduit 0.5版本成为Conduit的最后一个主要版本，Conduit后续逐步整合进Linkerd项目，成为Linkerd 2.0的基础继续存在。
2018年9月，Linkerd 2.0发布，Conduit正式并入Linkerd项目，Conduit作为一个存在不到一年的短暂项目，变成了历史。
当前，Linkerd项目以Linkerd 1.x和Linkerd 2.x的方式存在，并行开发，Linkerd 1.x相当于Conduit诞生之前的Linkerd；Linkerd 2.x继续承接类似Conduit的角色，只不过换了个名字。Buoyant正在和社区制定相应的迁移路线图，逐步将Linkerd 1.x的存量用户迁移到Linkerd 2.x。
Conduit是为了对抗Istio而诞生，为了构建和Istio相抗衡的Service Mesh生态体系，Conduit退出舞台也标志着Buoyant退出了Service Mesh生态的想法，后续Service Mesh生态只有Istio一家独大了。后续Linkerd的定位会朝Service Ops方向发展，提供Service Mesh生态体系中一些具体的解决方案。
Linkerd 2.0推出了一个重要的功能，就是Linkerd以“Service Sidecar”的方式独立部署，无须集群范围的安装，即可增强单个服务的集群管理和服务治理功能，并且整个过程对服务没有任何侵入。
从当前看，Linkerd后续可能会两条路线并存。一条路线是提供包含数据平面和控制平面在内的全套轻量级Service Mesh解决方案，这个过程中不做平台，不再强调可扩展性，直接提供用户需要的功能，解决用户的痛点问题，并且特别轻量，不需要用户过多地选择，卖点就是轻量；另一条路线是融入Istio生态体系中，仅提供数据平面。
路由机制（见图3-2）是Linkerd的核心，Linkerd的主要工作就是收到一个请求消息，然后将该请求消息转发到合适的目的节点，这个过程中主要由服务识别（Identification）、绑定（Binding）、解析（Resolution）和负载均衡4个主要步骤组成，其中识别、绑定、解析属于路由管理的范畴。
图3-2 Linkerd路由工作机制示意图
识别是指根据请求确定请求调用服务的过程，识别阶段的输出是service name，识别过程是根据识别类型，从请求消息生成一个特定的字符串，这个字符串与随后和这个请求关联，Linkerd路由会有一个默认前缀/svc，Linkerd会将默认前缀加上这个字符串作为本次请求的路由标识往后传递，对于HTTP请求来说，Linkerd默认情况下使用一个io.l5d.header.token类型的标识，它使用HTTP请求头中的Host字段作为标识，比如curl-H"Host：data"http://example/hello，路由标识时被转换为/svr/data。
同时，识别是一个可扩展的插件，用户可以使用自定义的识别逻辑，将请求按照自己的意愿转换到相应的识别。
通过识别阶段确定了service name之后，由dtab组件根据service name绑定，确定目标服务的集群名称。绑定阶段输出的是client name，client name是目标集群的名称，类似于DNS的域名，和service name只包含目标服务信息不同，client name中还包含集群、区域以及环境等信息。
dtab负责对绑定规则进行管理，比如dtab规则配置如下：/svc=>/#/io.l5d.fs，我们的/svc/test被转换为：/#/io.l5d.fs/test，client name一般以“/$”或者“/#”开头。
绑定是Linkerd中变化非常多的一个阶段，Linkerd中的很多场景需求，比如蓝绿测试、小流量灰度等均通过绑定来实现。
解析是服务发现的过程，通过named组件将目标集群名称client name转换成一组可用的节点，Linkerd会通过配置文件配置当前使用的服务发现方式，确定服务发现方式后，就可以根据client name，从服务发现中获取节点信息。
回顾上述Linkerd路由查找的整个过程，就是一个根据请求获取被调用服务名，然后根据路由规则从服务名获取对应的服务集群名，最后根据服务发现获取可用节点的过程。其中dtab和named组件分别负责路由规则和服务发现的管理。上面的讨论中，dtab与named和linkerd集成在一个进程中，默认情况下，配置在Linkerd中的dtab路由规则是Linkerd启动时解析，运行时无法动态修改。
为了解决dtab无法动态修改的问题，更好地进行路由规则管理，Linkerd将dtab从linkerd代理中剥离出来，形成一个独立的服务named，named服务独立部署，灵活支持各种路由规则的动态修改和下发。
从上面的Linkerd演进可以看出，Linkerd从诞生到现在虽然时间不算长，战略、定位和架构均发生了不少的变化，下面以Linkerd 2.X版本为例，介绍Linkerd当前的架构。
架构层面，Linkerd也是分为控制平面和数据平面，其中控制平面由下面几个部分组成。
1）Controller控制器：控制器由负责不同控制功能的多个容器组成，主要包括public-api、proxy-api、destination和tap，其中public-api负责Linkerd对外的API交互；
2）Web：Web是Linkerd提供的仪表板；
3）Prometheus：Prometheus负责Linkerd Metric信息的收集和存储；
4）Grafana：Grafana负责Linkered的可视化。
Linkered的数据平面采用的是Rust语言实现的轻量级高性能Proxy代理，通过配置Iptables，它可以透明地管理Kubernetes Pod的入口和出口流量，甚至可以对一个正在运行中的服务透明无感知地添加Linkered代理。Linkered支持HTTP、HTTP/2和TCP协议，通过按需诊断tap API，Linkered拥有强大的可视化监控和诊断能力。
从Linkered的整体架构看，Linkered已经完全舍弃了打造Service Mesh平台的想法，内置具体的统计和可视化组件，聚焦为用户提供开箱即可的Service Mesh能力，当前Linkered确实已经非常轻量，对于没有特别要求的通用场景，Linkered还是一个不错的选择。