Question

到目前为止，通过前面几章中构建的微服务，我们可以通过 Web 客户端直接调用各个服务，也可以通过诸如 Eureka 这样的服务发现引擎以编程方式调用它们。图 6-1 展示了没有服务网关的后果。

图 6-1 如果没有服务网关，服务客户端将为每个服务调用不同的端点

服务网关充当服务客户端和被调用的服务之间的中介。服务客户端仅与服务网关管理的单个 URL 进行对话。服务网关从服务客户端调用中分离出路径，并确定服务客户端正在尝试调用哪个服务。图 6-2 演示了服务网关如何像交通警察一样指挥交通，将用户引导到目标微服务和相应的实例。服务网关充当应用程序内所有微服务调用的入站流量的守门人。有了服务网关，服务客户端永远不会直接调用单个服务的 URL，而是将所有调用都放到服务网关上。

图 6-2 服务网关位于服务客户端和相应的服务实例之间。所有服务调用（内部和外部）都应流经服务网关

由于服务网关位于客户端到各个服务的所有调用之间，因此它还充当服务调用的中央策略执行点（PEP）。使用集中式 PEP 意味着横切服务关注点可以在一个地方实现，而无须各个开发团队来实现这些关注点。举例来说，可以在服务网关中实现的横切关注点包括以下几个。

• 静态路由 ——服务网关将所有的服务调用放置在单个 URL 和 API 路由的后面。这简化了开发，因为开发人员只需要知道所有服务的一个服务端点就可以了。
• 动态路由 ——服务网关可以检查传入的服务请求，根据来自传入请求的数据和服务调用者的身份执行智能路由。例如，可能会将参与测试版程序的客户的所有调用路由到特定服务集群的服务，这些服务运行的是不同版本的代码，而不是其他人使用的非测试版程序的代码。
• 验证和授权 ——由于所有服务调用都经过服务网关进行路由，所以服务网关是检查服务调用者是否已经进行了验证并被授权进行服务调用的自然场所。
• 度量数据收集和日志记录 ——当服务调用通过服务网关时，可以使用服务网关来收集数据和日志信息，还可以使用服务网关确保在用户请求上提供关键信息以确保日志统一。这并不意味着不应该从单个服务中收集度量数据，而是通过服务网关可以集中收集许多基本度量数据，如服务调用次数和服务响应时间。

等等——难道服务网关不是单点故障和潜在瓶颈吗？

在第 4 章中介绍 Eureka 时，我讨论了集中式负载均衡器是如何成为单点故障和服务瓶颈的。如果没有正确地实现，服务网关会承受同样的风险。在构建服务网关实现时，要牢记以下几点。

在单独的服务组前面，负载均衡器仍然很有用。在这种情况下，将负载均衡器放到多个服务网关实例前面的是一个恰当的设计，它确保服务网关实现可以伸缩。将负载均衡器置于所有服务实例的前面并不是一个好主意，因为它会成为瓶颈。

要保持为服务网关编写的代码是无状态的。不要在内存中为服务网关存储任何信息。如果不小心，就有可能限制网关的可伸缩性，导致不得不确保数据在所有服务网关实例中被复制。

要保持为服务网关编写的代码是轻量的。服务网关是服务调用的“阻塞点”，具有多个数据库调用的复杂代码可能是服务网关中难以追踪的性能问题的根源。

我们现在来看看如何使用 Spring Cloud 和 Netflix Zuul 来实现服务网关。