本章主要内容
结合微服务使用服务网关
使用Spring Cloud和Netflix Zuul实现服务网关
在Zuul中映射微服务路由
构建过滤器以使用关联ID并进行跟踪
使用Zuul进行动态路由
在像微服务架构这样的分布式架构中，需要确保跨多个服务调用的关键行为的正常运行，如安全、日志记录和用户跟踪。要实现此功能，开发人员需要在所有服务中始终如一地强制这些特性，而不需要每个开发团队都构建自己的解决方案。虽然可以使用公共库或框架来帮助在单个服务中直接构建这些功能，但这样做会造成3个影响。
第一，在构建的每个服务中很难始终实现这些功能。开发人员专注于交付功能，在每日的快速开发工作中，他们很容易忘记实现服务日志记录或跟踪。遗憾的是，对那些在金融服务或医疗保健等严格监管的行业工作的人来说，一致且有文档记录系统中的行为通常是符合政府法规的关键要求。
第二，正确地实现这些功能是一个挑战。对每个正在开发的服务进行诸如微服务安全的建立与配置可能是很痛苦的。将实现横切关注点（cross-cutting concern，如安全问题）的责任推给各个开发团队，大大增加了开发人员没有正确实现或忘记实现这些功能的可能性。
第三，这会在所有服务中创建一个顽固的依赖。开发人员在所有服务中共享的公共框架中构建的功能越多，在通用代码中无需重新编译和重新部署所有服务就能更改或添加功能就越困难。当应用程序中有6个微服务时，这似乎不是什么大问题，但当这个应用程序拥有更多的服务时（大概30个或更多），这就是一个很大的问题。突然间，共享库中内置的核心功能的升级就变成了一个数月的迁移过程。
为了解决这个问题，需要将这些横切关注点抽象成一个独立且作为应用程序中所有微服务调用的过滤器和路由器的服务。这种横切关注点被称为服务网关（service gatervay）。服务客户端不再直接调用服务。取而代之的是，服务网关作为单个策略执行点（Policy Enforcement Point，PEP），所有调用都通过服务网关进行路由，然后被路由到最终目的地。
在本章中，我们将看看如何使用Spring Cloud和Netflix的Zuul来实现一个服务网关。Zuul是Netflix的开源服务网关实现。具体来说，我们来看一下如何使用Spring Cloud和Zuul来完成以下操作。
将所有服务调用放在一个URL后面，并使用服务发现将这些调用映射到实际的服务实例。
将关联ID注入流经服务网关的每个服务调用中。
在从客户端发回的HTTP响应中注入关联ID。
构建一个动态路由机制，将各个具体的组织路由到服务实例端点，该端点与其他人使用的服务实例端点不同。
让我们深入了解服务网关是如何与本书中构建的整体微服务相适应的。
6.1 什么是服务网关
到目前为止，通过前面几章中构建的微服务，我们可以通过Web客户端直接调用各个服务，也可以通过诸如Eureka这样的服务发现引擎以编程方式调用它们。图6-1展示了没有服务网关的后果。
图6-1 如果没有服务网关，服务客户端将为每个服务调用不同的端点
服务网关充当服务客户端和被调用的服务之间的中介。服务客户端仅与服务网关管理的单个URL进行对话。服务网关从服务客户端调用中分离出路径，并确定服务客户端正在尝试调用哪个服务。图6-2演示了服务网关如何像交通警察一样指挥交通，将用户引导到目标微服务和相应的实例。服务网关充当应用程序内所有微服务调用的入站流量的守门人。有了服务网关，服务客户端永远不会直接调用单个服务的URL，而是将所有调用都放到服务网关上。
图6-2 服务网关位于服务客户端和相应的服务实例之间。所有服务调用（内部和外部）都应流经服务网关
由于服务网关位于客户端到各个服务的所有调用之间，因此它还充当服务调用的中央策略执行点（PEP）。使用集中式PEP意味着横切服务关注点可以在一个地方实现，而无须各个开发团队来实现这些关注点。举例来说，可以在服务网关中实现的横切关注点包括以下几个。
静态路由——服务网关将所有的服务调用放置在单个URL和API路由的后面。这简化了开发，因为开发人员只需要知道所有服务的一个服务端点就可以了。
动态路由——服务网关可以检查传入的服务请求，根据来自传入请求的数据和服务调用者的身份执行智能路由。例如，可能会将参与测试版程序的客户的所有调用路由到特定服务集群的服务，这些服务运行的是不同版本的代码，而不是其他人使用的非测试版程序的代码。
验证和授权——由于所有服务调用都经过服务网关进行路由，所以服务网关是检查服务调用者是否已经进行了验证并被授权进行服务调用的自然场所。
度量数据收集和日志记录——当服务调用通过服务网关时，可以使用服务网关来收集数据和日志信息，还可以使用服务网关确保在用户请求上提供关键信息以确保日志统一。这并不意味着不应该从单个服务中收集度量数据，而是通过服务网关可以集中收集许多基本度量数据，如服务调用次数和服务响应时间。
等等——难道服务网关不是单点故障和潜在瓶颈吗？
在第4章中介绍Eureka时，我讨论了集中式负载均衡器是如何成为单点故障和服务瓶颈的。如果没有正确地实现，服务网关会承受同样的风险。在构建服务网关实现时，要牢记以下几点。
在单独的服务组前面，负载均衡器仍然很有用。在这种情况下，将负载均衡器放到多个服务网关实例前面的是一个恰当的设计，它确保服务网关实现可以伸缩。将负载均衡器置于所有服务实例的前面并不是一个好主意，因为它会成为瓶颈。
要保持为服务网关编写的代码是无状态的。不要在内存中为服务网关存储任何信息。如果不小心，就有可能限制网关的可伸缩性，导致不得不确保数据在所有服务网关实例中被复制。
要保持为服务网关编写的代码是轻量的。服务网关是服务调用的“阻塞点”，具有多个数据库调用的复杂代码可能是服务网关中难以追踪的性能问题的根源。
我们现在来看看如何使用Spring Cloud和Netflix Zuul来实现服务网关。