共計(jì) 6068 個(gè)字符，預(yù)計(jì)需要花費(fèi) 16 分鐘才能閱讀完成。

這篇文章將為大家詳細(xì)講解有關(guān)怎樣選擇一個(gè)最佳微服務(wù)代理架構(gòu)，文章內(nèi)容質(zhì)量較高，因此丸趣 TV 小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

近兩年微服務(wù)架構(gòu)十分流行，許多公司也正在努力構(gòu)建自己的微服務(wù)架構(gòu)。而因?yàn)槲⒎?wù)能夠?qū)崿F(xiàn)更快的發(fā)布周期、將應(yīng)用程序模塊化、彈性伸縮以及讓應(yīng)用程序具備可移植性，其越來越成為企業(yè)數(shù)字化進(jìn)程中不可忽視的標(biāo)志。但是，由于對(duì)敏捷性所產(chǎn)生的影響了解較少，使得應(yīng)用程序交付增加了許多復(fù)雜性。

對(duì)于此，有什么解決方案呢？

選擇合適的代理架構(gòu)和應(yīng)用程序交付 controller（ADCs）對(duì)最終用戶獲得最佳體驗(yàn)至關(guān)重要。它必須能夠提供合適的安全等級(jí)、觀察性、高級(jí)流量管理以及故障排查能力并且能夠兼容你的開源工具。此外，代理架構(gòu)必須能夠同時(shí)滿足南北流量和微服務(wù)間東西流量的需求。

單體應(yīng)用程序的負(fù)載均衡十分簡(jiǎn)單。但是對(duì)于基于微服務(wù)的應(yīng)用程序而言，負(fù)載均衡則更為復(fù)雜。

下面將介紹 4 個(gè)代理架構(gòu)，并根據(jù)基于微服務(wù)應(yīng)用程序交付的 7 個(gè)關(guān)鍵標(biāo)準(zhǔn)對(duì)其中幾個(gè)進(jìn)行評(píng)估。

在優(yōu)勢(shì)和復(fù)雜性之間進(jìn)行權(quán)衡

首先，我們需要達(dá)成共識(shí)：微服務(wù)架構(gòu)實(shí)際上是十分復(fù)雜的。在開源創(chuàng)新的推動(dòng)下，最佳實(shí)踐隨著技術(shù)的進(jìn)步而迅速發(fā)展。不同的架構(gòu)擁有不同的優(yōu)勢(shì)，但是也呈現(xiàn)出不同程度的復(fù)雜性。很多時(shí)候，我們需要在自己實(shí)際所需的好處（例如安全性、可觀察性）和復(fù)雜性之間做出取舍。尤其當(dāng)你考慮實(shí)施特定架構(gòu)所需的技能和為了滿足大眾需求而必須添加的功能時(shí)，更需要在兩者之間做出選擇。

平衡核心參與者多樣化的需求

實(shí)際上，架構(gòu)的選擇比想象中復(fù)雜得多，因?yàn)椴煌睦嫦嚓P(guān)者關(guān)心的方面有所區(qū)別，所以他們的評(píng)估標(biāo)準(zhǔn)也有所不同。在微服務(wù)應(yīng)用程序旅程中，管理平臺(tái)的團(tuán)隊(duì)在組織中扮演著各個(gè)部門聯(lián)系紐帶的角色，他們關(guān)心 Kubernetes 的治理、運(yùn)維效率和開發(fā)人員的敏捷性。DevOps 團(tuán)隊(duì)關(guān)心更快的產(chǎn)品發(fā)布、自動(dòng)化、金絲雀測(cè)試以及漸進(jìn)式部署。而 SRE 最關(guān)心的是應(yīng)用程序的可用性、可觀察性以及事件響應(yīng)。DevSecOps 專注于應(yīng)用程序和基礎(chǔ)設(shè)施的安全性和自動(dòng)化。NetOps 團(tuán)隊(duì)則著迷于網(wǎng)絡(luò)管理、可見性、策略執(zhí)行和合規(guī)性。因此微服務(wù)應(yīng)用程序的交付架構(gòu)必須平衡以上所有的需求。

