溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章將為大家詳細講解有關怎樣選擇一個最佳微服務代理架構，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。
近兩年微服務架構十分流行，許多公司也正在努力構建自己的微服務架構。而因為微服務能夠實現更快的發布周期、將應用程序模塊化、彈性伸縮以及讓應用程序具備可移植性，其越來越成為企業數字化進程中不可忽視的標志。但是，由于對敏捷性所產生的影響了解較少，使得應用程序交付增加了許多復雜性。
對于此，有什么解決方案呢？
選擇合適的代理架構和應用程序交付controller（ADCs）對最終用戶獲得最佳體驗至關重要。它必須能夠提供合適的安全等級、觀察性、高級流量管理以及故障排查能力并且能夠兼容你的開源工具。此外，代理架構必須能夠同時滿足南北流量和微服務間東西流量的需求。
單體應用程序的負載均衡十分簡單。但是對于基于微服務的應用程序而言，負載均衡則更為復雜。
下面將介紹4個代理架構，并根據基于微服務應用程序交付的7個關鍵標準對其中幾個進行評估。
在優勢和復雜性之間進行權衡
首先，我們需要達成共識：微服務架構實際上是十分復雜的。在開源創新的推動下，最佳實踐隨著技術的進步而迅速發展。不同的架構擁有不同的優勢，但是也呈現出不同程度的復雜性。很多時候，我們需要在自己實際所需的好處（例如安全性、可觀察性）和復雜性之間做出取舍。尤其當你考慮實施特定架構所需的技能和為了滿足大眾需求而必須添加的功能時，更需要在兩者之間做出選擇。
實際上，架構的選擇比想象中復雜得多，因為不同的利益相關者關心的方面有所區別，所以他們的評估標準也有所不同。在微服務應用程序旅程中，管理平臺的團隊在組織中扮演著各個部門聯系紐帶的角色，他們關心Kubernetes的治理、運維效率和開發人員的敏捷性。DevOps團隊關心更快的產品發布、自動化、金絲雀測試以及漸進式部署。而SRE最關心的是應用程序的可用性、可觀察性以及事件響應。DevSecOps專注于應用程序和基礎設施的安全性和自動化。NetOps團隊則著迷于網絡管理、可見性、策略執行和合規性。因此微服務應用程序的交付架構必須平衡以上所有的需求。
選擇合適的代理架構絕非易事。需要注意的是，在做出任何決定時，需要把眼光放長遠，并使用南北流量和東西流量的7個關鍵標準來評估架構選擇：
應用程序安全性
可觀察性
持續部署
彈性伸縮和性能
對開源工具的集成
Istio對開源控制平面的支持
所需的IT技術棧
這樣，企業可確保他們在現在以及未來能夠安全可靠地交付應用程序，并擁有世界一流的運維體驗。
在當今的代理架構中，有4個選項可供考慮：
雙層ingress（two-tier ingress）
統一ingress（unified ingress）
服務網格（service mesh）
服務網格精簡版（service mesh lite）
對于云原生的新手小白和專家大佬而言，雙層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減少了南北代理層并消除了一躍點的延遲。而微服務間節點（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，可以與更多的工具進行集成。
南北流量的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集成，而對東西流量的支持還不完全。不過，目前兩者之間的差距正在縮小。
服務網格精簡版的主要優點是，與服務網格相比，實現和管理它所需的IT技術棧要少得多。與雙層Ingress相似，網絡團隊可以管理綠色ADC，而平臺團隊可以管理粉紅ADC，因此兩個團隊都可以根據自己的節奏來工作，而不需要額外花費時間成本進行學習。
服務網格精簡代理架構可以獲得與服務網格類似的功能但是又不想增加復雜性。它還提供了從雙層Ingress的輕松過渡，從而具有更好的可觀察性、更強的安全性，與開放源代碼工具的更好集成以及對東西流量的連續部署的支持等附加優點。
選擇合適的架構時，沒有絕對正確或錯誤的選擇，而需要根據自己實際情況選擇合適的。
想要最快、最簡單的架構進行生產部署的云原生新手可以從雙層Ingresss入手。如果需要使用具有可見性、安全性和集成性的南北和東西流量來完全控制基于微服務的應用程序，那么最好的架構是服務網格，值得一提的是，它十分復雜。如果IT既想享受服務網格的功能性又不想承受其復雜性，那么服務網格精簡版將十分合適。或者從雙層Ingress開始入門，然后隨著技術的精進將其遷移到服務網格精簡版上。
關于怎樣選擇一個最佳微服務代理架構就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
