引言：

各個(gè)細(xì)分行業(yè)和領(lǐng)域的組織機(jī)構(gòu)正在持續(xù)的加速采用微服務(wù)架構(gòu)。隨之而來(lái)的是容器的使用以及端點(diǎn)和服務(wù)通信的爆炸式增長(zhǎng)。企業(yè)內(nèi)部的復(fù)雜性和不確定性正在不斷增加。如何在這樣的情況下實(shí)現(xiàn)對(duì)規(guī)模化通信安全性和可見(jiàn)性的管理頗具挑戰(zhàn)。因此，無(wú)論是運(yùn)營(yíng)者或者開(kāi)發(fā)者都強(qiáng)烈渴望將網(wǎng)絡(luò)層的復(fù)雜性封裝為一個(gè)新的網(wǎng)絡(luò)基礎(chǔ)架構(gòu)層。當(dāng)此之時(shí)，處理此事的最流行的方式是服務(wù)網(wǎng)格（Service Mesh）。

因此，在本文中，我們將對(duì)比兩種主流的服務(wù)網(wǎng)絡(luò)的特性，以找出兩者的異同之處，即Linkerd和Istio。文中也會(huì)提及有關(guān)服務(wù)網(wǎng)格使用的爭(zhēng)論，探尋在某種特定的場(chǎng)景下，基于特定的用例和架構(gòu)，何者比何者更具優(yōu)勢(shì)。

一、服務(wù)網(wǎng)格是什么？

服務(wù)網(wǎng)格是一個(gè)專有的基礎(chǔ)設(shè)施層，這一層級(jí)的存在可以使得微服務(wù)架構(gòu)內(nèi)部的服務(wù)間通信更加可靠、快捷和安全。其基本的理念是在服務(wù)間插入一個(gè)代理組成的網(wǎng)絡(luò)來(lái)實(shí)現(xiàn)對(duì)網(wǎng)絡(luò)層的抽象。一言以蔽之，服務(wù)網(wǎng)格的設(shè)計(jì)初衷就是幫助開(kāi)發(fā)者解決微服務(wù)間的交互挑戰(zhàn)。

二、Istio是什么？

Istio是由Google、IBM和Lyft發(fā)起的開(kāi)源的服務(wù)網(wǎng)格項(xiàng)目。該項(xiàng)目在2017年推出，并在2018年7月發(fā)布了1．0版本。Istio基于Envoy代理并以之為數(shù)據(jù)層（data plane）。可以說(shuō)Istio是如今最炙手可熱的服務(wù)網(wǎng)格，但由于僅應(yīng)用于Kubernetes，其應(yīng)用價(jià)值受到某種限制。

三、Linkerd是什么？

Linkerd（音似chickadee），最初是由Buoyant團(tuán)隊(duì)于2016年打造的一個(gè)服務(wù)網(wǎng)格項(xiàng)目。Linkerd是CNCF的官方項(xiàng)目，基于Twitter的Finagle項(xiàng)目并和后者一樣，最初是由Scala語(yǔ)言編寫，設(shè)計(jì)理念是支持基于主機(jī)（物理主機(jī)或者虛擬節(jié)點(diǎn)）的部署模式。由于最初版本的內(nèi)存占用廣受詬病，導(dǎo)致了Conduit項(xiàng)目的開(kāi)發(fā)，Conduit是一個(gè)輕量級(jí)的服務(wù)網(wǎng)格，為Kubernetes定制，用Rust和Go語(yǔ)言編寫。Conduit項(xiàng)目目前已經(jīng)合并到Linkerd項(xiàng)目，并在2018年7月發(fā)布為L(zhǎng)inkerd 2．0 版本。鑒于Linkerd 2．x 基于Kubernetes，而Linkerd 1．x 可以基于節(jié)點(diǎn)的模式部署，當(dāng)面臨復(fù)雜環(huán)境的場(chǎng)景時(shí)，人們可以有更靈活的選擇。除非特指，本文的比較都是基于Linkerd 2．x。

四、特性和功能對(duì)比

架構(gòu)

Istio和Linkerd都支持以主流的外掛（Sidecar）模式部署。在這種模式下，每個(gè)微服務(wù)都被分配一個(gè)單獨(dú)的代理。微服務(wù)間的通信并不直接進(jìn)行，而是通過(guò)自身的代理轉(zhuǎn)發(fā)。代理會(huì)將請(qǐng)求路由到目標(biāo)微服務(wù)的代理，該代理再將請(qǐng)求轉(zhuǎn)發(fā)到目標(biāo)微服務(wù)。所有這些服務(wù)代理構(gòu)成了數(shù)據(jù)層。在服務(wù)網(wǎng)格的架構(gòu)下，數(shù)據(jù)層由控制層（control plane）來(lái)進(jìn)行配置和監(jiān)控，控制層一般另行獨(dú)立部署。

架構(gòu)圖示意：以Istio為例。Envoy代理以外掛形式部署。在這樣的部署模型中，代理將注入每個(gè)容器單元，因此可以獨(dú)立的配置。Istio控制層由很多的組件組成，用來(lái)對(duì)服務(wù)間通信進(jìn)行配置、度量、控制和安全管控。

