vlambda博客
学习文章列表

接下来的几节将演示如何 在真实场景中使用配置服务器。为此，我们将修改我们的搜索微服务（chapter7.search）以使用配置服务器。以下 diagram 描述了该场景：

在此示例中，搜索服务将通过传递服务名称在启动时读取 Config Server。在这种情况下，搜索服务的服务名称将是 search-service。为 search-service 配置的属性包括 RabbitMQ 属性和自定义属性。

以下步骤需要遵循 使用 STS 创建一个新的配置服务器：

        $ cd $HOME
        $ mkdir config-repo
        $ cd config-repo
        $ git init .
        $ echo message : helloworld > application.properties
        $ git add -A .
        $ git commit -m "Added sample application.properties"

这将在本地文件系统上创建一个新的 Git 存储库。还创建了一个名为 application.properties 的属性文件，其中包含属性消息和值 helloworld。

        server.port=8888
        spring.cloud.config.server.git.uri:
          file://${user.home}/config-repo

        @EnableConfigServer
        @SpringBootApplication
        publicclass ConfigserverApplication {

        {"name":"application","profiles":["default"],"label":"master",
          "version":"6046fd2ff4fa09d3843767660d963866ffcc7d28",
          "propertySources":[{"name":"file:///Users/rvlabs
          /config-repo /application.properties","source":
          {"message":"helloworld"}}]}

在上一节中，我们使用 http://localhost:8888/application/default/master 来探索属性。我们如何解释给定的 URL？

URL 中的第一个元素是应用程序名称。在最后一个示例中，应用程序名称应为 application。应用程序名称是使用 spring.application 提供给应用程序的逻辑 name。 Spring Boot 应用程序的 bootstrap.properties 中的 name 属性。每个应用程序必须有一个唯一的名称。 Config Server 将使用该名称来解析并从 Config Server 存储库中获取适当的属性。应用程序名称有时也称为服务 ID。如果有一个名为 myapp 的应用程序，那么配置库中应该有一个 myapp.properties 来存储所有相关的属性到那个应用程序。

URL 的第二部分代表配置文件。一个应用程序的存储库中可以配置多个配置文件。配置文件可用于各种场景。两种常见的场景是隔离不同的环境，例如 Dev、Test、Stage、Prod 等，或者隔离服务器配置，例如主要、次要等。第一个代表应用程序的不同环境，而第二个代表部署应用程序的不同服务器。

配置文件名称是逻辑名称，将用于匹配存储库中的文件名。默认配置文件命名为 default。要为不同的环境配置属性，我们必须配置不同的文件，如下所示。在此示例中，第一个文件用于开发环境，而第二个文件用于生产环境：

    application-development.properties
    application-production.properties

可以使用以下 URL 访问它们：

http://localhost:8888/application/development

http://localhost:8888/application/production

URL 的最后一部分是 label，默认命名为 master。 label 是一个可选的 Git 标签，如果需要可以使用。

简而言之，URL 就是基于这种模式：

http://localhost:8888/{name}/{profile}/{label}

也可以通过忽略配置文件来访问配置。在给定的示例中，以下所有三个 URL 都指向相同的配置：

http://localhost:8888/application/default

http://localhost:8888/application/master

http://localhost:8888/application/default/master

可以选择为不同的配置文件使用不同的 Git 存储库。这对于生产系统是有意义的，因为对不同存储库的访问可能不同。

Accessing the Config Server from clients

在上一节中，使用 Web 浏览器设置并访问 配置服务器。在本节中，将修改 Search 微服务以使用 Config Server。搜索微服务将充当配置客户端。

Follow the steps listed next to use the Config Server instead of reading properties from the application.properties file:

1. Add the Spring Cloud Config dependency and the Actuator (if Actuator is not already in place) to pom.xml. The Actuator is mandatory for refreshing the configuration properties:

        <dependency>
          <groupId>org.springframework.cloud</groupId>
          <artifactId>spring-cloud-starter-config</artifactId>
        </dependency>

Copy

2. Add the following to include the Spring Cloud dependencies. This is not required if the project is created from scratch:

        <dependencyManagement>
          <dependencies>
          <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dependencies</artifactId>  
        <version>Dalston.BUILD-SNAPSHOT</version>
        <type>pom</type>
        <scope>import</scope>
        </dependency>
        </dependencies>
        </dependencyManagement>

Copy

 

 

 

 

3. The following screenshot shows the Cloud starter library selection screen. If the application is built from the ground up, select the libraries as shown here:

4. Rename the application.properties to bootstrap.properties, and add an application name and a configuration server URL. The configuration server URL is not mandatory if the Config Server is running on the default port (8888) on the local host.

新的 bootstrap.properties 文件将如下所示：

        spring.application.name=search-service
        spring.cloud.config.uri=http://localhost:8888
        server.port=8090
        spring.rabbitmq.host=localhost
        spring.rabbitmq.port=5672
        spring.rabbitmq.username=guest
        spring.rabbitmq.password=guest

Copy

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

search-service 是搜索微服务的逻辑名称。这将被视为服务 ID。配置服务器将在存储库中查找 search-service.properties 以解析属性。

5. Create a new configuration file for search-service. Create a new search-service.properties under the config-repo folder where the Git repository is created. Note that search-service is the service ID given to the Search microservice in the bootstrap.properties file. Move service-specific properties from bootstrap.properties to the new search-service.properties. The following properties will be removed from bootstrap.properties and added to search-service.properties:

        spring.rabbitmq.host=localhost
        spring.rabbitmq.port=5672
        spring.rabbitmq.username=guest
        spring.rabbitmq.password=guest

Copy

6. In order to demonstrate the centralized configuration of properties and propagation of changes, add a new application-specific property to the property file. We will add originairports.shutdown to temporarily take out an airport from the search. Users will not get any flights when searching with an airport mentioned in the shutdown list:

        originairports.shutdown=SEA

Copy

在前面的示例中，当以 SEA 为始发地进行搜索时，我们不会返回任何航班。

7. Commit this new file into the Git repository by executing the following commands:

        git add –A .
        git commit –m “adding new configuration”      

Copy

最终的 search-service.properties 文件应如下所示：

        spring.rabbitmq.host=localhost
        spring.rabbitmq.port=5672
        spring.rabbitmq.username=guest
        spring.rabbitmq.password=guest
        originairports.shutdown:SEA

Copy

 

 

chapter7.search 项目的 bootstrap.properties 应该如下所示：

        spring.application.name=search-service
        server.port=8090
        spring.cloud.config.uri=http://localhost:8888

Copy

8. Modify the Search microservice code to use the configured parameter, originairports.shutdown. A RefreshScope annotation has to be added at the class level to allow properties to be refreshed when there is a change. In this case, we are adding a refresh scope to the SearchRestController class.

        @RefreshScope

Copy

9. Add the following instance variable as a placeholder for the new property that is just added in the Config Server. The property names in the search-service.properties must match:

        @Value("${originairports.shutdown}")
        private String originAirportShutdownList;

Copy

10. Change the application code to use this property. This is done by modifying the search method as follows:

        @RequestMapping(value="/get", method = RequestMethod.POST)
        List<Flight> search(@RequestBody SearchQuery query){
logger.info("Input : "+ query);
          if(Arrays.asList(originAirportShutdownList.split(","))
          .contains(query.getOrigin())){
logger.info("The origin airport is in shutdown state");
            returnnew ArrayList<Flight>();
          }
          return searchComponent.search(query);
        }

Copy

修改搜索方法，读取参数originAirportShutdownList，查看请求的origin是否在关闭列表中。如果匹配，搜索方法将返回一个空的航班列表，而不是进行实际搜索。

11. Start the Config Server. Then start the Search microservice. Make sure that the Rabbit MQ server is running.
12. Modify the chapter7.website project to match the bootstrap.properties content, as follows, to utilize the Config Server:

        spring.application.name=test-client
        server.port=8001
        spring.cloud.config.uri=http://localhost:8888

Copy

13. Change the CommandLineRunner's run method in Application.java to query SEA as origin airport.

        SearchQuery searchQuery = new SearchQuery(
          "SEA","SFO","22-JAN-18");

Copy

14. Run the chapter7.website project. CommandLineRunner will now return an empty flight list. The following message will be printed in the server:

        The origin airport is in shutdown state

Copy

/refresh 端点将 refresh 本地缓存的配置属性并重新加载来自配置服务器的值。

为了强制重新加载配置属性，请调用微服务的 /refresh 端点。这实际上是 Actuator 的刷新端点。以下命令将向 /refresh 端点发送一个空 POST：

curl –d {} localhost:8090/refresh

通过上述方法，可以在不重新启动微服务的情况下更改配置参数。当只有一个或两个 instances 服务运行时，这很好。如果有很多实例会发生什么？

例如，如果有五个实例，那么我们必须针对每个服务实例点击 /refresh。这绝对是一项繁琐的活动。

下图展示了使用 Spring Cloud Bus 的解决方案：

Spring Cloud Bus 提供了一种机制来跨多个实例刷新配置，而无需知道有多少实例，也不知道它们的位置。当有许多微服务的服务实例在运行时，或者当有许多不同类型的微服务在运行时，这特别方便。这是通过单个消息代理连接所有服务实例来完成的。每个实例都订阅更改事件并在需要时刷新其本地配置。通过点击 /bus/refresh 端点调用任何一个实例来触发此刷新，然后通过云总线和公共消息代理传播更改。

前面的部分探索了如何设置配置服务器，允许实时刷新配置属性。但是，配置服务器是 single 点的 failure 在这个架构中。

上一节建立的默认架构中存在三个单点故障。其中之一是 Config Server 本身的可用性，第二个是 Git 存储库，第三个是 RabbitMQ 服务器。

下图显示了 Config Server 的高可用性架构：

架构机制和原理解释如下：

配置服务器需要高可用性，因为如果配置服务器不可用，服务将无法引导。因此，高可用性需要冗余配置服务器。但是，如果服务启动后配置服务器不可用，应用程序可以继续运行。在这种情况下，服务将以最后已知的配置状态运行。因此，Config Server 可用性与微服务可用性不在同一关键级别。

为了使配置服务器具有高可用性，我们需要配置服务器的多个实例。由于 Config Server 是一个无状态的 HTTP 服务，因此可以并行运行多个配置服务器实例。根据配置服务器上的负载，必须调整多个实例。 bootstrap.properties 不能处理多个服务器地址。因此，应该将多个配置服务器配置为在负载平衡器之后或具有故障转移和回退功能的本地 DNS 之后运行。负载均衡器或 DNS 服务器 URL 将在微服务 bootstrap.properties 中配置。这是假设 DNS 或负载平衡器具有高可用性并且能够处理故障转移。

在生产场景中，不建议使用基于本地文件的 Git 存储库。配置服务器通常应该由高可用性 Git 服务支持。这可以通过使用外部高可用性 Git 服务或高可用性内部 Git 服务来实现。也可以考虑SVN。

话虽如此，已经引导的配置服务器始终能够使用配置的本地副本。因此，仅当配置服务器 需要 进行扩展时，我们才需要一个高可用性的 Git。因此，这也没有微服务可用性或 Config Server 可用性那么重要。

RabbitMQ 也必须配置为高可用性。 RabbitMQ 的高可用性仅需要将配置更改动态推送到所有实例。由于这更像是一种离线的、受控的活动，因此它并不真正需要组件所需的高可用性。

Rabbit MQ 高可用性可以通过使用 cloud 服务或本地配置的高可用性 Rabbit MQ 服务来实现。

Config Server 只不过是一个 Spring Boot 应用程序，默认情况下，配置有一个 Actuator。因此，所有 Actuator 端点都适用于 云服务器。 server 的运行状况可以使用以下 Actuator URL 进行监控：

http://localhost:8888/health

我们可能会遇到需要一个完整的配置文件外化的场景，比如 logback.xml。 Config Server 提供了一种机制来配置和存储这些文件。这可以通过使用如下 URL 格式来实现：

    /{name}/{profile}/{label}/{path}

name、profile 和 label 的含义如前所述.路径表示文件名，如logback.xml。

为了将这种能力构建到完整的BrownField Airline 的PSS，我们必须为所有服务使用配置服务器。

我们目前没有将搜索、预订和登记服务中使用的队列名称外部化。在本章后面，这些将被更改为使用 Spring Cloud Streams。

动态注册主要是来自service 供应商的观点。通过动态注册，当新服务启动时，它会自动在中央服务注册表中登记其可用性。同样，当服务停止服务时，它会自动从服务注册表中除名。注册表始终保持可用服务的最新信息及其元数据。

从服务消费者的角度来看，动态发现是适用的。动态发现是客户端查找服务注册表以获取服务拓扑的当前状态，然后相应地调用服务的地方。在这种方法中，不是静态配置服务 URL，而是从服务注册表中获取 URL。

客户端可以保留注册表数据的本地缓存以便更快地访问。一些注册表实现允许客户端监视他们感兴趣的项目。在这种方法中，注册表服务器中的状态更改将传播给相关方，以避免使用过时的数据。

有许多选项可用于动态服务注册和发现。 Netflix Eureka、Zookeeper 和 Consul 作为 Spring Cloud 的一部分提供，如 start.spring 所示。 io 截图如下。 etcd 是 Spring Cloud 之外的另一个服务注册中心，用于实现动态服务注册和发现。在本章中，我们将重点介绍 Eureka 的实现：

Spring Cloud Eureka 也来自 来自 Netflix OSS。 Spring Cloud 项目提供了一种 Spring 友好的声明式方法，用于将 Eureka 与基于 Spring 的应用程序集成。 Eureka 主要用于自注册、动态发现和负载平衡。 Eureka 内部使用 Ribbon 进行负载平衡。

如上图所示，Eureka 由一个服务器组件和一个客户端组件组成。服务器组件是所有微服务在其中注册其可用性的注册表。注册通常包括服务标识及其 URL。微服务使用 Eureka Client 来注册它们的可用性。消费组件将也使用Eureka Client 用于发现服务实例。

当微服务被引导时，它到达到Eureka Server 并通过绑定信息宣传其存在。注册后，服务端点每 30 秒向注册表发送 ping 请求以更新其租约。如果服务端点无法续订几次租约，则该服务端点将从服务注册表中取出。注册表信息被复制到所有 Eureka 客户端，因此客户端需要为每个请求转到远程 Eureka Server。 Eureka 客户端从服务器获取注册信息并在本地缓存。之后，客户使用该信息来查找其他服务。通过获取最后一个获取周期和当前周期之间的增量更新，定期（每 30 秒）更新此信息。

当客户端想要联系微服务端点时，Eureka Client 会根据请求的服务 ID 提供当前可用服务的列表。 Eureka Server 是区域感知的。注册服务时也可以提供区域信息。

当客户端请求服务实例时，Eureka 服务会尝试查找在同一区域中运行的服务。然后，Ribbon 客户端在 Eureka Client 提供的这些可用服务实例之间进行负载平衡。 Eureka Client 和 Eureka Server 之间的通信使用 REST 和JSON。

在本节中，我们将运行 通过 设置 Eureka Server 所需的步骤。

启动一个新的 Spring Starter 项目并选择 Config Client, Eureka Server 和 Actuator，如下图所示：

Eureka 服务器的项目结构如下图所示：

请注意，主应用程序名为 EurekaserverApplication.java。

将 application.properties 重命名为 bootstrap.properties，因为这是使用配置服务器。正如我们之前所做的那样，在 bootsratp.properties 中配置 Config Server 的详细信息，以便它可以找到 Config Server 实例。 bootstrap.properties 将如下所示：

        spring.application.name=eureka-server1
        server.port:8761
        spring.cloud.config.uri=http://localhost:8888

Eureka Server 可以设置为独立模式或集群模式。我们将从独立模式开始。默认情况下，Eureka Server 本身就是另一个 Eureka Client。当有多个 Eureka 服务器运行以实现高可用性时，这尤其有用。客户端组件负责从其他 Eureka 服务器同步状态。通过配置 eureka.client.serviceUrl.defaultZone 属性，Eureka Client 被带到它的对等点。

在独立模式下，我们会将 eureka.client.serviceUrl.defaultZone 指向同一个独立实例。稍后，我们将看到如何以集群模式运行 Eureka 服务器。

执行以下步骤来设置 Eureka 服务器：

        spring.application.name=eureka-server1
        eureka.client.serviceUrl.defaultZone:http:
          //localhost:8761/eureka/
        eureka.client.registerWithEureka:false
        eureka.client.fetchRegistry:false     

        @EnableEurekaServer
        @SpringBootApplication
        publicclass EurekaserverApplication {

http://localhost:8761

        <dependency>
          <groupId>org.springframework.cloud</groupId>
          <artifactId>spring-cloud-starter-eureka</artifactId>
        </dependency>

以下属性必须添加到 config-repo 下各自配置文件中的所有微服务中。这将有助于微服务连接到 Eureka Server。更新完成后提交到 Git：

        eureka.client.serviceUrl.defaultZone: 
          http://localhost:8761/eureka/

        @FeignClient(name="fares-service")
        publicinterface FareServiceProxy {    
          @RequestMapping(value = "fares/get",
          method=RequestMethod.GET)
          Fare getFare(@RequestParam(value="flightNumber") 
          String flightNumber, @RequestParam(value="flightDate") 
          String flightDate);
        }

        <dependency>
          <groupId>org.springframework.cloud</groupId>
          <artifactId>spring-cloud-starter-feign</artifactId>
        </dependency>

http://localhost:8761

        spring.application.name=test-client
        eureka.client.serviceUrl.defaultZone: 
          http://localhost:8761/eureka/

        @Configuration
        class AppConfiguration {
          @LoadBalanced
          @Bean
          RestTemplate restTemplate() {
            returnnew RestTemplate();
          }
        }
        @Autowired
        RestTemplate restClient;

        Flight[] flights = searchClient.postForObject(
          "http://search-service/search/get",
           searchQuery, Flight[].class);=

          long bookingId = bookingClient.postForObject(
            "http://book-service/booking/create", booking, long.class);

          long checkinId = checkInClient.postForObject(
          "http://checkin- service/checkin/create", checkIn,
           long.class);

在前面的示例中，在独立模式下只有一个 Eureka 服务器。这对于真正的生产系统来说还不够好。

Eureka Client 连接到服务器，获取注册表信息，并将其存储在本地缓存中。客户端始终使用此本地缓存。 Eureka Client 会定期检查服务器是否有任何状态更改。如果发生状态更改，它会从服务器下载更改并更新缓存。如果 Eureka Server 不可达，那么 Eureka Client 仍然可以根据客户端缓存中可用的数据使用服务器的最后一个已知状态。但是，这可能会很快导致陈旧状态问题。

本节将探讨 Eureka Server 的高可用性。高可用性架构如下图所示：

Eureka Server 采用点对点数据同步机制构建。运行时状态信息不存储在数据库中，而是使用内存缓存进行管理。高可用性实现有利于 CAP 定理中的可用性和分区容错性，而忽略了一致性。由于 Eureka Server 实例使用异步机制相互同步，因此服务器实例之间的状态可能并不总是匹配。点对点同步是通过将服务 URL 相互指向来完成的。如果有多个 Eureka Server，则每一个都必须连接到至少一个对等服务器。由于状态在所有对等方之间复制，因此 Eureka 客户端可以连接到任何可用的 Eureka 服务器。

为 Eureka 实现高可用性的最佳方法是集群多个 Eureka 服务器并在负载均衡器或本地 DNS 后面运行它们。客户端始终使用 DNS 或负载平衡器连接到服务器。在运行时，负载均衡器将负责选择合适的服务器。此负载均衡器地址将提供给 Eureka 客户端。

本节将展示如何在集群中运行两台 Eureka 服务器以实现高可用性。为此，定义两个属性文件——eureka-server1 和 eureka-server2。这些是对等服务器——如果一个失败，另一个将接管。这些服务器中的每一个也将充当另一个的客户端，以便它们可以同步它们的状态。接下来定义定义的两个属性文件。将这些属性上传并提交到 Git 存储库。在以下配置中，客户端 URL 相互指向，形成对等网络：

  #eureka-server1.properties
  eureka.client.serviceUrl.defaultZone:http://localhost:8762/eureka/
  eureka.client.registerWithEureka:false
  eureka.client.fetchRegistry:false

  #eureka-server2.properties
  eureka.client.serviceUrl.defaultZone:http://localhost:8761/eureka/
  eureka.client.registerWithEureka:false
  eureka.client.fetchRegistry:false

更新Eureka的bootstrap.properties，将应用名称改为eureka。由于我们使用两个配置文件，配置服务器将根据活动配置文件查找 eureka-server1 或 eureka-server2启动时提供：

  spring.application.name=eureka
  spring.cloud.config.uri=http://localhost:8888

在 8761 和 server2 上启动两个 Eureka 服务器实例 - server1在 8762 上：

    java -jar –Dserver.port=8761 -Dspring.profiles.active=server1
      demo-0.0.1-SNAPSHOT.jar

    java -jar –Dserver.port=8762 -Dspring.profiles.active=server2
      demo-0.0.1-SNAPSHOT.jar

我们所有的服务仍然指向第一台服务器 server1。打开两个浏览器窗口。

http://localhost:8761http://localhost:8762

启动所有微服务。打开 8761 的那个会立即反映变化，而另一个需要 30 秒才能反映状态。由于两台服务器都在一个集群中，因此这两台服务器之间的状态是同步的。如果我们将这些服务器保留在负载平衡器或 DNS 之后，那么客户端将始终连接到可用服务器之一。

完成本练习后，切换回独立模式进行剩余练习。

与 Eureka Server 和 Config Server 不同，在典型的部署中，Zuul 是特定于微服务的。但是，在某些部署中，一个 API 网关涵盖 多个微服务。在这种情况下，我们将为我们的每个微服务添加 Zuul——搜索、预订、票价和签到。

执行以下步骤来设置 Zuul：

search-apigateway 的项目结构如下图所示：

此配置还设置了有关如何转发流量的规则。在这种情况下，API 网关的 /api 端点上的任何请求都应该发送到搜索服务：

        spring.application.name=search-apigateway
        zuul.routes.search-apigateway.serviceId=search-service
        zuul.routes.search-apigateway.path=/api/**
        eureka.client.serviceUrl.defaultZone:
        http://localhost:8761/eureka/

search-service是Search服务的服务ID，会使用Eureka Server解析。

        spring.application.name=search-apigateway
        server.port=8095
        spring.cloud.config.uri=http://localhost:8888

        @EnableZuulProxy
        @EnableDiscoveryClient
        @SpringBootApplication
        publicclass SearchApiGateway {

        Flight[] flights = searchClient.postForObject(
          "http://search-apigateway/api/search/get",
          searchQuery, Flight[].class);

在这种情况下，Zuul 代理充当反向代理，将所有微服务端点代理给消费者。在前面的示例中，Zuul 代理并没有增加太多价值，因为我们只是将传入的请求传递给相应的后端服务。

当我们有如下一个或多个需求时，Zuul 特别有用：

Zuul 还提供了许多过滤器。这些过滤器分为前置过滤器、路由过滤器、后置过滤器和错误过滤器。正如名称所示，这些应用在服务调用的不同生命周期阶段。 Zuul 还为开发人员提供了编写自定义过滤器的选项。为了编写自定义过滤器，从抽象的 ZuulFilter 扩展，并实现如下所示的方法：

    publicclass CustomZuulFilter extends ZuulFilter{
    public Object run(){}
    publicboolean shouldFilter(){}
    publicint filterOrder(){}
    public String filterType(){}

实现自定义过滤器后，将该类添加到主上下文中。在我们的示例中，将其添加到 SearchApiGateway 类中，如下所示：

    @Bean
    public CustomZuulFilter customFilter() {
      returnnew CustomZuulFilter();
    }

如前所述，Zuul 代理是一个 Spring Boot 服务。我们可以按照我们想要的方式以编程方式自定义网关。如以下代码所示，我们可以将自定义端点添加到网关，网关又可以调用后端服务：

    @RestController
    class SearchAPIGatewayController {
      @RequestMapping("/")
      String greet(HttpServletRequest req){
        return "<H1>Search Gateway Powered By Zuul</H1>";
      }
    }

在前面的例子中，它只是添加一个新的端点，并从网关返回一个值。我们可以进一步使用 @Loadbalanced RestTemplate 来调用后端服务。由于我们拥有完全控制权，我们可以进行转换、数据聚合等。我们还可以使用 Eureka API 获取服务器列表和实现完全独立的负载均衡或流量整形机制，而不是out功能区提供的开箱即用的负载平衡功能。

Zuul 只是一个带有 HTTP 端点的 stateless 服务，因此，我们可以拥有任意数量的 Zuul 实例。不需要亲和力或粘性。但是，Zuul 的可用性非常关键，因为从消费者到提供者的所有流量都流经 Zuul 代理。但是，弹性扩展要求并不像后端微服务那么重要，所有繁重的工作都在后端微服务中进行。

Zuul 的高可用架构是由我们使用 Zuul 的场景决定的。典型的使用场景如下：

在某些情况下，客户端可能无法使用 Eureka 客户端库，例如在 PL/SQL 上编写的遗留应用程序。在某些情况下，组织策略不允许 Internet 客户端处理客户端负载平衡。对于基于浏览器的客户端，可以使用第三方 Eureka JavaScript 库。

这一切都归结为客户端是否使用 Eureka 客户端库。基于此，我们可以通过两种方式设置 Zuul 以实现高可用性。

High availability of Zuul when the client is also a Eureka Client

在这种情况下，由于 客户端也是另一个 Eureka 客户端，因此可以像其他微服务一样配置 Zuul。 Zuul 本身使用服务 ID 注册到 Eureka。然后客户端使用 Eureka 和服务 ID 来解析 Zuul 实例。

如上图所示，Zuul 服务使用服务 ID 向 Eureka 注册自己，在我们的例子中是 search-apigateway。 Eureka Client 将要求 ID 为 search-apigateway 的服务器列表。 Eureka Server 返回基于当前 Zuul 拓扑的服务器列表。 Eureka Client 基于此列表，选择其中一个服务器，并发起调用。

正如我们之前看到的，客户端将使用服务 ID 来解析 Zuul 实例。下面的例子中，search-apigateway就是在Eureka注册的Zuul实例ID：

    Flight[] flights = searchClient.postForObject(
      "http://search-apigateway/api/search/get",
       searchQuery, Flight[].class);

Copy

High availability when client is not a Eureka Client

在这种情况下，客户端不能够使用Eureka Server处理负载均衡。如下图所示，客户端将请求发送到负载均衡器，负载均衡器依次识别正确的 Zuul 服务实例。

The Zuul instances, in this case, will be running behind a load balancer such as HAProxy, or a hardware load balancer like NetScaler:

Zuul 仍将使用 Eureka Server 对微服务进行负载平衡。