云原生资深专家：如何选择一个最佳微服务代理架构？

做者简介

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/