雲原生資深專家：如何選擇一個最佳微服務代理架構？

時間 2020-03-11

原文原文鏈接

做者簡介
Pankaj Gupta，就任於Citrix，是雲原生應用程序交付解決方案的高級總監。算法

近兩年微服務架構十分流行，許多公司也正在努力構建本身的微服務架構。而由於微服務可以實現更快的發佈週期、將應用程序模塊化、彈性伸縮以及讓應用程序具有可移植性，其愈來愈成爲企業數字化進程中不可忽視的標誌。可是，因爲對敏捷性所產生的影響了解較少，使得應用程序交付增長了許多複雜性。安全

對於此，有什麼解決方案呢？網絡

選擇合適的代理架構和應用程序交付controller（ADCs）對最終用戶得到最佳體驗相當重要。它必須可以提供合適的安全等級、觀察性、高級流量管理以及故障排查能力而且可以兼容你的開源工具。此外，代理架構必須可以同時知足南北流量和微服務間東西流量的需求。架構

單體應用程序的負載均衡十分簡單。可是對於基於微服務的應用程序而言，負載均衡則更爲複雜。app

本文將介紹4個代理架構，並根據基於微服務應用程序交付的7個關鍵標準對其中幾個進行評估。負載均衡

在優點和複雜性之間進行權衡

首先，咱們須要達成共識：微服務架構其實是十分複雜的。在開源創新的推進下，最佳實踐隨着技術的進步而迅速發展。不一樣的架構擁有不一樣的優點，可是也呈現出不一樣程度的複雜性。不少時候，咱們須要在本身實際所需的好處（例如安全性、可觀察性）和複雜性之間作出取捨。尤爲當你考慮實施特定架構所需的技能和爲了知足大衆需求而必須添加的功能時，更須要在二者之間作出選擇。運維

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

實際上，架構的選擇比想象中複雜得多，由於不一樣的利益相關者關心的方面有所區別，因此他們的評估標準也有所不一樣。在微服務應用程序旅程中，管理平臺的團隊在組織中扮演着各個部門聯繫紐帶的角色，他們關心Kubernetes的治理、運維效率和開發人員的敏捷性。DevOps團隊關心更快的產品發佈、自動化、金絲雀測試以及漸進式部署。而SRE最關心的是應用程序的可用性、可觀察性以及事件響應。DevSecOps專一於應用程序和基礎設施的安全性和自動化。NetOps團隊則着迷於網絡管理、可見性、策略執行和合規性。所以微服務應用程序的交付架構必須平衡以上全部的需求。分佈式

選擇合適的代理架構絕非易事。須要注意的是，在作出任何決定時，須要把眼光放長遠，並使用南北流量和東西流量的7個關鍵標準來評估架構選擇：ide

應用程序安全性
可觀察性
持續部署
彈性伸縮和性能
對開源工具的集成
Istio對開源控制平面的支持
所需的IT技術棧

這樣，企業可確保他們在如今以及將來可以安全可靠地交付應用程序，並擁有世界一流的運維體驗。模塊化

代理架構類型

在當今的代理架構中，有4個選項可供考慮：

雙層ingress（two-tier ingress）
統一ingress（unified ingress）
服務網格（service mesh）
服務網格精簡版（service mesh lite）

雙層Ingress（Two-tier Ingress）

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

由上圖能夠看出，雙層ingress代理架構具備兩層用於南北流量的應用程序交付控制器（ADC）。圖中所示第一個（即綠色的那個）ADC主要用於入站流量的L4負載均衡，以及南北流量的安全功能，如SSL終止和Web應用程序防火牆（WAF）。它一般由熟悉面向Internet流量的網絡團隊成員管理。此外，綠色的ADC還能夠用於同時使用的其餘單體應用程序的L4負載均衡、SSL終止和WAF功能。

圖中以藍色顯示的第二個ADC用於處理南北流量的L7負載均衡。通常由平臺團隊管理，並在Kubernetes集羣中用於將流量定向到正確的節點。Layer 7屬性（如URL和HTTP標頭中的信息）可用於流量負載均衡決策。藍色ADC不斷接收有關Kubernetes集羣內微服務Pod的可用性和相應IP地址的更新，並能夠決定哪一個pod可以最好地處理請求。

微服務pod之間的東西流量由開源kube-proxy管理，這是一個基礎的L4負載均衡器，它有很是簡單的基於IP地址的輪詢調度或最少鏈接算法。因爲kube-proxy缺乏許多高級功能，如L7負載均衡、安全性和可觀察性，這使得東西流量在這一架構中沒有獲得很好的管理。

統一Ingress

與雙層Ingress相比，統一Ingress對於精通網絡的平臺團隊而言實施起來至關簡單。統一Ingress減小了南北代理層並消除了一躍點的延遲。而微服務間節點（E-W）流量負載均衡使用簡單的開源L4 kube-proxy。它適用於內部應用程序，並提供了稍後添加Web應用程序防火牆、SSL終止和外部應用程序的選項。與雙層Ingress架構相似，統一Ingress爲南北流量提供了極爲出色的安全性、流量管理以及可觀察性，但東西流量依舊沒有獲得很好地照顧。

