这一次，要聊到服务网格技术Linkerd技术了。其实在前面讲边缘代理网关Envoy时，就已经讲了服务网格的概念了。
而且，当聊起Linkerd时，也不能不涉及到Envoy这个技术。云原生架构中的服务网格技术选择时，主流的选择方案就是两种：
- • 选择Istio envoy搭配实现服务网格
- • 选择
Linkerd来实现服务网格
什么是服务网格
服务网格是微服务架构以及基于微服务实现的云原生架构越发流行之后自然衍生出的需求与技术。
随着服务越来越小，服务越来越多，这种微服务模式在带来灵活性的同时，也带来了很多复杂度，其中一个就是服务间相互的请求成指数级增长
于是，对服务间请求的管理，监控与优化就变得非常重要。也就是，对于微服务，技术上需要做到：
- • 提升服务间请求的可靠性，比如通过重试，超时，断路器等方式
- • 服务请求间的数据安全，比如通过加密等
- • 对网络请求数据的监控与信息收集
虽然我们可以通过架构这个层面，使用一些技术来做到，但在云原生架构中，类似K8S这样的平台，提供了解决方案，这就是服务网格
Istio与Linkerd
在以K8S为核心的云原生架构实践中，服务网格的主流选择主要就是Istio与Linkerd了。其中，Istio是前辈，占有更大的市场份额，而Linkerd是后来者，具有一些独特的优势，它的使用率越来越高，在一些地区，比如北美，其使用占比已经高于Istio。
有一点需要指出的是，在服务网格的实现中，有两个角色，一个是Data Plane，一个是Control Plane。
- • Control Plane是控制角色，负责监控，下发配置以及承担管理等能力
- • Data Plane是实施者，以边车服务(Sidecar)的方式集成在POD中，实现诸如流量，重试，负载及超时等实际服务网格能力。但它受Control Plane控制。
而Istio并不是一个完整的服务网格实现，它只承担Control Plane的能力，因此需要与Envoy搭配使用，由Envoty来承担Data Plane的能力。
与之不同的是，Linkerd是一个独立的完整的服务网格实现，它内部包含了Linkerd2-proxy的微代理实现，用来做Data Plane。但与Envoty不同的是，Linkerd2-proxy不是一个独立的框架或能力，是Linkerd的一部分，是一个微代理，但Envoy则是一个独立的完整的网络代理框架，可独立使用。
选择与区别
因此，关于Linkerd，在知道它是一个服务网格实现之后，最关键的是说清楚它与Istio的异同，以便能做出合适的选择。
Linkerd是完整的服务网格实现，Istio则需要与Envoy搭配
前文已经阐述过了，实现服务网格的能力，Linkerd是一个完整的技术实现，它内部包含一个微代理实现Linkerd2-proxy，不需要额外的技术搭配就能做到。
与之不同的是，Istio只承担Control Plane的能力，它需要与Envoy搭配协作才能实现服务网格的能力。而无论是Envoy还是Istio，它们都是独立的技术组件。
Linkerd是CNCF官方项目，而Istio则不是
Istio其实有一个非常尴尬的处境。就是Istio本身并不是CNCF的官方项目之一，而它搭配的Envoy却是CNCF的官方项目之一。
但Linkerd则是CNCF的官方项目之一。
好吧，这有什么影响么？我认为官方项目总会得到更多的照顾与使用，前景也许会更好？
Linkerd更易于使用，而Istio则较为复杂
Istio也好，Envoy也好，都是独立的技术组件，且不仅是支持K8S云原生架构，在非K8S场景中也能用到，所以相对而言它们的功能更复杂。这也导致它们的配置非常复杂，在K8S中使用与配置它们的学习曲线相对较高。
而Linkerd的思维则不同，它纯粹是为支持K8S而生的技术，使用Linkerd时，甚至你都不需要意识到背后的Linkerd2-proxy的存在，也不存在太多复杂的配置。
因此，在使用上，Linkerd更容易，而Istio则相对较为复杂。
Linkerd的性能更优
Linkerd在实现之初，就是为了提供一个轻量，高性能的服务网格为目标。之所以不使用Envoy，而自己基于Rust写了一个Linkerd2-proxy这么一个它们微代理的组件，也是因为基于Rust实现，所以更轻，性能表现更佳，在内存占用上更小。
用数据来说话， Linkerd2-proxy的内存占用在15M左右，而Envoy则在135-175M左右，而在CPU资源占用上， Linkerd2-proxy每实例占用约15ms，而Envoy则在22~156ms范围。
Linkerd是更轻量，性能更佳的实现
Istio使用率高于Linkerd，但趋势在改变
Linkerd2是2019年才重写并发布出来的（基于Go语言，而 Linkerd2-proxy则是基于Rust语言），意味着到现在为止，也仅仅3年左右的时间。
由于Linkerd是后来者，虽然它提供了更轻，性能更佳的实现，但从时间上并不具备优势。而Istio则存在更久，在Linkerd2出来并得到广泛的认同之前，Istio几乎是唯一主流的选择。
但这个趋势在改变，据2022年初CNCF的调查数据显示，在北美以及欧州，Linkerd2的使用占比已经高于Istio，而在亚州，Istio仍然是主流。
选择
其实，无论是Istio或是Linkerd，都是实现服务网格的非常好的选择。Istio可能仍然是更主流的一个选择，但Linkerd的未来可能更具前景，因为它更简单，易于使用，及性能更佳。
但不管选择哪一个，最重要的是要理解，在云原生架构中，平台有了服务网格的能力，可以在平台层面帮我们实现服务间交互的重试，超时，流量以及负载，网络数据监控与收集，这些能力都可以上交给平台层来负责与实现。
这会让我们的微服务中的每一个服务都能更专注于业务，更不需要去关注技术上的点。这也是云原生架构的优势与未来架构的发展的趋势。