控制層

控制層的使命是通過(guò)一系列API和工具對(duì)服務(wù)網(wǎng)格內(nèi)的代理實(shí)現(xiàn)控制。在控制層中，可以將整個(gè)數(shù)據(jù)層作為一個(gè)整體來(lái)指定認(rèn)證策略，收集度量指標(biāo)，進(jìn)行配置。

Istio的控制層由三個(gè)組件構(gòu)成。首先是Pilot，負(fù)責(zé)配置數(shù)據(jù)層。其次是Mixer，負(fù)責(zé)收集通信流量的度量指標(biāo)，并響應(yīng)數(shù)據(jù)層各種不同的查詢請(qǐng)求，包括授權(quán)、訪問(wèn)控制和配額查詢等。基于所啟用的適配器的不同，Mixer也可與日志和監(jiān)控系統(tǒng)進(jìn)行對(duì)接。最后是Citadel，這個(gè)組件允許開(kāi)發(fā)者基于服務(wù)身份認(rèn)證而非網(wǎng)絡(luò)控制建立一個(gè)零信任（零信任，zero－trust，簡(jiǎn)單講，即假定所有通信方不可信賴并必須進(jìn)行驗(yàn)證）機(jī)制的網(wǎng)絡(luò)環(huán)境。Citadel負(fù)責(zé)為每個(gè)服務(wù)指定證書(shū)，如果有需要，也可以接受外部的證書(shū)授權(quán)密鑰。

白小白：

Linkerd的控制層由一個(gè)Web組件、一個(gè)控制組件和一個(gè)度量組件組成。Web組件提供了基于Web的管理控制面板。控制組件由多個(gè)容器部署組成。完成了控制層的多數(shù)功能（包括聚合遙測(cè)數(shù)據(jù)，提供用戶界面API，為數(shù)據(jù)層提供控制數(shù)據(jù)等）。度量組件由定制化的Prometheus和Grafana組成。Prometheus負(fù)責(zé)抓取Linkerd暴露的度量指標(biāo)并儲(chǔ)存下來(lái)。Linkerd本身會(huì)生成很多外部面板，Grafana負(fù)責(zé)渲染和展現(xiàn)這些面板。

數(shù)據(jù)層

在一個(gè)典型的服務(wù)網(wǎng)格環(huán)境中，服務(wù)的部署過(guò)程將納入一個(gè)專有的外掛代理。如前文所述，服務(wù)并不直接向網(wǎng)絡(luò)傳遞消息，而是由本身的代理來(lái)進(jìn)行通信。這樣的機(jī)制封裝了服務(wù)間通信的復(fù)雜性。服務(wù)網(wǎng)格內(nèi)的代理之間相互連接，構(gòu)成了數(shù)據(jù)層。

默認(rèn)情況下，Istio使用Envoy作為數(shù)據(jù)層，Envoy原本是設(shè)計(jì)用來(lái)與其他類型的代理（比如Nginx）來(lái)進(jìn)行工作的。Linkerd使用自有的代理。

平臺(tái)支持

盡管聲稱支持大量的環(huán)境和框架，但在實(shí)踐中，Istio僅能與kubernetes相處融洽，這嚴(yán)重限制了他的應(yīng)用范疇。

Linkerd 2．x目前也需要與Kubernetes協(xié)同工作。然而Linkerd 1．x 部署廣泛，并處于活躍的研發(fā)狀態(tài)，可以在多種環(huán)境和框架下工作，包括與AWS ECS、DC／OS和Docker協(xié)同工作。能夠支持如此廣泛的環(huán)境，得益于Linkerd 1．x 可以基于主機(jī)的部署模式，這使得其可以與用戶的環(huán)境進(jìn)行整合而無(wú)需以外掛的形式部署。

Linkerd 1．x 主機(jī)部署模式：linkerd服務(wù)網(wǎng)格可以基于主機(jī)部署。基于這樣的模式，同一主機(jī)的多個(gè)微服務(wù)共享一個(gè)Linkerd（1．x）實(shí)例。

主機(jī)部署模式的主要缺點(diǎn)在于單點(diǎn)代理的失敗將影響多個(gè)微服務(wù)。從另一方面講，主機(jī)部署模式相對(duì)于外掛模式對(duì)資源的消耗更低。

協(xié)議支持

基于外掛代理，Istio和Linkerd 2．x 都支持HTTP 1．1， HTTP2， gRPC和TCP協(xié)議的服務(wù)間通信。但Linkerd 1．x 不支持TCP連接。

實(shí)現(xiàn)語(yǔ)言

Istio的控制層和Linkerd 2．x 都是用Go語(yǔ)言編寫的，Istio數(shù)據(jù)層的Envoy代理是由C＋＋編寫的，Linkerd 2．x 的數(shù)據(jù)層是用Rust編寫的。Linkerd 1．x 是用Scala編寫的。

安全、加密和授權(quán)

Istio的控制層組件提供了如下的安全功能：Citadel：密鑰和證書(shū)管理。Pilot：認(rèn)證策略和安全命名信息的分發(fā)。Mixer：授權(quán)和審計(jì)的管理。外掛：實(shí)現(xiàn)代理間基于TLS加密的安全通信。