實際上，統一Ingress與雙層Ingress的優缺點極爲類似。不一樣之處在於實施所需的技能。使用統一Ingress，用於南北流量的ADC和用於東西流量的kube-proxy都由平臺團隊成員管理，所以他們必須很是精通網絡才能實現和管理這種類型的架構。

統一Ingress代理架構可以參與Kubernetes集羣的overlay網絡，這使其能夠直接與微服務Pod通訊。所以，平臺團隊必須瞭解網絡堆棧的第3-7層，才能充分利用此架構。

與服務網格相比，統一ingress代理架構的部署至關簡單，而且南北流量提供了出色的功能。可是因爲kube-proxy的侷限性以及須要精通網絡的平臺團隊來實現，所以它的東西流量功能很是有限。

服務網格

這是近兩年纔出現的架構，同時也是最早進、最複雜的架構。服務網格爲每一個微服務pod採用了sidecar，並在進入和離開pod時檢查和管理東西流量。所以，服務網格可以提供最高級別的可觀察性、安全性以及微服務之間流量的細粒度管理。此外，還能選擇重複的微服務功能（如加密），將其卸載到sidecar。但須要強調的是，因爲服務網格是一個十分複雜的架構，所以對於平臺團隊來講學習曲線很陡峭。

典型的服務網格架構相似於用於南北流量的雙層Ingress代理架構，而且具備如上文所述的好處。而在雙層Ingress和服務網格之間最爲關鍵的區別，也是其價值所在，是服務網格採用輕量級ADC做爲每一個東西流量微服務pod的sidecar。微服務之間也沒法直接通訊，而須要經過sidecar，這樣就能夠在進入和離開pod時檢查和管理pod間的流量。

經過使用代理sidecar，服務網格提供了最高級別的可觀察性、安全性以及微服務之間的細粒度流量管理和控制。此外，能夠將諸如重試和加密之類的重複性微服務功能轉移到sidecar上。儘管此前咱們已經爲每一個sidecar分配了本身的內存和CPU資源，但sidecar一般十分輕量。

對於sidecar能夠選擇Envoy之類的開源解決方案。通常而言，sidecar由平臺團隊管理並鏈接到每一個pod，進而可建立高度可擴展的分佈式架構，但因爲添加了許多活動組件，所以它們也具備極大的複雜性。

接下來，讓咱們根據如下7個標準對服務網格代理架構進行評估。

應用程序安全性

Sidecar爲微服務中的東西流量提供了最佳安全性。本質上，微服務之間的每一個API調用都經過sidecar進行代理，以提高安全性。此外，海能夠在微服務之間執行身份驗證，並設置策略和控制以防止濫用。也可以檢查微服務之間的流量，以確認是否存在任何安全漏洞。

此外，能夠在微服務通訊之間強制執行加密，而且能夠將加密功能轉移到sidecar上。爲了防止微服務不堪重負和發生故障，還能夠限制微服務之間的流量。例如，若是微服務每秒可以接收100個調用，那麼能夠設置速率限制。

使用服務網格，南北流量的安全性則很是好，與雙層架構所提供的安全性至關。對於具備嚴格監管或高級安全要求的應用程序（如金融業和國防行業），那麼服務網格架構則是最佳選擇。

可觀察性

服務網格在微服務之間爲東西流量提供了很是好的可觀察性，由於全部pod之間的流量對sidecar來講都是可見的。進而能夠經過開源或廠商提供的分析工具來分析sidecar的遙測，以得到更好的視角，從而更快地進行故障排查或容量規劃。南北流量的可觀察性在服務網格架構中也十分出色，與雙層Ingress架構至關。

持續部署

藉助服務網格，南北流量和東西流量均支持用於持續部署的高級流量管理，例如自動金絲雀部署、藍綠部署和回滾。與kube-proxy不一樣，sidecar具備高級API，使它們可以與Spinnaker等CI/CD解決方案集成。

彈性伸縮和性能

服務網格對於東西流量來講有高度可擴展性，由於它是分佈式架構。它還有助於擴展可觀察性、安全性以及高級流量管理和控制等功能。

性能取決於sidecar的選擇，由於sidecar供應商之間的性能和延遲可能會有所不一樣。因爲東西流量由sidecar代理，所以使用sidecar將爲Pod間流量增長兩個額外的躍點，這將增長整體延遲。若是使用Istio控制平面，則會向提供策略實施的Istio Mixer增長一個躍點，從而增長額外的延遲。每一個Pod上運行sidecar都須要內存和CPU，而且能夠迅速添加成千上百個pod。

服務網格提供很是出色的南北流量彈性伸縮和性能，與雙層Ingress至關。

開源工具的集成

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

Istio對開源控制平面的支持

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

所需的技術棧

