API 网关知识看这篇就足够了！

时间 2019-11-10

标签 api 网关知识看这足够繁體版

原文原文链接

本文已经收录自 JavaGuide （60k+ Star【Java学习+面试指南】一份涵盖大部分Java程序员所须要掌握的核心知识。）
本文受权转载自：https://github.com/javagrowing/JGrowing/blob/master/服务端开发/浅析如何设计一个亿级网关.md。html

1.背景

1.1 什么是API网关

API网关能够看作系统与外界联通的入口，咱们能够在网关进行处理一些非业务逻辑的逻辑，好比权限验证，监控，缓存，请求路由等等。java

1.2 为何须要API网关

RPC协议转成HTTP。

因为在内部开发中咱们都是以RPC协议(thrift or dubbo)去作开发，暴露给内部服务，当外部服务须要使用这个接口的时候每每须要将RPC协议转换成HTTP协议。git

请求路由

在咱们的系统中因为同一个接口新老两套系统都在使用，咱们须要根据请求上下文将请求路由到对应的接口。程序员

统一鉴权

对于鉴权操做不涉及到业务逻辑，那么能够在网关层进行处理，不用下层到业务逻辑。github

统一监控

因为网关是外部服务的入口，因此咱们能够在这里监控咱们想要的数据，好比入参出参，链路时间。web

流量控制，熔断降级

对于流量控制，熔断降级非业务逻辑能够统一放到网关层。面试

有不少业务都会本身去实现一层网关层，用来接入本身的服务，可是对于整个公司来讲这还不够。redis

1.3 统一API网关

统一的API网关不只有API网关的全部的特色，还有下面几个好处:spring

统一技术组件升级

在公司中若是有某个技术组件须要升级，那么是须要和每一个业务线沟通，一般几个月都搞不定。举个例子若是对于入口的安全鉴权有重大安全隐患须要升级，若是速度仍是这么慢确定是不行，那么有了统一的网关升级是很快的。数据库

统一服务接入

对于某个服务的接入也比较困难，好比公司已经研发出了比较稳定的服务组件，正在公司大力推广，这个周期确定也特别漫长，因为有了统一网关，那么只须要统一网关统一接入。

节约资源

不一样业务不一样部门若是按照咱们上面的作法应该会都本身搞一个网关层，用来作这个事，能够想象若是一个公司有100个这种业务，每一个业务配备4台机器，那么就须要400台机器。而且每一个业务的开发RD都须要去开发这个网关层，去随时去维护，增长人力。若是有了统一网关层，那么也许只须要50台机器就能够作这100个业务的网关层的事，而且业务RD不须要随时关注开发，上线的步骤。

2.统一网关的设计

2.1 异步化请求

对于咱们本身实现的网关层，因为只有咱们本身使用，对于吞吐量的要求并不高因此，咱们通常同步请求调用便可。

对于咱们统一的网关层，如何用少许的机器接入更多的服务，这就须要咱们的异步，用来提升更多的吞吐量。对于异步化通常有下面两种策略：

Tomcat/Jetty+NIO+servlet3

这种策略使用的比较广泛，京东，有赞，Zuul，都选取的是这个策略，这种策略比较适合HTTP。在Servlet3中能够开启异步。

Netty+NIO

Netty为高并发而生，目前惟品会的网关使用这个策略，在惟品会的技术文章中在相同的状况下Netty是每秒30w+的吞吐量，Tomcat是13w+,能够看出是有必定的差距的，可是Netty须要本身处理HTTP协议，这一块比较麻烦。

对于网关是HTTP请求场景比较多的状况能够采用Servlet，毕竟有更加成熟的处理HTTP协议。若是更加剧视吞吐量那么能够采用Netty。

2.1.1 全链路异步

对于来的请求咱们已经使用异步了，为了达到全链路异步因此咱们须要对去的请求也进行异步处理，对于去的请求咱们能够利用咱们rpc的异步支持进行异步请求因此基本能够达到下图:

由在web容器中开启servlet异步，而后进入到网关的业务线程池中进行业务处理，而后进行rpc的异步调用并注册须要回调的业务，最后在回调线程池中进行回调处理。

2.2 链式处理

在设计模式中有一个模式叫责任链模式，他的做用是避免请求发送者与接收者耦合在一块儿，让多个对象都有可能接收请求，将这些对象链接成一条链，而且沿着这条链传递请求，直到有对象处理它为止。经过这种模式将请求的发送者和请求的处理者解耦了。在咱们的各个框架中对此模式都有实现，好比servlet里面的filter，springmvc里面的Interceptor。

在Netflix Zuul中也应用了这种模式，以下图所示:

这种模式在网关的设计中咱们能够借鉴到本身的网关设计:

preFilters：前置过滤器，用来处理一些公共的业务，好比统一鉴权，统一限流，熔断降级，缓存处理等，而且提供业务方扩展。
routingFilters: 用来处理一些泛化调用，主要是作协议的转换，请求的路由工做。
postFilters: 后置过滤器，主要用来作结果的处理，日志打点，记录时间等等。
errorFilters: 错误过滤器，用来处理调用异常的状况。

这种设计在有赞的网关也有应用。

2.3 业务隔离

上面在全链路异步的状况下不一样业务之间的影响很小，可是若是在提供的自定义FiIlter中进行了某些同步调用，一旦超时频繁那么就会对其余业务产生影响。因此咱们须要采用隔离之术，下降业务之间的互相影响。

2.3.1 信号量隔离

