api网关 聚合服务_适用于Java开发人员的微服务：API网关和聚合器

api网关 聚合服务

1.简介

在这篇文章中，我们将介绍有关微服务API网关和聚合器的综合文章。 在本教程的最后一部分中，我们讨论了微服务架构中的服务如何相互发现的不同方法。 希望这是一个有益的讨论，但是我们完全没有涉及其他消费者（例如台式机，Web前端或移动客户端）如何应对此类挑战的话题。

典型的前端或移动应用程序可能需要与数十个微服务进行通信，例如，在REST（ful）服务后端的情况下，这些微服务需要了解如何定位每个有问题的端点。 在这种情况下，使用服务发现或服务注册表是不切实际的，因为这些基础结构组件不应公开访问。 除了在客户端可以使用的某种配置设置（通常是配置文件）中预填充服务连接详细信息之外，这没有留下很多其他选项。

总的来说，这种方法行之有效，但又带来了另一个问题：客户端与服务之间的往返次数激增。 对于经常通过非常慢且不可靠的网络通道进行通信的移动客户端而言，这尤其令人痛苦。 不仅如此，在基于云的部署中，如果许多云提供商按请求数（或调用数）向您收费，这可能会非常昂贵。 这个问题是真实的，需要解决，但是如何解决呢？ 这是舞台上出现API网关模式的时刻。

关于API网关的实际定义有许多正式和非正式的定义，下面的定义试图用几句话涵盖它的所有方面。

API网关 是充当API前端，接收API请求，执行限制和安全策略，将请求传递到后端服务，然后将响应传递回请求者的服务器。 网关通常包括一个转换引擎，以即时组织和修改请求和响应。 网关还可以提供功能，例如收集分析数据和提供缓存。 网关可以提供支持身份验证，授权，安全性，审计和法规遵从性的功能。

https://zh.wikipedia.org/wiki/API_management

关于API网关定义的更抽象和更简短的描述来自出色的博客文章。API网关不是新的Unicorn ，强烈推荐阅读。

API网关是一种解决客户端如何在微服务模式下的基于微服务的生态系统中消费其用例的问题的方式– https://www.krakend.io/blog/what-is-an-api-gateway /

在本教程的其余部分中，我们将讨论在野外可用的各种API网关 ，以及在什么情况下它们可能有用。

2. Zuul 2

Zuul出生于Netflix，并充当所有向其流后端发送请求的大门。 它是网关服务（有时也称为边缘服务），提供动态路由，监视，弹性，安全性以及更多其他功能。 它最近进行了重大改进，并已更名为下一代Zuul 2 。

本质上， Zuul提供了基本的构建块，但其他所有内容（例如路由规则）都通过过滤器和端点抽象进行定制。 此类扩展应使用Groovy （首选的脚本语言）实现。 例如， JCG租车平台通过提供自己的入站筛选器实现，大量使用Zuul将请求转发到其所有服务。

class Routes extends HttpInboundSyncFilter {
    @Override
    int filterOrder() {
        return 0
    }

    @Override
    boolean shouldFilter(HttpRequestMessage httpRequestMessage) {
        return true
    }

    @Override
    HttpRequestMessage apply(HttpRequestMessage request) {
        SessionContext context = request.getContext()
        
        if (request.getPath().equals("/inventory") || request.getPath().startsWith("/inventory/")) {
            request.setPath("/api" + request.getPath())
            context.setEndpoint(ZuulEndPointRunner.PROXY_ENDPOINT_FILTER_NAME)
            context.setRouteVIP("inventory")
        } else if (request.getPath().equals("/customers") || request.getPath().startsWith("/customers/")) {
            request.setPath("/api" + request.getPath())
            context.setEndpoint(ZuulEndPointRunner.PROXY_ENDPOINT_FILTER_NAME)
            context.setRouteVIP("customers")
        } else if (request.getPath().equals("/reservations") || request.getPath().startsWith("/reservations/")) {
            request.setPath("/api" + request.getPath())
            context.setEndpoint(ZuulEndPointRunner.PROXY_ENDPOINT_FILTER_NAME)
            context.setRouteVIP("reservations")
        } else if (request.getPath().equals("/payments") || request.getPath().startsWith("/payments/")) {
            request.setPath("/api" + request.getPath())
            context.setEndpoint(ZuulEndPointRunner.PROXY_ENDPOINT_FILTER_NAME)
            context.setRouteVIP("payments")
        } else {
            context.setEndpoint(NotFoundEndpoint.class.getCanonicalName())
        }

        return request
    }
}

Zuul非常灵活，可让您完全控制API管理策略。 除了许多其他功能之外，它还与Eureka（用于服务发现）和Ribbon（用于负载平衡）很好地集成在一起。 服务器初始化非常简单。

