1.3 基础设施的解决思路

这些基本的应用程序网络通信问题并非存在于特定的应用程序、语言或框架中。重试、超时、客户端负载均衡、熔断等特性对不同的应用程序而言没有太大的区别。服务才是核心关注点，为在每一种语言中实现这些功能而投入大量的时间和资源（包括上一节中的其他缺点）是一种浪费。我们真正想要的是一种与技术无关的方式，将应用程序从网络通信问题中解放出来。

1.3.1 应用程序感知服务代理

有一种方法是通过代理，将这些水平关注点转移到基础设施中。代理是一种基础设施中介组件，可以处理连接并将它们重定向到适当的后端服务实例。我们一直在使用代理（不管是否察觉到）来处理网络流量，执行安全相关工作，并对后端服务进行负载均衡。例如，HAProxy是一个简单但功能强大的反向代理，用于跨多个后端服务实例分发连接。mod_proxy是Apache HTTP服务器的一个模块，它也充当反向代理。在我们的公司IT系统中，通常所有开放到互联网的流量都是通过防火墙中的转发代理路由的。这些代理监视流量并阻止某些类型的活动。

我们想要的是一个能够感知应用程序并替服务构建应用程序网络的代理（见图1.4）。为此，该服务代理需要理解应用程序的构造，如消息和请求，而不像传统的基础设施代理，需要理解连接和包。换句话说，我们需要一个7层代理。

图1.4 使用代理将水平关注点（如弹性、流量控制和安全性）推到应用程序实现之外

1.3.2 认识Envoy代理

Envoy是一个服务代理，作为一种多功能、高性能和强大的应用层代理出现在开源社区中。Envoy是Lyft开发的，作为公司SOA基础设施的一部分，能够实现诸如重试、超时、熔断、客户端负载均衡、服务发现、安全性和指标收集等网络功能，而不需要任何明确的语言或框架依赖。Envoy在应用程序中实现了所有进程外的功能，如图1.5所示。

图1.5 在应用程序网络中，Envoy代理是进程外的参与者

Envoy的能力并不局限于这些应用层弹性方面。Envoy还捕获了许多应用程序网络指标，如每秒请求数、故障数、熔断事件等。我们可以使用Envoy自动了解服务之间发生了什么，在这里会看到很多意想不到的复杂性。Envoy代理为解决服务架构的水平可靠性和可观测性问题奠定了基础，允许我们将这些问题推到应用程序之外并引入基础设施。在接下来的章节中，我们将介绍更多关于Envoy的内容。

我们可以在应用程序旁边部署服务代理，以从应用程序中获得这些特性（弹性和可观测性），但保真度是非常特定于应用程序的。图1.6显示了在这个模型中，希望与系统其他部分通信的应用程序是如何先将请求传递给Envoy，然后由Envoy处理上游通信的。

服务代理还可以做一些其他事情，比如收集分布式追踪span，这样我们就可以将特定请求所采取的所有步骤拼接在一起。我们可以看到每个步骤花了多长时间，并在系统中寻找潜在的瓶颈或bug。如果所有的应用程序都通过它们自己的代理与外部世界通信，并且所有进入应用程序的流量都通过我们的代理，那么我们就可以在不改变应用程序代码的情况下使其获得一些重要的功能。这个代理加应用程序的组合构成了称为服务网格的通信总线的基础。

我们可以将像Envoy这样的服务代理与应用程序的每个实例一起部署为一个单独的原子单元。例如，在Kubernetes中，我们可以在一个Pod中联合部署服务代理和应用程序。图1.7显示了sidecar部署模式，其中部署了服务代理以补充主应用程序实例。

图1.6 Envoy代理脱离应用程序的进程

图1.7 sidecar部署是一个附加的过程，它与主应用程序进程协同工作，以交付一个功能块