服務網格極爲複雜，而管理成千上百的sidecar也絕對是一個極大的挑戰。這種新的分佈式代理架構爲IT人員帶來了陡峭的學習曲線。對於平臺團隊來講，最主要的挑戰多是使用sidecar來管理許多活動組件。由於他們不得不處理延遲和性能的需求，而且必須可以對任何數量的分佈式代理以及數據平面和Istio控制平面組件中的問題進行故障排除。

服務網格精簡版

對於那些想要服務網格帶來更高的安全性、可觀察性和高級流量管理，但更喜歡簡單架構的用戶來講，服務網格精簡架構是一個可行的選擇。這一架構並不是在每一個Pod上使用Sidecar，而是在Kubernetes集羣內部部署了一組代理（例如，每一個節點代理），全部Pod之間的流量都經過該代理流動。Service Mesh lite對平臺和網絡團隊而言學習成本更低，而且能夠輕鬆地從雙層Ingress架構過渡。

使用Service Mesh lite架構，圖中所示的綠色應用程序交付控制器（ADC）負責第4-7層負載均衡，以處理南北流量，以處理入站請求和負載均衡到正確的Kubernetes集羣。綠色ADC能夠執行SSL終止、Web應用程序防火牆、身份驗證或其餘網絡服務。

根據隔離度和規模要求，服務網格精簡代理架構使用單個或多個ADC（圖中的粉紅色方框）來代理微服務Pod之間的通訊以管理Pod間東西流量，而不是使用附加到每一個Pod的sidecar。而代理會部署到每一個節點上。

服務網格精簡版提供了服務網格的許多優勢，但因爲每一個集羣僅具備一個ADC實例來管理Pod間通訊，下降了整體複雜性。最終結果是，當全部流量經過一個或多個ADC時，就提供了與服務網格代理架構的相同高級策略控制、安全性和細粒度的流量管理，而不會擁有像服務網格同樣的複雜性。

讓咱們根據七個關鍵標準評估服務網格精簡代理架構：

應用程序安全性

服務網格精簡版的安全性優點與服務網格類似。綠色ADC爲南北流量提供出色的安全性。因爲全部東西流量都經過粉紅色ADC，所以它能夠提供出色的安全功能，例如策略實施、網絡分段、速率限制和API保護。可是，若是須要東西加密，則必須在每一個單獨的微服務中實施加密，由於沒有像服務網格中的sidecar那樣能夠自動加密流量。而諸如SPIFFE等開源項目，有望可讓這一步驟變得更加容易。

可觀察性

因爲ADC能夠同時看到南北和東西應用程序流量流過，所以其可見性十分出色，基本與服務網格至關。

持續部署

南北和東西流量都支持用於持續部署的高級流量管理，例如自動金絲雀部署、漸進式部署、藍綠部署和回滾，就像服務網格同樣。諸如Spinnaker之類的CI / CD工具也能夠集成到東西流量中。

彈性伸縮和性能

與服務網格同樣，該架構還能夠輕鬆擴展南北和東西流量，並受益於高級可觀察性、安全性和流量管理。服務網格精簡版的另外一個優勢是，與服務網格相比，它的東西流量延遲少一躍點。

開源工具集成

服務網格精簡版和服務網格對第三方工具的集成徹底相同，它能夠與主流的開源工具集成，如Prometheus、Grafana、Spinnaker、Elasticsearch、Fluentd和Kibana。

Istio支持

服務網格精簡版支持用於南北流量的Istio集成，而對東西流量的支持還不徹底。不過，目前二者之間的差距正在縮小。

所需的技術棧更少

服務網格精簡版的主要優勢是，與服務網格相比，實現和管理它所需的IT技術棧要少得多。與雙層Ingress類似，網絡團隊能夠管理綠色ADC，而平臺團隊能夠管理粉紅ADC，所以兩個團隊均可以根據本身的節奏來工做，而不須要額外花費時間成本進行學習。

服務網格精簡代理架構能夠得到與服務網格相似的功能可是又不想增長複雜性。它還提供了從雙層Ingress的輕鬆過渡，從而具備更好的可觀察性、更強的安全性，與開放源代碼工具的更好集成以及對東西流量的連續部署的支持等附加優勢。

總結

選擇合適的架構時，沒有絕對正確或錯誤的選擇，而須要根據本身實際狀況選擇合適的。

想要最快、最簡單的架構進行生產部署的雲原生新手能夠從雙層Ingresss入手。若是須要使用具備可見性、安全性和集成性的南北和東西流量來徹底控制基於微服務的應用程序，那麼最好的架構是服務網格，值得一提的是，它十分複雜。若是IT既想享受服務網格的功能性又不想承受其複雜性，那麼服務網格精簡版將十分合適。或者從雙層Ingress開始入門，而後隨着技術的精進將其遷移到服務網格精簡版上。

若是企業想要作出最合適本身的選擇，那麼必需要考慮應用程序交付控制需求和IT團隊的技術棧，而後在得到的優點和複雜性之間進行權衡。最重要的是，要具有長遠的眼光，在解決當前的業務需求的同時還可以爲將來的擴展作好準備。