微服务架构下网关的技术选型

1、简介

当使用单体应用程序架构时，客户端（Web 或移动端）通过向后端应用程序发起一次 REST 调用来获取数据。负载均衡器将请求路由给 N 个相同的应用程序实例中的一个。然后应用程序会查询各种数据库表，并将响应返回给客户端。微服务架构下，单体应用被切割成多个微服务，如果将所有的微服务直接对外暴露，势必会出现安全方面的各种问题，另外内外耦合严重。

客户端可以直接向每个微服务发送请求，其问题主要如下：

• 客户端需求和每个微服务暴露的细粒度 API 不匹配。

• 部分服务使用的协议不是Web友好协议。可能使用 Thrift 二进制 RPC，也可能使用 AMQP 消息传递协议。

• 微服务难以重构。如果合并两个服务，或者将一个服务拆分成两个或更多服务，这类重构就非常困难了。

服务端的各个服务直接暴露给客户端调用势必会引起各种问题。同时，服务端的各个服务可扩展和伸缩性很差。API 网关是微服务架构中的基础组件，位于接入层之下和业务服务层之上，如前所述的这些功能适合在 API 网关实现。

1.1 什么是网关？

网关的角色是作为一个API架构，用来保护、增强和控制对于API服务的访问。它是一个处于应用程序或服务（提供REST API接口服务）之前的系统，用来管理授权、访问控制和流量限制等。这样REST API接口服务就被网关保护起来，对所有的调用者透明。因此，隐藏在API网关后面的业务系统就可以专注于创建和管理服务，无需关心这些策略性的请求。

1.2 API网关的四大职能

• 请求接入：作为所有API接口服务请求的接入点，管理所有的接入请求。

• 业务聚合：作为所有后端业务服务的聚合点，所有的业务服务都可以在这里被调用。

• 中介策略：实现安全、验证、路由、过滤、流控、缓存等策略，进行一些必要的中介处理。

• 统一管理：提供配置管理工具，对所有API服务的调用生命周期和相应的中介策略进行统一管理。

1.3 微服务下网关作用

下面图介绍了网关(Gateway)作用，可知 Gateway 方式下的架构，可以细到为每一个服务的实例配置一个自己的 Gateway，也可以粗到为一组服务配置一个，甚至可以粗到为整个架构配置一个接入的 Gateway。于是，整个系统架构的复杂度就会变得简单可控起来。

这张图展示了一个多层 Gateway 架构，其中有一个总的 Gateway 接入所有的流量(流量网关 )，并分发给不同的子系统，还有第二级 Gateway 用于做各个子系统的接入 Gateway(业务网关 )。可以看到，网关所管理的服务粒度可粗可细。通过网关，我们可以把分布式架构组织成一个星型架构，由网络对服务的请求进行路由和分发。下面来聊聊好的网关应该具备哪些功能，也就是网关设计模式。

2 、网关设计思路

API网关并不是一个典型的业务系统，而是一个为了让业务系统更专注于业务本身，给API服务提供更多附加能力的一个中间层。一个网关需要有以下的功能:

1. 请求路由

   网关一定要有请求路由的功能。这样一来，对于调用端来说，也是一件非常方便的事情。因为调用端不需要知道自己需要用到的其它服务的地址，全部统一地交给 Gateway 来处理。

2. 服务注册

   为了能够代理后面的服务，并把请求路由到正确的位置上，网关应该有服务注册功能，也就是后端的服务实例可以把其提供服务的地址注册、取消注册。一般来说，注册也就是注册一些 API 接口。比如，HTTP 的 Restful 请求，可以注册相应 API 的 URI、方法、HTTP 头。这样，Gateway 就可以根据接收到的请求中的信息来决定路由到哪一个后端的服务上。

3. 负载均衡

   因为一个网关可以接收多个服务实例，所以网关还需要在各个对等的服务实例上做负载均衡策略。简单点就是直接 Round-Robin 轮询，复杂点的可以设置上权重进行分发，再复杂一点还可以做到 session 粘连。

4. 弹力设计

   网关还可以把弹力设计中的那些异步、重试、幂等、流控、熔断、监视等都可以实现进去。这样，同样可以像 Service Mesh 那样，让应用服务只关心自己的业务逻辑（或是说数据面上的事）而不是控制逻辑（控制面）。

5. 安全方面

   SSL 加密及证书管理、Session 验证、授权、数据校验，以及对请求源进行恶意攻击的防范。错误处理越靠前的位置就是越好，所以，网关可以做到一个全站的接入组件来对后端的服务进行保护。当然，网关还可以做更多更有趣的事情，比如：灰度发布、API聚合、API编排。

6. 灰度发布

   网关完全可以做到对相同服务不同版本的实例进行导流，还可以收集相关的数据。这样对于软件质量的提升，甚至产品试错都有非常积极的意义。

7. API 聚合

   使用网关可以将多个单独请求