選擇合適的代理架構(gòu)絕非易事。需要注意的是，在做出任何決定時(shí)，需要把眼光放長(zhǎng)遠(yuǎn)，并使用南北流量和東西流量的 7 個(gè)關(guān)鍵標(biāo)準(zhǔn)來評(píng)估架構(gòu)選擇：

應(yīng)用程序安全性

可觀察性

持續(xù)部署

彈性伸縮和性能

對(duì)開源工具的集成

Istio 對(duì)開源控制平面的支持

所需的 IT 技術(shù)棧

這樣，企業(yè)可確保他們?cè)诂F(xiàn)在以及未來能夠安全可靠地交付應(yīng)用程序，并擁有世界一流的運(yùn)維體驗(yàn)。

代理架構(gòu)類型

在當(dāng)今的代理架構(gòu)中，有 4 個(gè)選項(xiàng)可供考慮：

雙層 ingress（two-tier ingress）

統(tǒng)一 ingress（unified ingress）

服務(wù)網(wǎng)格（service mesh）

服務(wù)網(wǎng)格精簡(jiǎn)版（service mesh lite）

雙層 Ingress（Two-tier Ingress）

對(duì)于云原生的新手小白和專家大佬而言，雙層 Ingress 代理架構(gòu)是最簡(jiǎn)單也最快的部署生產(chǎn)級(jí)應(yīng)用程序的方式。南北流量的負(fù)載均衡被分為兩層，以簡(jiǎn)化平臺(tái)和網(wǎng)絡(luò)團(tuán)隊(duì)的分界。而微服務(wù)間節(jié)點(diǎn)（即東西流量）流量負(fù)載均衡則使用簡(jiǎn)單的開源 L4 kube-proxy。雙層 ingress 為南北流量提供了很好的安全性、流量管理和可觀察性，但東西流量沒有被很好地照顧到。

由上圖可以看出，雙層 ingress 代理架構(gòu)具有兩層用于南北流量的應(yīng)用程序交付控制器（ADC）。圖中所示第一個(gè)（即綠色的那個(gè)）ADC 主要用于入站流量的 L4 負(fù)載均衡，以及南北流量的安全功能，如 SSL 終止和 Web 應(yīng)用程序防火墻（WAF）。它通常由熟悉面向 Internet 流量的網(wǎng)絡(luò)團(tuán)隊(duì)成員管理。此外，綠色的 ADC 還可以用于同時(shí)使用的其他單體應(yīng)用程序的 L4 負(fù)載均衡、SSL 終止和 WAF 功能。

圖中以藍(lán)色顯示的第二個(gè) ADC 用于處理南北流量的 L7 負(fù)載均衡。一般由平臺(tái)團(tuán)隊(duì)管理，并在 Kubernetes 集群中用于將流量定向到正確的節(jié)點(diǎn)。Layer 7 屬性（如 URL 和 HTTP 標(biāo)頭中的信息）可用于流量負(fù)載均衡決策。藍(lán)色 ADC 不斷接收有關(guān) Kubernetes 集群內(nèi)微服務(wù) Pod 的可用性和相應(yīng) IP 地址的更新，并可以決定哪個(gè) pod 能夠最好地處理請(qǐng)求。

微服務(wù) pod 之間的東西流量由開源 kube-proxy 管理，這是一個(gè)基礎(chǔ)的 L4 負(fù)載均衡器，它有非常簡(jiǎn)單的基于 IP 地址的輪詢調(diào)度或最少連接算法。由于 kube-proxy 缺少許多高級(jí)功能，如 L7 負(fù)載均衡、安全性和可觀察性，這使得東西流量在這一架構(gòu)中沒有得到很好的管理。

統(tǒng)一 Ingress

