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

近两年微服务架构十分流行，许多公司也正在努力构建自己的微服务架构。而因为微服务能够实现更快的发布周期、将应用程序模块化、弹性伸缩以及让应用程序具备可移植性，其越来越成为企业数字化进程中不可忽视的标志。但是，由于对敏捷性所产生的影响了解较少，使得应用程序交付增加了许多复杂性。

对于此，有什么解决方案呢？

选择合适的代理架构和应用程序交付 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/
  

作者简介

Pankaj Gupta，就职于 Citrix，是云原生应用程序交付解决方案的高级总监。