什么是服務網(wǎng)格
服務網(wǎng)格近年來有很高的話題度，背后的原因是什么？
2017年底，非侵入式的 Service Mesh 技術從萌芽到走向了成熟。
Service Mesh 又譯作“服務網(wǎng)格”，作為服務間通信的基礎設施層。
如果用一句話來解釋什么是 Service Mesh，可以將它比作是應用程序或者說微服務間的 TCP/IP，負責服務之間的網(wǎng)絡調用、限流、熔斷和監(jiān)控。對于編寫應用程序來說一般無須關心 TCP/IP 這一層（比如通過 HTTP 協(xié)議的 RESTful 應用），同樣使用 Service Mesh 也就無須關系服務之間的那些原來是通過應用程序或者其他框架實現(xiàn)的事情，比如 Spring Cloud、OSS，現(xiàn)在只要交給 Service Mesh 就可以了。
微服務已經(jīng)成為一種靈活快速的開發(fā)方式。然而，隨著微服務數(shù)量成倍數(shù)地增長，開發(fā)團隊開始遇到了部署和擴展性上的問題。
容器和 Kubernetes 這樣的容器編排系統(tǒng) ，將運行時和服務一起打包進鏡像，調度容器到合適的節(jié)點，運行容器。這個方案可以解決開發(fā)團隊遇到的不少問題。然而，在這個操作流程中仍存在短板：如何管理服務間的通信。
在采用服務網(wǎng)格的場景下，以一種和應用代碼解耦的方式，增強了應用間統(tǒng)一的網(wǎng)絡通信能力。服務網(wǎng)格擴展了集群的管理能力，增強可觀測性、服務發(fā)現(xiàn)、負載均衡、IT 運維監(jiān)控及應用故障恢復等功能。
服務網(wǎng)格概覽
服務網(wǎng)格一直有很高的熱度。正如 Linkerd 的作者 William Morgan 所提到的：“服務網(wǎng)格本質上無非就是和應用捆綁在一起的用戶空間代理。” 此說法相當簡潔，他還補充道，“如果你能透過噪音看清本質，服務網(wǎng)格能給你帶來實實在在的重要價值?！?/p>
Envoy 是許多服務網(wǎng)格框架的核心組件，是一個通用的開源代理，常被用于 Pod 內的 sidecar 以攔截流量。也有服務網(wǎng)格使用另外的代理方案。
若論具體服務網(wǎng)格方案的普及程度，Istio 和 Linkerd 獲得了更多的認可。也有其它可選項，包括 Consul Connect，Kuma，AWS App Mesh和OpenShift。下文會闡述9種服務網(wǎng)格提供的關鍵特性。
Service Mesh 的來龍去脈：
從最原始的主機之間直接使用網(wǎng)線相連
網(wǎng)絡層的出現(xiàn)
集成到應用程序內部的控制流
分解到應用程序外部的控制流
應用程序的中集成服務發(fā)現(xiàn)和斷路器
出現(xiàn)了專門用于服務發(fā)現(xiàn)和斷路器的軟件包/庫，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，這時候還是集成在應用程序內部
出現(xiàn)了專門用于服務發(fā)現(xiàn)和斷路器的開源軟件，如 Netflix OSS、Airbnb 的 synapse 和 nerve
最后作為微服務的中間層 Service Mesh 出現(xiàn)
Service Mesh 有如下幾個特點：
應用程序間通訊的中間層
輕量級網(wǎng)絡代理
應用程序無感知
解耦應用程序的重試/超時、監(jiān)控、追蹤和服務發(fā)現(xiàn)
1、Istio
Istio 是基于 Envoy 構建的一個可擴展的開源服務網(wǎng)格。開發(fā)團隊可以通過它連接、加密、管控和觀察應用服務。Istio 于 2017 年開源，目前 IBM、Google、Lyft 仍在對其進行持續(xù)維護升級。Lyft 在 2017 年把 Envoy 捐贈給了 CNCF。
Istio 花了不少時間去完善增強它的功能特性。Istio 的關鍵特性包括負載均衡、流量路由、策略創(chuàng)建、可度量性及服務間認證。
Istio 有兩個部分組成：數(shù)據(jù)平面和控制平面。數(shù)據(jù)平面負責處理流量管理，通過 Envoy 的 sidecar 代理來實現(xiàn)流量路由和服務間調用?？刂破矫媸侵饕砷_發(fā)者用來配置路由規(guī)則和觀測指標。
Istio 觀測指標是細粒度的屬性，其中包含和服務行為相關的特定數(shù)據(jù)值。下面是個樣例：
request.path: xyz/abc request.size: 234 request.time: 12:34:56.789 04/17/2017 source.ip: [192 168 0 1] destination.service.name: example
與其他服務網(wǎng)格相比，Istio 勝在其平臺成熟度以及通過其 Dashbaord
著重突出的服務行為觀測和業(yè)務管理功能，然而也因為這些高級特性和復雜的配置流程，Istio 可能并不如其它一些替代方案那樣容易上手。
istio的特性：
istio 提供一種簡單的方式來為已部署的服務建立網(wǎng)絡，該網(wǎng)絡具有負載均衡、服務間認證、監(jiān)控等功能，而不需要對服務的代碼做任何改動。想要讓服務支持istio，只需要在您的環(huán)境中部署一個特殊的 sidecar 代理，使用 istio 控制平面功能配置和管理代理，攔截微服務之間的所有網(wǎng)絡通信：
HTTP、gRPC、WebSocket 和 TCP 流量的自動負載均衡。
通過豐富的路由規(guī)則、重試、故障轉移和故障注入，可以對流量行為進行細粒度控制。
可插入策略層和配置 API，支持訪問控制、速率限制和配額。
對出入集群入口和出口中所有流量的自動度量指標、日志記錄和跟蹤。
通過強大的基于身份的驗證和授權，在集群中實現(xiàn)安全的服務間通信。
istio 旨在實現(xiàn)可擴展性，滿足各種部署需求。
istio優(yōu)勢：
集群規(guī)模可視性：在故障狀況出現(xiàn)時，運營人員需要利用多種工具以始終關注集群運行狀況并分析微服務狀態(tài)圖表。
彈性與效率：在開發(fā)微服務時，運營人員需要假設網(wǎng)絡本身處于不可靠狀態(tài)。運營人員能夠利用重試、負載均衡、流量控制（HTTP/2）以及斷路補償?shù)确绞浇鉀Q由網(wǎng)絡可靠性低下所造成的各類常見故障模式。Istio 項目則提供一種統(tǒng)一方法以配置上述功能，使得運營人員能夠更為輕松地運作高彈性水平服務網(wǎng)格。
開發(fā)人員生產(chǎn)力：Istio 項目能夠確保開發(fā)人員專注于利用已選擇的編程語言構建服務功能，從而極大提升其生產(chǎn)能力。
政策驅動型運營：Istio 項目能夠授權具有不同職能的團隊以實現(xiàn)獨立運作。
默認安全：分布式計算當中經(jīng)常存在著大量網(wǎng)絡安全問題。Istio 項目允許運營人員利用 TLS 連接以認證并保護各服務之間的所有通信，而不會給開發(fā)人員或者運營人員帶來由證書管理造成的額外負擔。其安全框架與新的 SPIFFE 規(guī)范保持一致，事實上谷歌公司一直在內部廣泛使用類似的保障性系統(tǒng)。
增量化采用：在設計 Istio 項目時充分考慮到網(wǎng)絡內所運行各服務的透明性，允許團隊隨著時間推移逐步采用 Istio 提供的各項功能。
2、Linkerd
Linkerd是Buoyant公司2016年率先開源的高性能網(wǎng)絡代理，是業(yè)界的第一款Service Mesh框架。其主要用于解決分布式環(huán)境中服務之間通信面臨的一些問題，如網(wǎng)絡不可靠、不安全、延遲丟包等問題。
按照官網(wǎng)的說法，Linkerd 是一個輕量級、安全優(yōu)先的 Kubernetes 服務網(wǎng)格。它的創(chuàng)建流程快到讓人難以置信（據(jù)稱在 Kubernetes 安裝只需要 60 秒），這是大多數(shù)開發(fā)者喜聞樂見的。Linkerd 并沒有采用基于 Envoy 的構建方案。而是使用了一個基于 Rust 的高性能代理 linkerd2-proxy，這個代理是專門為 Linkerd 服務網(wǎng)格編寫的。
Linkerd 由社區(qū)驅動，是 100% 的 Apache 許可開源項目，它還是 CNCF 孵化項目。Linkerd 始于 2016 年，維護者也花了不少時間去解決其中的缺陷。
使用 Linkerd 服務網(wǎng)格，應用服務可以增強其可靠性、可觀測性及其在 Kubernetes 上部署的安全性。舉個例子，可觀測性的增強可以幫助用戶解決服務間的延遲問題。使用 Linkerd 不要求用戶做很多代碼調整或是花費大量時間寫 YAML 配置文件?？煽康漠a(chǎn)品特性和正向的開發(fā)者使用回饋，使得 Linkerd 成為服務網(wǎng)格中一個強有力的競爭者。
Linkerd使用Scala語言編寫，運行于JVM，底層基于Twitter的Finagle庫，并對其做了相應的擴展。最主要的是Linkerd具有快速、輕量級、高性能等特點，每秒以最小的延遲及負載處理萬級請求，易于水平擴展。除此之外，還有以下功能：
支持多平臺：可運行于多種平臺，比如Kubernetes、DC/OS、Docker，甚至虛擬機或物理機。
無縫集成多種服務發(fā)現(xiàn)工具。
支持多協(xié)議，如gRPC、HTTP/1.x、HTTP/2，甚至可通過linkerd-tcp支持TCP協(xié)議。
支持與第三方分布式追蹤系統(tǒng)Zipkin集成。
靈活性、擴展性高，可通過其提供的接口開發(fā)自定義插件。
目前，Linkerd和Linkerd2并行開發(fā)，其情況如下：
Linkerd：Linkerd使用**Scala語言編寫**，運行于JVM，底層基于Twitter的Finagle庫，并對其做了相應的擴展。
Linkerd2：使用Go語言和Rust語言完全重寫了Linkerd，專門用于Kubernetes。
3、Consul Connect
Consul Connect 是來自 HashiCorp 的服務網(wǎng)格，專注于路由和分段，通過應用級的 sidecar 代理來提供服務間的網(wǎng)絡特性。Consult Connect 側重于應用安全，提供應用間的雙向 TLS 連接以實現(xiàn)授權和加密。
Consult Connect 獨特的一點是提供了兩種代理模式。一種是它內建的代理，同時它還支持 Envoy 方案。Connect 強調可觀測性，集成了例如 Prometheus 這樣的工具來監(jiān)控來自 sidecar 代理的數(shù)據(jù)。Consul Connect 可以靈活地滿足開發(fā)者使用需求。比如，它提供了多種方式注冊服務：可以從編排系統(tǒng)注冊，可以通過配置文件，通過 API 調用，或是命令行工具。
Consul Connect 的特性，使網(wǎng)絡管理變得與規(guī)模無關，并且您不需要顯著修改應用程序來保護傳輸中的數(shù)據(jù)。Connect 允許工程師具有更簡單的網(wǎng)絡拓撲，并可以在分布式應用環(huán)境中維護網(wǎng)絡性能。
Consul Connect 讓網(wǎng)絡管理更簡單:
Sidecar 代理: 將TLS通信帶到您的服務中，不依賴任何應用程序，也不需要修改應用程序。
Service Access Graph: 讓操作員對于有操作權限的服務通信可進行集中的，與規(guī)模無關的控制。
Consul Connect 更安全:
自動流量加密：具有相互的TLS和低信任的姿。
證書管理： 在不會中斷服務的情況下使用內置的證書頒發(fā)機構（CA）提供生成、分發(fā)和rotates證書的功能。
雖然對性能影響很小，但是使用Consul的新的本地集成能力（允許用戶在沒有代理的情況下構建連接管理）可以減輕這種影響。
4、Kuma
Kuma 來源于 Kong，自稱是一個非常好用的服務網(wǎng)格替代方案。Kuma 是一個基于 Envoy 的平臺無關的控制平面。Kuma 提供了安全、觀測、路由等網(wǎng)絡特性，同時增強了服務間的連通性。Kuma 同時支持 Kubernetes 和虛擬機。
Kuma 讓人感興趣的一點是，它的企業(yè)版可以通過一個統(tǒng)一控制面板來運維管理多個互相隔離獨立的服務網(wǎng)格。這項能力可以滿足安全要求高的使用場景。既符合隔離的要求，又實現(xiàn)集中控制。
Kuma 也是相對容易安裝的一個方案。因為它預先內置了不少策略。這些策略覆蓋了常見需求，例如路由，雙向 TLS，故障注入，流量控制，加密等場景。
Kuma 原生兼容 Kong，對于那些已經(jīng)采用 Kong API 管理的企業(yè)組織，Kuma 是個非常自然而然的候選方案。
5、Maesh
Maesh 是來自 Containous 的容器原生的服務網(wǎng)格，標榜自己是比市場其它服務網(wǎng)格更輕量級更易用的方案。和很多基于 Envoy 構建的服務網(wǎng)格不同，Maesh 采用了 Traefik， 一個開源的反向代理和負載均衡器。
Maesh 并沒有采用 sidecar 的方式進行代理，而是在每個節(jié)點部署一個代理終端。這樣做的好處是不需要去編輯 Kubernetes 對象，同時可以讓用戶有選擇性地修改流量，Maesh 相比其他服務網(wǎng)格侵入性更低。Maesh 支持的配置方式：在用戶服務對象上添加注解或是在服務網(wǎng)格對象上添加注解來實現(xiàn)配置。
實際上，SMI 是一種新的服務網(wǎng)格規(guī)范格式，對 SMI 的支持 Maesh 獨有的一大亮點。隨著 SMI 在業(yè)界逐漸被采用，可以提高可擴展性和減緩供應商綁定的擔憂。
Maesh 要求 Kubernetes 1.11 以上的版本，同時集群里安裝了 CoreDNS/KubeDNS。這篇安裝指南演示了如何通過 Helm v3 快速安裝 Maesh。
helm repo add maesh https://containous.github.io/maesh/charts helm repo update helm install maesh maesh/maesh
6、ServiceComb-mesher
Apache 軟件基金會形容旗下的 ServiceComb-mesher “是一款用 Go 語言實現(xiàn)的高性能服務網(wǎng)格”。Mesher 基于一個非常受歡迎的 Go 語言微服務開發(fā)框架 Go Chassis[4] 來設計實現(xiàn)。因此，它沿襲了 Go Chassis 的一些特性如服務發(fā)現(xiàn)、負載均衡、錯誤容忍、路由管理和分布式追蹤等特性。
Mesher 采用了 sidecar 方式；每個服務有一個 Mesher sidecar 代理。開發(fā)人員通過 Admin API 和 Mesher 交互，查看運行時信息。Mesher 同時支持 HTTP 和 gRPC，可快速移植到不同的基礎設施環(huán)境，包括 Docker、Kubernetes、虛擬機和裸金屬機環(huán)境。
7、Network Service Mesh（NSM）
Network Service Mesh（NSM）是一款專門為 telcos 和 ISPs 設計的服務網(wǎng)格。它提供了一層級用以增強服務在 Kubernetes 的低層級網(wǎng)絡能力。NSM 目前是 CNCF 的沙箱項目。
根據(jù) NSM 的文檔說明，“經(jīng)常接觸 L2/L3 層的網(wǎng)絡運維人員抱怨說，適合他們的下一代架構的容器網(wǎng)絡解決方案幾乎沒有”。
因此，NSM 在設計時就考慮到一些不同使用場景，尤其是網(wǎng)絡協(xié)議不同和網(wǎng)絡配置混雜的場景。這使得 NSM 對某些特殊場景具備相當吸引力，例如邊緣計算、5G 網(wǎng)絡和 IOT 設備等場景。NSM 使用簡單直接的 API 接口去實現(xiàn)容器和外部端點的之間的通信。
和其他服務網(wǎng)格相比，NSM 工作在另一個不同的網(wǎng)絡層。VMware 形容 NSM“專注于連接”。GitHub 的文檔演示了 NSM 是如何與 Envoy協(xié)同工作的。
8、AWS App Mesh
AWS APP Mesh 為開發(fā)者提供了“適用于不同服務的應用層的網(wǎng)絡”。它接管了服務的所有網(wǎng)絡流量，使用開源的 Envoy 代理去控制容器的流量出入。AWS App Mesh 支持 HTTP/2 gRPC。
AWS App Mesh 對于那些已經(jīng)將容器平臺深度綁定 AWS 的公司而言，會是相當不錯的服務網(wǎng)格方案。AWS 平臺包括 AWS Fargate，Amazon Elastic Container Service，Amazon Elastic Kubernetes Service（EKS），Amazon Elastic Compute Cloud（EC2），Kubernetes on EC2，包括 AWS App Mesh 不需要付額外費用。
AWS App Mesh 和 AWS 生態(tài)內的監(jiān)控工具無縫兼容。這些工具包括 CloudWatch 和 AWS X-Ray，以及一些來自第三方供應商的工具。因為 AWS 計算服務支持 AWS Outposts，AWS App Mesh 可以和混合云和已經(jīng)部署的應用良好兼容。
AWS App Mesh 的缺點可能是使得開發(fā)者深度綁定了單一供應商方案，相對閉源，可擴展性缺失。
9、OpenShift Service Mesh by Red Hat
OpenShift 是來自紅帽的一款幫助用戶“連接、管理、觀測微服務應用”的容器管理平臺。OpenShift 預裝了不少提升企業(yè)能力的組件，也被形容為企業(yè)級的混合云 Kubernetes 平臺。
OpenShift Service Mesh 基于開源的 Istio 構建，具備 Isito 的控制平面和數(shù)據(jù)平面等特性。OpenShift 利用兩款開源工具來增強 Isito 的追蹤能力和可觀測性。OpenShift 使用 Jaeger 實現(xiàn)分布式追蹤，更好地跟蹤請求是如何在服務間調用處理的。
另一方面，OpenShift 使用了 Kiali 來增強微服務配置、流量監(jiān)控、跟蹤分析等方面的可觀測性。
10、Conduit
Conduit 是 Rust 語言開發(fā)的超輕量級 service mesh。
Conduit 的目標是成為最快、最輕、最簡單并且最安全的 Service Mesh。他使用 Rust 構建了快速、安全的數(shù)據(jù)平面，用 Go 開發(fā)了簡單強大的控制平面，總體設計圍繞著性能、安全性和可用性進行。
Conduit 是讓微服務安全可靠的下一代 Service Mesh。他能透明的管理服務之間的通信，自動提供可測性、可靠性、安全性和彈性的支持。還是跟 Linkerd 相仿，他的數(shù)據(jù)平面是在應用代碼之外運行的輕量級代理，控制平面是一個高可用的控制器。然而和 Linkerd 不同的是，Conduit 的設計更加傾向于 Kubernetes 中的低資源部署。
Conduit 的特性：
輕量高速：Conduit 代理只需要不到 10 MB 實際內存（RSS），p99 延遲在分毫秒以內。
安全：Rust 的內存使用相當安全，同時還缺省使用了 TLS，Conduit 的安全性與生俱來。
最小化：Conduit 的特性集被設計為盡量的最小化和可編排，便于使用 gRPC 插件進行定制。
易用性：內置有聚合的服務指標，強大的客戶端工具（想想看，微服務界的 tcpdump），Conduit 為運維人員提供了新的強大的工具來對付生產(chǎn)環(huán)境的微服務。
如何選擇
正如文中所提到的，可供選擇的服務網(wǎng)格方案有很多，同時還有新的方案在涌現(xiàn)。
當然，每一種方案在技術實現(xiàn)上都略有不同。選擇一款合適的服務網(wǎng)格，主要考慮的因素包括，你能接受它帶來多大的侵入性，它的安全性如何，以及平臺成熟度等。
目前比較流行的 Service Mesh 開源軟件有 Linkerd、Envoy 和 Istio，而最近 Buoyant（開源 Linkerd 的公司）又發(fā)布了基于 Kubernetes 的 Service Mesh 開源項目 Conduit。以下幾點可以幫助 DevOps 團隊選擇一款適合他們場景的服務網(wǎng)格：
是否依賴Envoy。Envoy 有一個活躍的社區(qū)生態(tài)。開源，同時是許多服務網(wǎng)格的底座。Envoy 具備的豐富特性使得其成為一個很難繞過的因素。
具體使用場景。服務網(wǎng)格為微服務而生。如果你的應用是一個單體的龐然大物，那你在服務網(wǎng)格上的投入可能達不到預期的收益。如果不是所有應用都部署在 Kubernetes，則應該優(yōu)先考慮平臺無關的方案。
現(xiàn)有容器管理平臺。有些企業(yè)已經(jīng)使用了特定供應商的生態(tài)來解決容器編排問題，例如 AWS 的 EKS，紅帽的 OpenShift，Consul。沿襲原有的生態(tài)，可以繼承并拓展原有的特性。而這些可能是開源方案所不能提供的。
所在行業(yè)。許多服務網(wǎng)格不是為特定行業(yè)專門設計的。Kuma 統(tǒng)一管理多個隔離服務網(wǎng)格的能力可能更適用于收到高度管制的金融行業(yè)。底層網(wǎng)絡 telcos 和 ISPs 則更應該考慮 Network Service Mesh。
對可視化的要求?？捎^測性是服務網(wǎng)格的核心能力之一?？紤]進一步定制和更深度能力的團隊應該優(yōu)先考慮 Istio 或 Consul。
是否遵循開發(fā)標準。遵循開發(fā)標準使得你的平臺更具備前瞻性和可擴展性。這使得企業(yè)會傾向于采用支持 SMI 的方案，Maesh 或其他基金會孵化的項目如 Linkerd。
是否重視用戶體驗?？紤]運維人員的易用性是評判新工具的關鍵指標。這方 Linkerd 似乎在開發(fā)者中間口碑不錯。
團隊準備。評估你的團隊所具備的資源和技術儲備，在技術選型時決定你們適合用基于 Envoy 的 Istio，或是供應商抽象封裝的方案，例如 OpenShift。
這些考慮因素沒有覆蓋到全部場景。此處僅是拋磚引玉，引起讀者的思考。希望讀完上面所列的服務網(wǎng)格清單，和相關的決策因素之后，你們的團隊能找到新的方法去改善微服務應用的網(wǎng)絡特性。
相關閱讀：
Istio項目名稱的由來 http://www.zhongjima.net/atang_4803.html
2021年11款最佳的開源Kubernetes工具 http://www.zhongjima.net/atang_5082.html
七款VPN開源工具介紹 http://www.zhongjima.net/atang_4348.html
二十多款開源的服務器監(jiān)控軟件，你用過幾款? http://www.zhongjima.net/atang_4712.html