public class Bootstrap {
    public static void main(String[] args) {
        Server server = null;

        try {
            ConfigurationManager.loadCascadedPropertiesFromResources("application");
            final Injector injector = InjectorBuilder.fromModule(new RentalsModule()).createInjector();
            final BaseServerStartup serverStartup = injector.getInstance(BaseServerStartup.class);
            server = serverStartup.server();
            server.start(true);
        } catch (final IOException ex) {
            throw new UncheckedIOException(ex);
        } finally {
            // server shutdown
            if (server != null) {
                server.stop();
            }
        }
    }
}

它已经在生产中经过多年的考验，其作为API网关和/或边缘服务的有效性在Netflix的规模上得到了证明。

3. Spring Cloud Gateway

Spring Cloud Gateway是Spring平台的成员，它是一个库，可帮助您利用Spring MVC和Spring WebFlux构建自己的API网关 。 第一代Spring Cloud Gateway是在Zuul之上构建的，但现在不再如此了。 新一代已将动力总成改为Spring自己的Project Reactor及其生态系统。

让我们看一下JCG租车平台如何利用Spring Cloud Gateway为其API提供边缘入口点。

server:
  port: 17001

spring:
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true
      routes:
      - id: inventory
        uri: lb://inventory-service
        predicates:
        - Path=/inventory/**
        filters:
        - RewritePath=/(?.*), /api/$\{path}
      - id: customers
        uri: lb://customer-service
        predicates:
        - Path=/customers/**
        filters:
        - RewritePath=/(?.*), /api/$\{path}
      - id: reservations
        uri: lb://reservation-service
        predicates:
        - Path=/reservations/**
        filters:
        - RewritePath=/(?.*), /api/$\{path}
      - id: payments
        uri: lb://payment-service
        predicates:
        - Path=/payments/**
        filters:
        - RewritePath=/(?.*), /api/$\{path}
        
eureka:
  instance:
    appname: api-gateway
    preferIpAddress: true
  client:
    register-with-eureka: false
    fetch-registry: true
    healthcheck:
      enabled: true
    service-url:
      defaultZone: http://localhost:20200/eureka/

如您所见，我们使用纯配置驱动的方法以及Eureka集成来进行服务发现。 使用Spring Boot运行服务器只需要几行代码。

@SpringBootApplication
@EnableDiscoveryClient
public class GatewayStarter {
    public static void main(String[] args) {
        SpringApplication.run(GatewayStarter.class, args);
    }
}

与Zuul 2相似， Spring Cloud Gateway允许您将API网关对微服务架构要求的任何功能进行切片和切块。 但是，维护和学习操作方法也成为您的责任。

建立自己的API网关的好处之一是可以对多种服务执行聚合和扇出操作。 这样，由于API网关负责将多个响应拼接在一起，因此可以大大减少客户端必须执行的往返次数。 不过，这条道路还有阴暗的一面 ，请继续关注。

4. HAProxy

在本教程的上半部分中，我们主要将HAProxy用作负载平衡器 ，但是其功能还使其可以用作API网关 。 如果HAProxy已经进入您的微服务体系结构 ，则值得考虑尝试以API网关的身份进行尝试。

5.微网关

StrongLoop的Microgateway很好地说明了JavaScript特别是Node.js生态系统中正在发生的创新。

该 Microgateway 是一个开发者为中心的，可扩展的网关写在Node.js的强制执行进入微服务和API框架。 – https://strongloop.com/projects/

6.Kong

Kong是最早出现在Mashape中的API网关 之一，以应对其微服务部署的挑战。

Kong是可扩展的开源API层（也称为API网关或API中间件）。 Kong在任何RESTful API之前运行，并通过 Plugins 扩展， Plugins 提供 了核心平台之外的其他 功能和服务 。 – https://konghq.com/about-kong/

Kong是在Lua上撰写的，它建立在nginx的坚实基础（我们在本教程的上半部分已经讨论过）的基础上 ，并与功能完善的nginx驱动的 Web平台OpenResty一起分发。

7. Gravitee.io

从专注的API网关解决方案，我们将从开源API平台Gravitee.io开始逐步向更强大的选项发展。

Gravitee.io 是一个灵活，轻便且快速的开源API平台，可帮助您的组织精确控制用户，何时以及如何访问您的API。 – https://gravitee.io/

Gravitee.io平台由三个核心组件组成：中心是API网关 ，被Management API和Management Web Portal包围。

8.Tyk

Tyk是轻量级且全面的API平台的另一个示例，其核心是API网关 。

Tyk 是一个快速，可扩展和现代的开源API网关。 Tyk开箱即用，提供了一个带有API网关，API Analytics，开发人员门户和API管理仪表板的API管理平台。 – https://tyk.io/

Tyk用Go编写，易于分发和部署。 它具有很多关键功能 ，重点是API分析和访问管理。

9.大使

Kubernetes的高度流行导致API网关的兴起，而API网关本可以在其上运行。 该类别的先驱之一是Datawire的 大使 。

Ambassador 是一个 基于 Envoy的 开源 Kubernetes原生 API网关 ，专为微服务而设计。 大使 本质上是作为 Envoy 入口控制器的，但具有更多功能。 – https://github.com/datawire/ambassador

由于大多数组织都在利用Kubernetes部署其微服务 团队 ，因此大使一直在该领域占据领导地位。

10. Gloo

另一个著名的Kubernetes原生 API网关代表是Gloo ，由solo.io开源并维护。

Gloo 是功能丰富的 Kubernetes 本地入口控制器和下一代API网关。 Gloo在功能级别的路由方面表现出色。 对旧版应用程序，微服务和无服务器的支持； 它的发现能力； 其众多功能； 并与领先的开源项目紧密集成。 – https://gloo.solo.io/

Gloo建立在Envoy的顶部。 与众多无服务器产品的无缝集成使Gloo成为真正独特的解决方案。

11.前端后端（BFF）

如今 ，许多基于微服务的平台面临的挑战之一是应对各种不同类型的消费者（移动设备，桌面应用程序，Web前端……）。 由于每个消费者都有自己独特的需求和要求，因此与现实相冲突，无法与一应俱全的后端服务竞争。

API网关可能会有所帮助，通常会为每个消费者量身定制API的爆炸性便利。 为了解决这些缺点，出现了“ 后端后端 （ BFF ）”模式并获得了一定的吸引力。 特别是在GraphQL的支持下，它成为解决该问题的非常有效的解决方案。

让我们快速浏览一下基于GraphQL和Apollo GraphQL堆栈的包含BFF组件的JCG租车平台。 实现本身使用REST数据源将工作透明地委派给客户 ，该客户只需要使用GraphQL查询就可以查询所需的内容，即可将工作委派给Reservation Service ， Customer Service或/和Inventory Service 。

query {
  reservations(customerId: $customerId) {
    from
    to
  }
  profile(id: $customerId) {
    firstName
    lastName
  }
}

BFF ，尤其是GraphQL ，可能不会被分类为传统的API网关，但是在处理众多不同的客户端时，它无疑是一个非常有用的模式。 BFF带来的主要好处是能够针对特定客户端或平台进行优化，但它们也可能会轻易地转移到危险区域 。

12.建立自己的

如果现有方法都无法满足您的微服务架构需求，那么总有可能构建自己的方法。 充分利用Apache Camel或Spring Integration等成熟的集成框架可能是使您到达那里的最佳途径。 而且，如果您已经开始押注这些框架，那么使用熟悉的范式比学习另一种技术要有效得多（扰流警报，不要被炒作误导您）。

13.云

每个主要的云提供商都至少提供一种API网关产品。 它可能不是一流的，但希望足够好。 从好的方面来说，它可以与许多其他产品无缝集成，特别是与安全性和访问控制有关的产品。

需要涉及的一个有趣主题是了解API网关在无服务器计算中的作用是什么？ 可以肯定地说API网关是这种体系结构中非常核心的组件，因为它提供了无服务器执行模型的入口点之一。 如果琐碎的微服务部署可以在没有API网关的情况下顺利进行，那么无服务器的无服务器可能无法实现。

14.在黑暗的一面

在API网关的利基市场中争夺领导权的斗争迫使供应商将越来越多的功能注入其产品中，这实质上重塑了API网关是什么的定义，并直接导致身份危机 。 ThoughtWorks在其出色的技术雷达中特别出色地概括了这个问题。

我们仍然关注在中间件中实现的业务逻辑和流程编排，尤其是在创建扩展和控制单点时，需要专业技能和工具的地方。 竞争激烈的API网关市场中的供应商通过添加功能来尝试使其产品与众不同，从而继续保持这一趋势。 这导致了过分雄心勃勃的API网关产品，其功能（本质上是反向代理之外），鼓励了仍然难以测试和部署的设计。 API网关确实提供了处理某些特定问题（例如身份验证和速率限制）的实用程序，但是任何域智能都应存在于应用程序或服务中。 – https://www.thoughtworks.com/radar/platforms/overambitious-api-gateways

这些问题是无法想象的，而且确实在许多组织中正在发生。 请认真对待它，并避免在旅途中遇到陷阱。

15.微服务API网关和聚合器–结论

在本教程的这一部分中，我们确定了API网关的作用，这是现代微服务体系结构中的另一个关键部分。 与BFF一起 ，它可以解决许多跨领域的问题，并消除了消费者不必要的负担，但是却以增加复杂性为代价。 我们还讨论了组织在引入API网关和BFF时遇到的常见陷阱，其他人犯的错误，您应该学习和避免。

16.接下来是什么

在本教程的下一部分中，我们将讨论专门适用于微服务的部署和编排。

翻译自: https://www.javacodegeeks.com/2019/06/microservices-api-gateways-aggregators.html

api网关 聚合服务