Pankaj Gupta，就職於Citrix，是雲原生應用程序交付解決方案的高級總監。
近兩年微服務架構十分流行，許多公司也正在努力構建自己的微服務架構。而因為微服務能夠實現更快的發佈週期、將應用程序模塊化、彈性伸縮以及讓應用程序具備可移植性，其越來越成為企業數字化進程中不可忽視的標誌。但是，由於對敏捷性所產生的影響了解較少，使得應用程序交付增加了許多複雜性。
對於此，有什麼解決方案呢？
選擇合適的代理架構和應用程序交付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（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團隊的技術棧，然後在獲得的優勢和複雜性之間進行權衡。最重要的是，要具備長遠的眼光，在解決當前的業務需求的同時還能夠為未來的擴展做好準備。
原文鏈接：
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/
閱讀更多 RancherLabs 的文章