與雙層 Ingress 相比，統(tǒng)一 Ingress 對(duì)于精通網(wǎng)絡(luò)的平臺(tái)團(tuán)隊(duì)而言實(shí)施起來相當(dāng)簡(jiǎn)單。統(tǒng)一 Ingress 減少了南北代理層并消除了一躍點(diǎn)的延遲。而微服務(wù)間節(jié)點(diǎn)（E-W）流量負(fù)載均衡使用簡(jiǎn)單的開源 L4 kube-proxy。它適用于內(nèi)部應(yīng)用程序，并提供了稍后添加 Web 應(yīng)用程序防火墻、SSL 終止和外部應(yīng)用程序的選項(xiàng)。與雙層 Ingress 架構(gòu)類似，統(tǒng)一 Ingress 為南北流量提供了極為出色的安全性、流量管理以及可觀察性，但東西流量依舊沒有得到很好地照顧。

實(shí)際上，統(tǒng)一 Ingress 與雙層 Ingress 的優(yōu)缺點(diǎn)極為相似。不同之處在于實(shí)施所需的技能。使用統(tǒng)一 Ingress，用于南北流量的 ADC 和用于東西流量的 kube-proxy 都由平臺(tái)團(tuán)隊(duì)成員管理，因此他們必須非常精通網(wǎng)絡(luò)才能實(shí)現(xiàn)和管理這種類型的架構(gòu)。

統(tǒng)一 Ingress 代理架構(gòu)能夠參與 Kubernetes 集群的 overlay 網(wǎng)絡(luò)，這使其可以直接與微服務(wù) Pod 通信。因此，平臺(tái)團(tuán)隊(duì)必須了解網(wǎng)絡(luò)堆棧的第 3 - 7 層，才能充分利用此架構(gòu)。

與服務(wù)網(wǎng)格相比，統(tǒng)一 ingress 代理架構(gòu)的部署相當(dāng)簡(jiǎn)單，并且南北流量提供了出色的功能。但是由于 kube-proxy 的局限性以及需要精通網(wǎng)絡(luò)的平臺(tái)團(tuán)隊(duì)來實(shí)現(xiàn)，因此它的東西流量功能非常有限。

服務(wù)網(wǎng)格

這是近兩年才出現(xiàn)的架構(gòu)，同時(shí)也是最先進(jìn)、最復(fù)雜的架構(gòu)。服務(wù)網(wǎng)格為每個(gè)微服務(wù) pod 采用了 sidecar，并在進(jìn)入和離開 pod 時(shí)檢查和管理東西流量。因此，服務(wù)網(wǎng)格能夠提供最高級(jí)別的可觀察性、安全性以及微服務(wù)之間流量的細(xì)粒度管理。此外，還能選擇重復(fù)的微服務(wù)功能（如加密），將其卸載到 sidecar。但需要強(qiáng)調(diào)的是，由于服務(wù)網(wǎng)格是一個(gè)十分復(fù)雜的架構(gòu)，因此對(duì)于平臺(tái)團(tuán)隊(duì)來說學(xué)習(xí)曲線很陡峭。

典型的服務(wù)網(wǎng)格架構(gòu)類似于用于南北流量的雙層 Ingress 代理架構(gòu)，并且具有如上文所述的好處。而在雙層 Ingress 和服務(wù)網(wǎng)格之間最為關(guān)鍵的區(qū)別，也是其價(jià)值所在，是服務(wù)網(wǎng)格采用輕量級(jí) ADC 作為每個(gè)東西流量微服務(wù) pod 的 sidecar。微服務(wù)之間也無法直接通信，而需要通過 sidecar，這樣就可以在進(jìn)入和離開 pod 時(shí)檢查和管理 pod 間的流量。

通過使用代理 sidecar，服務(wù)網(wǎng)格提供了最高級(jí)別的可觀察性、安全性以及微服務(wù)之間的細(xì)粒度流量管理和控制。此外，可以將諸如重試和加密之類的重復(fù)性微服務(wù)功能轉(zhuǎn)移到 sidecar 上。盡管此前我們已經(jīng)為每個(gè) sidecar 分配了自己的內(nèi)存和 CPU 資源，但 sidecar 通常十分輕量。

對(duì)于 sidecar 可以選擇 Envoy 之類的開源解決方案。一般而言，sidecar 由平臺(tái)團(tuán)隊(duì)管理并連接到每個(gè) pod，進(jìn)而可創(chuàng)建高度可擴(kuò)展的分布式架構(gòu)，但由于添加了許多活動(dòng)組件，因此它們也具有極大的復(fù)雜性。

