作者简介

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/