关于后端:微服务架构必读篇-网关

前言

因为互联网的高速倒退，网络数据申请数激增，使得服务器接受的压力越来越大。在晚期的零碎架构中，为加重单台服务器的压力，通常应用 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 进行二次开发的也是能够的。

网关次要性能

1. 路由性能 ：路由是微服务网关的外围能力。通过路由性能微服务网关能够将申请转发到指标微服务。在微服务架构中，网关能够联合注册核心的动静服务发现，实现对后端服务的发现，调用方只须要晓得网关对外裸露的服务 API 就能够通明地拜访后端微服务。
2. 负载平衡 ：API 网关联合负载平衡技术，利用 Eureka 或者 Consul 等服务发现工具，通过轮询、指定权重、IP 地址哈希等机制实现上游服务的负载平衡。
3. 对立鉴权 ：一般而言，无论对内网还是外网的接口都须要做用户身份认证，而用户认证在一些规模较大的零碎中都会采纳对立的单点登录（Single Sign On）零碎，如果每个微服务都要对接单点登录零碎，那么显然比拟浪费资源且开发效率低。API 网关是对立治理安全性的绝佳场合，能够将认证的局部抽取到网关层，微服务零碎毋庸关注认证的逻辑，只关注本身业务即可。
4. 限流熔断 ：在某些场景下须要管制客户端的拜访次数和拜访频率，一些高并发零碎有时还会无限流的需要。在网关上能够配置一个阈值，当申请数超过阈值时就间接返回谬误而不持续拜访后盾服务。当呈现流量洪峰或者后端服务呈现提早或故障时，网关可能被动进行熔断，爱护后端服务，并放弃前端用户体验良好。
5. 灰度公布 ：微服务网关能够依据 HTTP 申请中的非凡标记和后端服务列表元数据标识进行流量管制，实现在用户无感知的状况下实现灰度公布。
6. 日志审计 ：微服务网关能够作为对立的日志记录和收集器，对服务 URL 粒度的日志申请信息和响应信息进行拦挡。
7. 指标监控 ：网关能够统计后端服务的申请次数，并且能够实时地更新以后的流量衰弱状态，能够对 URL 粒度的服务进行提早统计，也能够应用 Hystrix Dashboard 查看后端服务的流量状态及是否有熔断产生。
8. 协定转换 ：API 网关的一大作用在于构建异构零碎，API 网关作为繁多入口，通过协定转换整合后盾基于 REST、AMQP、Dubbo 等不同格调和实现技术的微服务，面向 Web Mobile、开放平台等特定客户端提供对立服务。
9. 黑白名单 ：微服务网关能够应用零碎黑名单，过滤 HTTP 申请特色，拦挡异样客户端的申请，例如 DDoS 攻打等侵蚀带宽或资源迫使服务中断等行为，能够在网关层面进行拦挡过滤。比拟常见的拦挡策略是依据 IP 地址减少黑名单。在存在鉴权治理的路由服务中能够通过设置白名单跳过鉴权治理而间接拜访后端服务资源。
10. 文档核心 ：网关联合 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 实例别离对申请进行路由、认证、鉴权等操作，这样能够使得整个网络更加持重、牢靠、可扩大。

本文由 mdnice 多平台公布