接下來，讓我們根據(jù)以下 7 個(gè)標(biāo)準(zhǔn)對(duì)服務(wù)網(wǎng)格代理架構(gòu)進(jìn)行評(píng)估。

應(yīng)用程序安全性

Sidecar 為微服務(wù)中的東西流量提供了最佳安全性。本質(zhì)上，微服務(wù)之間的每個(gè) API 調(diào)用都通過 sidecar 進(jìn)行代理，以提升安全性。此外，海可以在微服務(wù)之間執(zhí)行身份驗(yàn)證，并設(shè)置策略和控制以防止濫用。也能夠檢查微服務(wù)之間的流量，以確認(rèn)是否存在任何安全漏洞。

此外，可以在微服務(wù)通信之間強(qiáng)制執(zhí)行加密，并且可以將加密功能轉(zhuǎn)移到 sidecar 上。為了防止微服務(wù)不堪重負(fù)和發(fā)生故障，還可以限制微服務(wù)之間的流量。例如，如果微服務(wù)每秒能夠接收 100 個(gè)調(diào)用，那么可以設(shè)置速率限制。

使用服務(wù)網(wǎng)格，南北流量的安全性則非常好，與雙層架構(gòu)所提供的安全性相當(dāng)。對(duì)于具有嚴(yán)格監(jiān)管或高級(jí)安全要求的應(yīng)用程序（如金融業(yè)和國(guó)防行業(yè)），那么服務(wù)網(wǎng)格架構(gòu)則是最佳選擇。

可觀察性

服務(wù)網(wǎng)格在微服務(wù)之間為東西流量提供了非常好的可觀察性，因?yàn)樗?pod 之間的流量對(duì) sidecar 來說都是可見的。進(jìn)而可以通過開源或廠商提供的分析工具來分析 sidecar 的遙測(cè)，以獲得更好的視角，從而更快地進(jìn)行故障排查或容量規(guī)劃。南北流量的可觀察性在服務(wù)網(wǎng)格架構(gòu)中也十分出色，與雙層 Ingress 架構(gòu)相當(dāng)。

持續(xù)部署

借助服務(wù)網(wǎng)格，南北流量和東西流量均支持用于持續(xù)部署的高級(jí)流量管理，例如自動(dòng)金絲雀部署、藍(lán)綠部署和回滾。與 kube-proxy 不同，sidecar 具有高級(jí) API，使它們能夠與 Spinnaker 等 CI/CD 解決方案集成。

彈性伸縮和性能

服務(wù)網(wǎng)格對(duì)于東西流量來說有高度可擴(kuò)展性，因?yàn)樗欠植际郊軜?gòu)。它還有助于擴(kuò)展可觀察性、安全性以及高級(jí)流量管理和控制等功能。

性能取決于 sidecar 的選擇，因?yàn)?sidecar 供應(yīng)商之間的性能和延遲可能會(huì)有所不同。由于東西流量由 sidecar 代理，因此使用 sidecar 將為 Pod 間流量增加兩個(gè)額外的躍點(diǎn)，這將增加總體延遲。如果使用 Istio 控制平面，則會(huì)向提供策略實(shí)施的 Istio Mixer 增加一個(gè)躍點(diǎn)，從而增加額外的延遲。每個(gè) Pod 上運(yùn)行 sidecar 都需要內(nèi)存和 CPU，并且可以迅速添加成千上百個(gè) pod。

服務(wù)網(wǎng)格提供非常出色的南北流量彈性伸縮和性能，與雙層 Ingress 相當(dāng)。

開源工具的集成

南北流量的 ADC 和東西流量的 sidecar 均能集成比較主流的開源工具如 Prometheus、Grafana、Spinnaker、Elasticsearch、Fluentd 以及 Kibana 等。大部分的 sidecar 還能有擴(kuò)展的 API，可以與更多的工具進(jìn)行集成。

Istio 對(duì)開源控制平面的支持