信号量隔离只是限制了总的并发数，服务仍是主线程进行同步调用。这个隔离若是远程调用超时依然会影响主线程，从而会影响其余业务。所以，若是只是想限制某个服务的总并发调用量或者调用的服务不涉及远程调用的话，可使用轻量级的信号量来实现。有赞的网关因为没有自定义filter因此选取的是信号量隔离。

2.3.2 线程池隔离

最简单的就是不一样业务之间经过不一样的线程池进行隔离，就算业务接口出现了问题因为线程池已经进行了隔离那么也不会影响其余业务。在京东的网关实现之中就是采用的线程池隔离，比较重要的业务好比商品或者订单都是单独的经过线程池去处理。可是因为是统一网关平台，若是业务线众多，你们都以为本身的业务比较重要须要单独的线程池隔离，若是使用的是Java语言开发的话那么，在Java中线程是比较重的资源比较受限，若是须要隔离的线程池过多不是很适用。若是使用一些其余语言好比Golang进行开发网关的话，线程是比较轻的资源，因此比较适合使用线程池隔离。

2.3.3 集群隔离

若是有某些业务就须要使用隔离可是统一网关又没有线程池隔离那么应该怎么办呢？那么可使用集群隔离，若是你的某些业务真的很重要那么能够为这一系列业务单独申请一个集群或者多个集群，经过机器之间进行隔离。

2.4 请求限流

流量控制能够采用不少开源的实现，好比阿里最近开源的Sentinel和比较成熟的Hystrix。

通常限流分为集群限流和单机限流:

利用统一存储保存当前流量的状况，通常能够采用Redis，这个通常会有一些性能损耗。
单机限流:限流每台机器咱们能够直接利用Guava的令牌桶去作，因为没有远程调用性能消耗较小。

2.5 熔断降级

这一块也能够参照开源的实现Sentinel和Hystrix，这里不是重点就很少提了。

2.6 泛化调用

泛化调用指的是一些通讯协议的转换，好比将HTTP转换成Thrift。在一些开源的网关中好比Zuul是没有实现的，由于各个公司的内部服务通讯协议都不一样。好比在惟品会中支持HTTP1,HTTP2,以及二进制的协议，而后转化成内部的协议，淘宝的支持HTTPS,HTTP1,HTTP2这些协议均可以转换成，HTTP,HSF,Dubbo等协议。

2.6.1泛化调用

如何去实现泛化调用呢？因为协议很难自动转换，那么其实每一个协议对应的接口须要提供一种映射。简单来讲就是把两个协议都能转换成共同语言，从而互相转换。

通常来讲共同语言有三种方式指定:

json：json数据格式比较简单,解析速度快，较轻量级。在Dubbo的生态中有一个HTTP转Dubbo的项目是用JsonRpc作的，将HTTP转化成JsonRpc再转化成Dubbo。

好比能够将一个 www.baidu.com/id = 1 GET 能够映射为json：

代码块

xml:xml数据比较重，解析比较困难，这里不过多讨论。
自定义描述语言:通常来讲这个成本比较高须要本身定义语言来进行描述并进行解析，可是其扩展性，自定义个性化性都是最高。例:spring自定义了一套本身的SPEL表达式语言

对于泛化调用若是要本身设计的话JSON基本能够知足，若是对于个性化的须要特别多的话却是能够本身定义一套语言。

2.7 管理平台

上面介绍的都是如何实现一个网关的技术关键。这里须要介绍网关的一个业务关键。有了网关以后，须要一个管理平台如何去对咱们上面所描述的技术关键进行配置,包括但不限于下面这些配置:

限流
熔断
缓存
日志
自定义filter
泛化调用

3.总结

最后一个合理的标准网关应该按照以下去实现:

---	京东	惟品会	有赞	阿里	Zuul
实现关键	servlet3.0	netty	servlet3.0	servlet3.0	servlet3.0
异步状况	servlet异步，rpc是否异步不清楚	全链路异步	全链路异步	全链路异步	Zuul1同步阻塞,Zuul2异步非阻塞
限流	---	---	平滑限流。最初是codis，后续换到每一个单机的令牌桶限流。	1.基本流控:基于API的QPS作限流。2.运营流控:支持APP流量包，APP+API+USER的流控33.大促流控:APP访问API的权重流控。阿里开源:Sentinel	提供了jar包:spring-cloud-zuul-ratelimit。1.对请求的目标URL进行限流（例如：某个URL每分钟只容许调用多少次)。2.对客户端的访问IP进行限流（例如：某个IP每分钟只容许请求多少次）3.对某些特定用户或者用户组进行限流（例如：非VIP用户限制每分钟只容许调用100次某个API等）4.多维度混合的限流。此时，就须要实现一些限流规则的编排机制。与、或、非等关系。支持四种存储方式ConcurrentHashMap,Consul,Redis,数据库。
熔断降级	---	---	Hystrix	---	只支持服务级别熔断，不支持URL级别。
隔离	线程池隔离	---	信号量隔离	---	线程池隔离，信号量隔离
缓存	redis	---	二级缓存，本地缓存+Codis	HDCC 本地缓存，远程缓存，数据库	须要本身开发
泛化调用	---	http,https,http1,http2,二进制	dubbo,http,nova	hsf,dubbo,http,https,http2,http1	只支持http

4.参考

开源项目推荐

做者的其余开源项目推荐：

JavaGuide：【Java学习+面试指南】一份涵盖大部分Java程序员所须要掌握的核心知识。
springboot-guide : 适合新手入门以及有经验的开发人员查阅的 Spring Boot 教程（业余时间维护中，欢迎一块儿维护）。
programmer-advancement : 我以为技术人员应该有的一些好习惯！
spring-security-jwt-guide :从零入门！Spring Security With JWT（含权限验证）后端部分代码。