哪種服務(wù)網(wǎng)格最適合你的企業(yè)?近年來(lái),Kubernetes服務(wù)網(wǎng)格框架數(shù)量增加迅速,使得這成為一個(gè)棘手的問(wèn)題。
專(zhuān)注于為中小企業(yè)提供成都做網(wǎng)站、成都網(wǎng)站制作、成都外貿(mào)網(wǎng)站建設(shè)服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)泰興免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都,凝聚了一批互聯(lián)網(wǎng)行業(yè)人才,有力地推動(dòng)了數(shù)千家企業(yè)的穩(wěn)健成長(zhǎng),幫助中小企業(yè)通過(guò)網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。下面將介紹9種較受歡迎的用以支撐微服務(wù)開(kāi)發(fā)的服務(wù)網(wǎng)格框架,每種方案都給出了其適用場(chǎng)景。
服務(wù)網(wǎng)格近年來(lái)有很高的話題度,背后的原因是什么?
微服務(wù)已經(jīng)成為一種靈活快速的開(kāi)發(fā)方式。然而,隨著微服務(wù)數(shù)量成倍數(shù)地增長(zhǎng),開(kāi)發(fā)團(tuán)隊(duì)開(kāi)始遇到了部署和擴(kuò)展性上的問(wèn)題。
容器和Kubernetes這樣的容器編排系統(tǒng) ,將運(yùn)行時(shí)和服務(wù)一起打包進(jìn)鏡像,調(diào)度容器到合適的節(jié)點(diǎn),運(yùn)行容器。這個(gè)方案可以解決開(kāi)發(fā)團(tuán)隊(duì)遇到的不少問(wèn)題。然而,在這個(gè)操作流程中仍存在短板:如何管理服務(wù)間的通信。
在采用服務(wù)網(wǎng)格的場(chǎng)景下,以一種和應(yīng)用代碼解耦的方式,增強(qiáng)了應(yīng)用間統(tǒng)一的網(wǎng)絡(luò)通信能力。服務(wù)網(wǎng)格擴(kuò)展了集群的管理能力,增強(qiáng)可觀測(cè)性、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、IT運(yùn)維監(jiān)控及應(yīng)用故障恢復(fù)等功能。
服務(wù)網(wǎng)格一直有很高的熱度。正如Linkerd的作者William Morgan所提到的:“服務(wù)網(wǎng)格本質(zhì)上無(wú)非就是和應(yīng)用捆綁在一起的用戶空間代理。” 此說(shuō)法相當(dāng)簡(jiǎn)潔,他還補(bǔ)充道,“如果你能透過(guò)噪音看清本質(zhì),服務(wù)網(wǎng)格能給你帶來(lái)實(shí)實(shí)在在的重要價(jià)值。”
Envoy是許多服務(wù)網(wǎng)格框架的核心組件,是一個(gè)通用的開(kāi)源代理,常被用于Pod內(nèi)的sidecar以攔截流量。也有服務(wù)網(wǎng)格使用另外的代理方案。
若論具體服務(wù)網(wǎng)格方案的普及程度,Istio 和 Linkerd 獲得了更多的認(rèn)可。也有其它可選項(xiàng),包括 Consul Connect,Kuma,AWS App Mesh和OpenShift。下文會(huì)闡述9種服務(wù)網(wǎng)格提供的關(guān)鍵特性。
Istio
Istio是基于Envoy構(gòu)建的一個(gè)可擴(kuò)展的開(kāi)源服務(wù)網(wǎng)格。開(kāi)發(fā)團(tuán)隊(duì)可以通過(guò)它連接、加密、管控和觀察應(yīng)用服務(wù)。Istio于2017年開(kāi)源,目前 IBM 、Google、Lyft 仍在對(duì)其進(jìn)行持續(xù)維護(hù)升級(jí)。Lyft 在2017年把 Envoy 捐贈(zèng)給了CNCF。
Istio 花了不少時(shí)間去完善增強(qiáng)它的功能特性。Istio 的關(guān)鍵特性包括負(fù)載均衡、流量路由、策略創(chuàng)建、可度量性及服務(wù)間認(rèn)證。
Istio 有兩個(gè)部分組成:數(shù)據(jù)平面和控制平面。綿陽(yáng)電信機(jī)房數(shù)據(jù)平面負(fù)責(zé)處理流量管理,通過(guò) Envoy 的 sidecar 代理來(lái)實(shí)現(xiàn)流量路由和服務(wù)間調(diào)用??刂破矫媸侵饕砷_(kāi)發(fā)者用來(lái)配置路由規(guī)則和觀測(cè)指標(biāo)。
Istio 觀測(cè)指標(biāo)是細(xì)粒度的屬性,其中包含和服務(wù)行為相關(guān)的特定數(shù)據(jù)值。下面是個(gè)樣例:成都服務(wù)器托管
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ù)網(wǎng)格相比,Istio 勝在其平臺(tái)成熟度以及通過(guò)其 Dashbaord
著重突出的服務(wù)行為觀測(cè)和業(yè)務(wù)管理功能,然而也因?yàn)檫@些高級(jí)特性和復(fù)雜的配置流程,Istio 可能并不如其它一些替代方案那樣容易上手。
Linkerd
按照官網(wǎng)的說(shuō)法,Linkerd 是一個(gè)輕量級(jí)、安全優(yōu)先的 Kubernetes 服務(wù)網(wǎng)格。它的創(chuàng)建流程快到讓人難以置信(據(jù)稱(chēng)在 Kubernetes 安裝只需要 60 秒),這是大多數(shù)開(kāi)發(fā)者喜聞樂(lè)見(jiàn)的。Linkerd 并沒(méi)有采用基于 Envoy 的構(gòu)建方案。而是使用了一個(gè)基于 Rust 的高性能代理 linkerd2-proxy,這個(gè)代理是專(zhuān)門(mén)為 Linkerd 服務(wù)網(wǎng)格編寫(xiě)的。
Linkerd 由社區(qū)驅(qū)動(dòng),是 100% 的 Apache 許可開(kāi)源項(xiàng)目。它還是 CNCF 孵化項(xiàng)目。Linkerd 始于 2016 年,維護(hù)者也花了不少時(shí)間去解決其中的缺陷。
使用 Linkerd 服務(wù)網(wǎng)格,應(yīng)用服務(wù)可以增強(qiáng)其可靠性、可觀測(cè)性及其在 Kubernetes 上部署的安全性。舉個(gè)例子,可觀測(cè)性的增強(qiáng)可以幫助用戶解決服務(wù)間的延遲問(wèn)題。使用 Linkerd 不要求用戶做很多代碼調(diào)整或是花費(fèi)大量時(shí)間寫(xiě) YAML 配置文件??煽康漠a(chǎn)品特性和正向的開(kāi)發(fā)者使用回饋,使得 Linkerd 成為服務(wù)網(wǎng)格中一個(gè)強(qiáng)有力的競(jìng)爭(zhēng)者。
Consul Connect
Consul Connect 是來(lái)自 HashiCorp 的服務(wù)網(wǎng)格,專(zhuān)注于路由和分段,通過(guò)應(yīng)用級(jí)的 sidecar 代理來(lái)提供服務(wù)間的網(wǎng)絡(luò)特性。 Consult Connect 側(cè)重于應(yīng)用安全,提供應(yīng)用間的雙向 TLS 連接以實(shí)現(xiàn)授權(quán)和加密。
Consult Connect 獨(dú)特的一點(diǎn)是提供了兩種代理模式。一種是它內(nèi)建的代理,同時(shí)它還支持 Envoy 方案。Connect 強(qiáng)調(diào)可觀測(cè)性,集成了例如 Prometheus 這樣的工具來(lái)監(jiān)控來(lái)自 sidecar 代理的數(shù)據(jù)。Consul Connect 可以靈活地滿足開(kāi)發(fā)者使用需求。比如,它提供了多種方式注冊(cè)服務(wù):可以從編排系統(tǒng)注冊(cè),可以通過(guò)配置文件,通過(guò) API 調(diào)用,或是命令行工具。
Kuma
Kuma 來(lái)源于 Kong,自稱(chēng)是一個(gè)非常好用的服務(wù)網(wǎng)格替代方案。Kuma 是一個(gè)基于 Envoy 的平臺(tái)無(wú)關(guān)的控制平面。綿陽(yáng)電信機(jī)房 Kuma 提供了安全、觀測(cè)、路由等網(wǎng)絡(luò)特性,同時(shí)增強(qiáng)了服務(wù)間的連通性。Kuma 同時(shí)支持 Kubernetes 和虛擬機(jī)。
Kuma 讓人感興趣的一點(diǎn)是,它的企業(yè)版可以通過(guò)一個(gè)統(tǒng)一控制面板來(lái)運(yùn)維管理多個(gè)互相隔離獨(dú)立的服務(wù)網(wǎng)格。這項(xiàng)能力可以滿足安全要求高的使用場(chǎng)景。既符合隔離的要求,又實(shí)現(xiàn)集中控制。
Kuma 也是相對(duì)容易安裝的一個(gè)方案。因?yàn)樗A(yù)先內(nèi)置了不少策略。這些策略覆蓋了常見(jiàn)需求,例如路由,雙向 TLS,故障注入,流量控制,加密等場(chǎng)景。
Kuma 原生兼容 Kong,對(duì)于那些已經(jīng)采用 Kong API 管理的企業(yè)組織,Kuma 是個(gè)非常自然而然的候選方案。
Maesh
Maesh 是來(lái)自 Containous 的容器原生的服務(wù)網(wǎng)格,標(biāo)榜自己是比市場(chǎng)其它服務(wù)網(wǎng)格更輕量級(jí)更易用的方案。和很多基于 Envoy 構(gòu)建的服務(wù)網(wǎng)格不同,Maesh 采用了 Traefik, 一個(gè)開(kāi)源的反向代理和負(fù)載均衡器。
Maesh 并沒(méi)有采用 sidecar 的方式進(jìn)行代理,而是在每個(gè)節(jié)點(diǎn)部署一個(gè)代理終端。這樣做的好處是不需要去編輯 Kubernetes 對(duì)象,同時(shí)可以讓用戶有選擇性地修改流量,Maesh 相比其他服務(wù)網(wǎng)格侵入性更低。Maesh 支持的配置方式:在用戶服務(wù)對(duì)象上添加注解或是在服務(wù)網(wǎng)格對(duì)象上添加注解來(lái)實(shí)現(xiàn)配置。
實(shí)際上,SMI 是一種新的服務(wù)網(wǎng)格規(guī)范格式,對(duì) SMI 的支持 Maesh 獨(dú)有的一大亮點(diǎn)。隨著 SMI 在業(yè)界逐漸被采用,可以提高可擴(kuò)展性和減緩供應(yīng)商綁定的擔(dān)憂。
Maesh 要求 Kubernetes 1.11 以上的版本,同時(shí)集群里安裝了 CoreDNS/KubeDNS。這篇安裝指南演示了如何通過(guò) Helm v3 快速安裝 Maesh。
helmrepoaddmaeshhttps://containous.github.io/maesh/chartshelmrepoupdatehelminstallmaeshmaesh/maesh
ServiceComb-mesher
Apache 軟件基金會(huì)形容旗下的 ServiceComb-mesher “是一款用 Go 語(yǔ)言實(shí)現(xiàn)的高性能服務(wù)網(wǎng)格”。Mesher 基于一個(gè)非常受歡迎的 Go 語(yǔ)言微服務(wù)開(kāi)發(fā)框架 Go Chassis 來(lái)設(shè)計(jì)實(shí)現(xiàn)。因此,它沿襲了 Go Chassis 的一些特性如服務(wù)發(fā)現(xiàn)、負(fù)載均衡、錯(cuò)誤容忍、路由管理和分布式追蹤等特性。
Mesher 采用了 sidecar 方式;每個(gè)服務(wù)有一個(gè) Mesher sidecar 代理。開(kāi)發(fā)人員通過(guò) Admin API 和 Mesher 交互,查看運(yùn)行時(shí)信息。Mesher 同時(shí)支持 HTTP 和 gRPC,可快速移植到不同的基礎(chǔ)設(shè)施環(huán)境,包括 Docker、Kubernetes、虛擬機(jī)和裸金屬機(jī)環(huán)境。
Network Service Mesh(NSM)
Network Service Mesh(NSM)是一款專(zhuān)門(mén)為 telcos 和 ISPs 設(shè)計(jì)的服務(wù)網(wǎng)格。它提供了一層級(jí)用以增強(qiáng)服務(wù)在 Kubernetes 的低層級(jí)網(wǎng)絡(luò)能力。NSM 目前是 CNCF 的沙箱項(xiàng)目。
根據(jù) NSM 的文檔說(shuō)明,“經(jīng)常接觸 L2/L3 層的網(wǎng)絡(luò)運(yùn)維人員抱怨說(shuō),適合他們的下一代架構(gòu)的容器網(wǎng)絡(luò)解決方案幾乎沒(méi)有”。
因此,NSM 在設(shè)計(jì)時(shí)就考慮到一些不同使用場(chǎng)景,尤其是網(wǎng)絡(luò)協(xié)議不同和網(wǎng)絡(luò)配置混雜的場(chǎng)景。這使得 NSM 對(duì)某些特殊場(chǎng)景具備相當(dāng)吸引力,例如邊緣計(jì)算、5G 網(wǎng)絡(luò)和 IOT 設(shè)備等場(chǎng)景。NSM 使用簡(jiǎn)單直接的 API 接口去實(shí)現(xiàn)容器和外部端點(diǎn)的之間的通信。
和其他服務(wù)網(wǎng)格相比,NSM 工作在另一個(gè)不同的網(wǎng)絡(luò)層。 VMware 形容 NSM“專(zhuān)注于連接”。GitHub 的文檔演示了 NSM 是如何與 Envoy協(xié)同工作的。
AWS App Mesh
AWS APP Mesh 為開(kāi)發(fā)者提供了“適用于不同服務(wù)的應(yīng)用層的網(wǎng)絡(luò)”。它接管了服務(wù)的所有網(wǎng)絡(luò)流量,使用開(kāi)源的 Envoy 代理去控制容器的流量出入。AWS App Mesh 支持 HTTP/2 gRPC 。
AWS App Mesh 對(duì)于那些已經(jīng)將容器平臺(tái)深度綁定 AWS 的公司而言,會(huì)是相當(dāng)不錯(cuò)的服務(wù)網(wǎng)格方案。AWS 平臺(tái)包括 AWS Fargate,Amazon Elastic Container Service,Amazon Elastic Kubernetes Service(EKS),Amazon Elastic Compute Cloud(EC2),Kubernetes on EC2,包括 AWS App Mesh 不需要付額外費(fèi)用。
AWS App Mesh 和 AWS 生態(tài)內(nèi)的監(jiān)控工具無(wú)縫兼容。這些工具包括 CloudWatch 和 AWS X-Ray,以及一些來(lái)自第三方供應(yīng)商的工具。因?yàn)?AWS 計(jì)算服務(wù)支持 AWS Outposts,AWS App Mesh 可以和混合云和已經(jīng)部署的應(yīng)用良好兼容。
AWS App Mesh 的缺點(diǎn)可能是使得開(kāi)發(fā)者深度綁定了單一供應(yīng)商方案,相對(duì)閉源,可擴(kuò)展性缺失。
OpenShift Service Mesh by Red Hat
OpenShift 是來(lái)自紅帽的一款幫助用戶“連接、管理、觀測(cè)微服務(wù)應(yīng)用”的容器管理平臺(tái)。OpenShift 預(yù)裝了不少提升企業(yè)能力的組件,也被形容為企業(yè)級(jí)的混合云 Kubernetes 平臺(tái)。
OpenShift Service Mesh 基于開(kāi)源的 Istio 構(gòu)建,具備 Isito 的控制平面和數(shù)據(jù)平面等特性。OpenShift 利用兩款開(kāi)源工具來(lái)增強(qiáng) Isito 的追蹤能力和可觀測(cè)性。OpenShift 使用 Jaeger 實(shí)現(xiàn)分布式追蹤,更好地跟蹤請(qǐng)求是如何在服務(wù)間調(diào)用處理的。
另一方面,OpenShift 使用了 Kiali 來(lái)增強(qiáng)微服務(wù)配置、流量監(jiān)控、跟蹤分析等方面的可觀測(cè)性。
正如文中所提到的,可供選擇的服務(wù)網(wǎng)格方案有很多,同時(shí)還有新的方案在涌現(xiàn)。當(dāng)然,每一種方案在技術(shù)實(shí)現(xiàn)上都略有不同。選擇一款合適的服務(wù)網(wǎng)格,主要考慮的因素包括,你能接受它帶來(lái)多大的侵入性,它的安全性如何,以及平臺(tái)成熟度等。
以下幾點(diǎn)可以幫助 DevOps 團(tuán)隊(duì)選擇一款適合他們場(chǎng)景的服務(wù)網(wǎng)格:成都服務(wù)器托管
這些考慮因素沒(méi)有覆蓋到全部場(chǎng)景。此處僅是拋磚引玉,引起讀者的思考。希望讀完上面所列的服務(wù)網(wǎng)格清單,和相關(guān)的決策因素之后,你們的團(tuán)隊(duì)能找到新的方法去改善微服務(wù)應(yīng)用的網(wǎng)絡(luò)特性。
文章名稱(chēng):9種開(kāi)源的服務(wù)網(wǎng)格比較
URL鏈接:http://muchs.cn/article22/chijc.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站建設(shè)、網(wǎng)站制作、網(wǎng)站維護(hù)、品牌網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、網(wǎng)站排名
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)