微服务架构必读篇-网关

前言

由于互联网的高速发展，网络数据请求数激增，使得服务器承受的压力越来越大。在早期的系统架构中，为减轻单台服务器的压力，通常使用 Load Balancer 来将网络流量平摊到多个服务器中。如今后端服务的种类和数量在不断变多，传统的 Load Balancer 为主的系统架构的局限性就变得明显起来，于是一款主要工作在七层且具有丰富扩展能力的基础设施便应运而生，那便是API Gateway。

什么是API网关

API网关简单来说是一种主要工作在七层、专门用于 API 的管理和流量转发的基础设施，并拥有强大的扩展性。

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

网关工作流程如下图：

网关必须具备的特点

1.高性能

对于高性能而言，网关不应该也不能成为性能的瓶颈，最好使用高性能的编程语言来实现，如 C、C++、Go 和 Java。网关对后端的请求，以及对前端的请求的服务一定要使用异步非阻塞的 I/O 来确保后端延迟不会导致应用程序中出现性能问题。C 和 C++ 可以参看 Linux 下的 epoll 和 Windows 的 I/O Completion Port 的异步 IO 模型，Java 下如 Netty、Spring Reactor 的 NIO 框架。

2.高可用

所有的流量或调用都要经过网关，所以网关必须成为一个高可用的组件，它的稳定直接关系到了所有服务的稳定。不能出现单点故障，因此，一个好的网关至少做到以下几点。

集群化。网关要成为一个集群，并可以自己同步集群数据，而不需要依赖于第三方系统来同步数据。

服务化。网关还需要做到在不间断的情况下修改配置，一种是像 Nginx reload 配置那样，可以做到不停服务，另一种是最好做到服务化。也就是说，得要有自己的 Admin API 来在运行时修改配置。

持续化。比如重启，就是像 Nginx 那样优雅地重启。有一个主管请求分发的主进程。当我们需要重启时，新的请求被分配到新的进程中，而老的进程处理完正在处理的请求后就退出。

3.高扩展

网关要承接所有的业务流量和请求，所以一定存在或多或少的业务逻辑。而业务逻辑是多变和不确定的，比如，需要在网关上加入一些和业务相关的东西。因此一个好的网关还需要是可以扩展的，并能进行二次开发。当然，像 Nginx 那样通过 Module 进行二次开发的也是可以的。

网关主要功能

路由功能：路由是微服务网关的核心能力。通过路由功能微服务网关可以将请求转发到目标微服务。在微服务架构中，网关可以结合注册中心的动态服务发现，实现对后端服务的发现，调用方只需要知道网关对外暴露的服务API就可以透明地访问后端微服务。

负载均衡：API网关结合负载均衡技术，利用Eureka或者Consul等服务发现工具，通过轮询、指定权重、IP地址哈希等机制实现下游服务的负载均衡。

统一鉴权：一般而言，无论对内网还是外网的接口都需要做用户身份认证，而用户认证在一些规模较大的系统中都会采用统一的单点登录（Single Sign On）系统，如果每个微服务都要对接单点登录系统，那么显然比较浪费资源且开发效率低。API网关是统一管理安全性的绝佳场所，可以将认证的部分抽取到网关层，微服务系统无须关注认证的逻辑，只关注自身业务即可。

限流熔断：在某些场景下需要控制客户端的访问次数和访问频率，一些高并发系统有时还会有限流的需求。在网关上可以配置一个阈值，当请求数超过阈值时就直接返回错误而不继续访问后台服务。当出现流量洪峰或者后端服务出现延迟或故障时，网关能够主动进行熔断，保护后端服务，并保持前端用户体验良好。

灰度发布：微服务网关可以根据HTTP请求中的特殊标记和后端服务列表元数据标识进行流量控制，实现在用户无感知的情况下完成灰度发布。

日志审计：微服务网关可以作为统一的日志记录和收集器，对服务URL粒度的日志请求信息和响应信息进行拦截。

指标监控：网关可以统计后端服务的请求次数，并且可以实时地更新当前的流量健康状态，可以对URL粒度的服务进行延迟统计，也可以使用Hystrix Dashboard查看后端服务的流量状态及是否有熔断发生。

协议转换：API网关的一大作用在于构建异构系统，API网关作为单一入口，通过协议转换整合后台基于REST、AMQP、Dubbo等不同风格和实现技术的微服务，面向Web Mobile、开放平台等特定客户端提供统一服务。

黑白名单：微服务网关可以使用系统黑名单，过滤HTTP请求特征，拦截异常客户端的请求，例如DDoS攻击等侵蚀带宽或资源迫使服务中断等行为，可以在网关层面进行拦截过滤。比较常见的拦截策略是根据IP地址增加黑名单。在存在鉴权管理的路由服务中可以通过设置白名单跳过鉴权管理而直接访问后端服务资源。

文档中心：网关结合Swagger，可以将后端的微服务暴露给网关，网关作为统一的入口给接口的使用方提供查看后端服务的API规范，不需要知道每一个后端微服务的Swagger地址，这样网关起到了对后端API聚合的效果。

目前主流的网关

Spring Cloud Gateway：是springcloud的全新API网关项目，旨在替换zuul的网关服务，基于spring framework5.0+springboot 2.0+webFlux开发，其也实现了异步非阻塞的特性，有较高的性能，其有丰富的过滤器类型，可以根据自身需求来自定义过滤器。

Zuul 2.0: 采用Netty实现异步非阻塞编程模型，一个CPU一个线程，能够处理所有的请求和响应，请求响应的生命周期通过事件和回调进行处理，减少线程数量，开销较小。相比于zuul 1.0，zuul 2.0实现的异步非阻塞的特性，在性能上有较大提升。

OpenResty: OpenResty基于 Nginx与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。

Kong: 基于OpenResty（Nginx + Lua模块）编写的高可用、易扩展的，性能高效且稳定，支持多个可用插件（限流、鉴权）等，开箱即可用，只支持HTTP协议，且二次开发扩展难，缺乏更易用的管理和配置方式

网关之间的对比如下图：

总结

总体而言，API Gateway 主要用于作为后端的 API 接口代理，提供对外访问不同种类 API 的一个单独入口，并且可以提供独立于后端服务的限流、认证、监控等功能。

在合理的架构设计下，一般都将 API Gateway 和 Load Balancer 配合使用，使用 Load Balancer 作为整个系统的网络出入口，将流量分发到多个 API Gateway 实例，然后每个 API Gateway 实例分别对请求进行路由、认证、鉴权等操作，这样可以使得整个网络更加稳健、可靠、可扩展。

审核编辑：刘清