作者簡介?

Pankaj Gupta，就職于Citrix，是云原生應(yīng)用程序交付解決方案的高級總監(jiān)。

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

對于此，有什么解決方案呢？

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

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

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

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

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

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

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

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

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

• 可觀察性

• 持續(xù)部署

• 彈性伸縮和性能

• 對開源工具的集成

• Istio對開源控制平面的支持

• 所需的IT技術(shù)棧

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

代理架構(gòu)類型

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

• 雙層ingress（two-tier ingress）

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

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

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

雙層Ingress（Two-tier Ingress）

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

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

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

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

統(tǒng)一Ingress

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

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

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

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

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

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

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

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

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

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

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

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

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

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

可觀察性

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

持續(xù)部署

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

彈性伸縮和性能

服務(wù)網(wǎng)格對于東西流量來說有高度可擴展性，因為它是分布式架構(gòu)。它還有助于擴展可觀察性、安全性以及高級流量管理和控制等功能。

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

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

開源工具的集成

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

Istio對開源控制平面的支持

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

所需的技術(shù)棧

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

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

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

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

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

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

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

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

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

可觀察性

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

持續(xù)部署

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

彈性伸縮和性能

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

開源工具集成

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

Istio支持

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

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

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

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

總? 結(jié)

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

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

如果企業(yè)想要做出最合適自己的選擇，那么必須要考慮應(yīng)用程序交付控制需求和IT團(tuán)隊的技術(shù)棧，然后在獲得的優(yōu)勢和復(fù)雜性之間進(jìn)行權(quán)衡。最重要的是，要具備長遠(yuǎn)的眼光，在解決當(dāng)前的業(yè)務(wù)需求的同時還能夠為未來的擴展做好準(zhǔn)備。? ? ?

原文鏈接：

https://thenewstack.io/part-1-the-best-way-to-select-a-proxy-architecture-for-microservices-application-delivery/

https://thenewstack.io/part-2-the-best-way-to-select-a-proxy-architecture-for-microservices-application-delivery/

https://thenewstack.io/part-3-the-best-way-to-select-a-proxy-architecture-for-microservices-application-delivery/

https://thenewstack.io/part-4-when-a-service-mesh-lite-proxy-is-right-for-your-organization/? ? ? ? ? ? ??