本文成文時(shí)，Linkerd的自動(dòng)化的TLS加密還處于實(shí)驗(yàn)階段，主機(jī)間認(rèn)證也還未獲支持。

外掛注入

將外掛加入到部署包并且在服務(wù)網(wǎng)格的控制層進(jìn)行注冊(cè)的過(guò)程即為“外掛注入”。Istio和Linkerd都支持手動(dòng)和自動(dòng)的外掛注入。

高可用性

Istio支持高可性，當(dāng)且僅當(dāng)配置了Kubernetes的多副本模式，并且打開(kāi)podAntiAffinity開(kāi)關(guān)的情況下。

linkerd的高可用性目前仍處于實(shí)驗(yàn)階段。

監(jiān)控和跟蹤

Istio原生支持Prometheus并且集成了Jaeger來(lái)進(jìn)行分布式跟蹤。Linkerd支持Prometheus和Grafana從外部進(jìn)行監(jiān)控，但目前并不支持分布式跟蹤。

性能

Linkerd 2．x 在性能上的常規(guī)開(kāi)銷總體上比Istio要低一些。一項(xiàng)關(guān)于兩者的性能測(cè)試表明，基于一組由HTTP請(qǐng)求組成的測(cè)試負(fù)載，每秒的千次查詢數(shù)（kqps）基準(zhǔn)值是30－35kqps，經(jīng)由代理轉(zhuǎn)發(fā)后，性能會(huì)有所下降，Linkderd降到了10－12kqps，而Istio則降到了3．2－3．9kqps。

五、什么時(shí)候應(yīng)該謹(jǐn)慎使用服務(wù)網(wǎng)格？

有五個(gè)主要的原因，可能阻止你考慮使用服務(wù)網(wǎng)格來(lái)管理微服務(wù)架構(gòu)所帶來(lái)的潛在的網(wǎng)絡(luò)復(fù)雜性挑戰(zhàn)。

1、服務(wù)網(wǎng)格具有排他性

服務(wù)網(wǎng)格是一個(gè)平臺(tái)解決方案，因此是排他性的。這意味著你將被迫在“服從他們的方式”和“基于我自己的業(yè)務(wù)和技術(shù)考量選擇適合的方式”之間做出選擇。根據(jù)你所處的形勢(shì)，對(duì)服務(wù)網(wǎng)格的前期投資可能十分昂貴。

而且，如果說(shuō)控制應(yīng)用和服務(wù)間通信對(duì)你的組織來(lái)說(shuō)具有戰(zhàn)略性的重要意義的話，那么使用一個(gè)現(xiàn)成的服務(wù)網(wǎng)格就沒(méi)有意義了。這樣或許可以受益于框架成長(zhǎng)帶來(lái)的收益 ，但無(wú)法對(duì)你的目標(biāo)實(shí)現(xiàn)控制。

2、服務(wù)網(wǎng)格具有復(fù)雜性

服務(wù)網(wǎng)格的部署將向你的架構(gòu)引入相當(dāng)可觀的復(fù)雜性。部署過(guò)程需要引入外掛代理，服務(wù)網(wǎng)格需要與現(xiàn)有的環(huán)境進(jìn)行整合并在未來(lái)的時(shí)間里反復(fù)的配置，所有的加密可能需要重新設(shè)計(jì)。基于Kubernetes這樣的平臺(tái)建立服務(wù)網(wǎng)格的實(shí)例，會(huì)要求你不僅是服務(wù)網(wǎng)格的專家，并且是熟悉Kubernetes的專家。

3、服務(wù)網(wǎng)格可能運(yùn)行緩慢

隨著網(wǎng)格的擴(kuò)張和路由表的膨脹，通過(guò)一系列代理進(jìn)行的路由通信將慢的痛苦異常。

4、服務(wù)網(wǎng)格傾向于建立自治的架構(gòu)藍(lán)圖

使用服務(wù)網(wǎng)格來(lái)追蹤服務(wù)間的通信請(qǐng)求并不總是像最初那樣看起來(lái)有價(jià)值。比如，假設(shè)你的微服務(wù)環(huán)境與其他團(tuán)隊(duì)的應(yīng)用和服務(wù)相整合，在跨越不同的技術(shù)團(tuán)隊(duì)和業(yè)務(wù)單元的邊界時(shí)，翻譯不同的追蹤記錄將十分挑戰(zhàn)，如果是企業(yè)級(jí)環(huán)境或者是云端供應(yīng)商的情況下，這種挑戰(zhàn)將更加嚴(yán)峻。

5、服務(wù)網(wǎng)格著眼于開(kāi)發(fā)者層面的考量

服務(wù)網(wǎng)格著眼于典型的開(kāi)發(fā)者視角的服務(wù)間通信問(wèn)題。對(duì)于規(guī)模化且不確定的應(yīng)用和服務(wù)而言，組件之間的交互會(huì)天然衍生一系列的復(fù)雜性，對(duì)這些新興行為的管控，服務(wù)網(wǎng)格無(wú)能為力。