南北流量的 ADC 和東西流量的 sidecar 均能很好地集成 Istio 開源控制平面。請(qǐng)注意，Istio 為 Istio Mixer 增加了額外一躍點(diǎn)的延遲，從而為東西流量提供了策略實(shí)施。

所需的技術(shù)棧

服務(wù)網(wǎng)格極為復(fù)雜，而管理成千上百的 sidecar 也絕對(duì)是一個(gè)極大的挑戰(zhàn)。這種新的分布式代理架構(gòu)為 IT 人員帶來了陡峭的學(xué)習(xí)曲線。對(duì)于平臺(tái)團(tuán)隊(duì)來說，最主要的挑戰(zhàn)可能是使用 sidecar 來管理許多活動(dòng)組件。因?yàn)樗麄儾坏貌惶幚硌舆t和性能的需求，并且必須能夠?qū)θ魏螖?shù)量的分布式代理以及數(shù)據(jù)平面和 Istio 控制平面組件中的問題進(jìn)行故障排除。

服務(wù)網(wǎng)格精簡(jiǎn)版

對(duì)于那些想要服務(wù)網(wǎng)格帶來更高的安全性、可觀察性和高級(jí)流量管理，但更喜歡簡(jiǎn)單架構(gòu)的用戶來說，服務(wù)網(wǎng)格精簡(jiǎn)架構(gòu)是一個(gè)可行的選擇。這一架構(gòu)并非在每個(gè) Pod 上使用 Sidecar，而是在 Kubernetes 集群內(nèi)部部署了一組代理（例如，每個(gè)節(jié)點(diǎn)代理），所有 Pod 之間的流量都通過該代理流動(dòng)。Service Mesh lite 對(duì)平臺(tái)和網(wǎng)絡(luò)團(tuán)隊(duì)而言學(xué)習(xí)成本更低，并且可以輕松地從雙層 Ingress 架構(gòu)過渡。

使用 Service Mesh lite 架構(gòu)，圖中所示的綠色應(yīng)用程序交付控制器（ADC）負(fù)責(zé)第 4 - 7 層負(fù)載均衡，以處理南北流量，以處理入站請(qǐng)求和負(fù)載均衡到正確的 Kubernetes 集群。綠色 ADC 可以執(zhí)行 SSL 終止、Web 應(yīng)用程序防火墻、身份驗(yàn)證或其他網(wǎng)絡(luò)服務(wù)。

根據(jù)隔離度和規(guī)模要求，服務(wù)網(wǎng)格精簡(jiǎn)代理架構(gòu)使用單個(gè)或多個(gè) ADC（圖中的粉紅色方框）來代理微服務(wù) Pod 之間的通信以管理 Pod 間東西流量，而不是使用附加到每個(gè) Pod 的 sidecar。而代理會(huì)部署到每個(gè)節(jié)點(diǎn)上。

服務(wù)網(wǎng)格精簡(jiǎn)版提供了服務(wù)網(wǎng)格的許多優(yōu)點(diǎn)，但由于每個(gè)集群僅具有一個(gè) ADC 實(shí)例來管理 Pod 間通信，降低了總體復(fù)雜性。最終結(jié)果是，當(dāng)所有流量通過一個(gè)或多個(gè) ADC 時(shí)，就提供了與服務(wù)網(wǎng)格代理架構(gòu)的相同高級(jí)策略控制、安全性和細(xì)粒度的流量管理，而不會(huì)擁有像服務(wù)網(wǎng)格一樣的復(fù)雜性。

讓我們根據(jù)七個(gè)關(guān)鍵標(biāo)準(zhǔn)評(píng)估服務(wù)網(wǎng)格精簡(jiǎn)代理架構(gòu)：

應(yīng)用程序安全性

服務(wù)網(wǎng)格精簡(jiǎn)版的安全性優(yōu)勢(shì)與服務(wù)網(wǎng)格相似。綠色 ADC 為南北流量提供出色的安全性。由于所有東西流量都通過粉紅色 ADC，因此它可以提供出色的安全功能，例如策略實(shí)施、網(wǎng)絡(luò)分段、速率限制和 API 保護(hù)。但是，如果需要東西加密，則必須在每個(gè)單獨(dú)的微服務(wù)中實(shí)施加密，因?yàn)闆]有像服務(wù)網(wǎng)格中的 sidecar 那樣可以自動(dòng)加密流量。而諸如 SPIFFE 等開源項(xiàng)目，有望可以讓這一步驟變得更加容易。

可觀察性

由于 ADC 可以同時(shí)看到南北和東西應(yīng)用程序流量流過，因此其可見性十分出色，基本與服務(wù)網(wǎng)格相當(dāng)。

持續(xù)部署

南北和東西流量都支持用于持續(xù)部署的高級(jí)流量管理，例如自動(dòng)金絲雀部署、漸進(jìn)式部署、藍(lán)綠部署和回滾，就像服務(wù)網(wǎng)格一樣。諸如 Spinnaker 之類的 CI / CD 工具也可以集成到東西流量中。

彈性伸縮和性能

與服務(wù)網(wǎng)格一樣，該架構(gòu)還可以輕松擴(kuò)展南北和東西流量，并受益于高級(jí)可觀察性、安全性和流量管理。服務(wù)網(wǎng)格精簡(jiǎn)版的另一個(gè)優(yōu)點(diǎn)是，與服務(wù)網(wǎng)格相比，它的東西流量延遲少一躍點(diǎn)。

開源工具集成

服務(wù)網(wǎng)格精簡(jiǎn)版和服務(wù)網(wǎng)格對(duì)第三方工具的集成完全相同，它可以與主流的開源工具集成，如 Prometheus、Grafana、Spinnaker、Elasticsearch、Fluentd 和 Kibana。

Istio 支持

服務(wù)網(wǎng)格精簡(jiǎn)版支持用于南北流量的 Istio 集成，而對(duì)東西流量的支持還不完全。不過，目前兩者之間的差距正在縮小。

所需的技術(shù)棧更少

服務(wù)網(wǎng)格精簡(jiǎn)版的主要優(yōu)點(diǎn)是，與服務(wù)網(wǎng)格相比，實(shí)現(xiàn)和管理它所需的 IT 技術(shù)棧要少得多。與雙層 Ingress 相似，網(wǎng)絡(luò)團(tuán)隊(duì)可以管理綠色 ADC，而平臺(tái)團(tuán)隊(duì)可以管理粉紅 ADC，因此兩個(gè)團(tuán)隊(duì)都可以根據(jù)自己的節(jié)奏來工作，而不需要額外花費(fèi)時(shí)間成本進(jìn)行學(xué)習(xí)。

服務(wù)網(wǎng)格精簡(jiǎn)代理架構(gòu)可以獲得與服務(wù)網(wǎng)格類似的功能但是又不想增加復(fù)雜性。它還提供了從雙層 Ingress 的輕松過渡，從而具有更好的可觀察性、更強(qiáng)的安全性，與開放源代碼工具的更好集成以及對(duì)東西流量的連續(xù)部署的支持等附加優(yōu)點(diǎn)。

選擇合適的架構(gòu)時(shí)，沒有絕對(duì)正確或錯(cuò)誤的選擇，而需要根據(jù)自己實(shí)際情況選擇合適的。

想要最快、最簡(jiǎn)單的架構(gòu)進(jìn)行生產(chǎn)部署的云原生新手可以從雙層 Ingresss 入手。如果需要使用具有可見性、安全性和集成性的南北和東西流量來完全控制基于微服務(wù)的應(yīng)用程序，那么最好的架構(gòu)是服務(wù)網(wǎng)格，值得一提的是，它十分復(fù)雜。如果 IT 既想享受服務(wù)網(wǎng)格的功能性又不想承受其復(fù)雜性，那么服務(wù)網(wǎng)格精簡(jiǎn)版將十分合適。或者從雙層 Ingress 開始入門，然后隨著技術(shù)的精進(jìn)將其遷移到服務(wù)網(wǎng)格精簡(jiǎn)版上。

關(guān)于怎樣選擇一個(gè)最佳微服務(wù)代理架構(gòu)就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。