企业API 网关

时间  2019-11-17
标签 企业 api 网关 繁體版
原文   原文链接

网关一词较早出如今网络设备里面，好比两个相互独立的局域网段之间经过路由器或者桥接设备进行通讯， 这中间的路由或者桥接设备咱们称之为网关。前端

相应的API网关将各系统对外暴露的服务聚合起来，全部要调用这些服务的系统都须要经过API网关进行访问，基于这种方式网关能够对API进行统一管控，例如：认证、鉴权、流量控制、协议转换、监控等等。数据库

API网关的流行得益于近几年微服务架构的兴起，本来一个庞大的业务系统被拆分红许多粒度更小的系统进行独立部署和维护，这种模式势必会带来更多的跨系统交互，企业API的规模也会成倍增长，API网关（或者微服务网关）就逐渐成为了微服务架构的标配组件。编程

以下是咱们整理的API网关的几种典型应用场景：后端

 

一、面向Web或者移动App缓存

这类场景，在物理形态上相似先后端分离，前端应用经过API调用后端服务，须要网关具备认证、鉴权、缓存、服务编排、监控告警等功能。安全

二、面向合做伙伴开放API微信

这类场景，主要为了知足业务形态对外开放，与企业外部合做伙伴创建生态圈，此时的API 网关注重安全认证、权限分级、流量管控、缓存等功能的建设。网络

三、企业内部系统互联互通session

对于中大型的企业内部每每有几10、甚至上百个系统，尤为是微服务架构的兴起系统数量更是急剧增长。系统之间相互依赖，逐渐造成网状调用关系不便于管理和维护，须要API网关进行统一的认证、鉴权、流量管控、超时熔断、监控告警管理，从而提升系统的稳定性、下降重复建设、运维管理等成本。架构

设计目标

  1. 纯Java实现；

  2. 支持插件化，方便开发人员自定义组件；

  3. 支持横向扩展，高性能；

  4. 避免单点故障，稳定性要高，不能由于某个API故障致使整个网关中止服务；

  5. 管理控制台配置更新可自动生效，不须要重启网关；

应用架构设计

说明：

一、网关核心子系统经过HAProxy或者Nginx进行负载均衡，为避免正好路由的LB节点服务不可用，能够考虑在此基础上增长Keepalived来实现LB的失效备援，当LB Node1中止服务，Keepalived会将虚拟IP自动飘移到LB Node2，从而避免由于负载均衡器致使单点故障。DNS能够直接指向Keepalived的虚拟IP。

二、网关除了对性能要求很高外，对稳定性也有很高的要求，引入Zookeeper及时将Admin对API的配置更改同步刷新到各网关节点。

三、管理中心和监控中心能够采用相似网关子系统的高可用策略，若是嫌麻烦管理中心能够省去Keepalived，相对来讲管理中心没有这么高的可用性要求。

四、理论上监控中心须要承载很大的数据量，好比有1000个API，平均每一个API一天调用10万次，对于不少互联网公司单个API的量远远大于10万，若是将每次调用的信息都存储起来太浪费，也没有太大的必要。能够考虑将API每分钟的调用状况汇总后进行存储，好比1分钟的平均响应时间、调用次数、流量、正确率等等。

五、数据库选型能够灵活考虑，原则上网关在运行时要尽量减小对DB的依赖，不然IO延时会严重影响网关性能。能够考虑首次访问后将API配置信息缓存，Admin对API配置更改后经过Zookeeper通知网关刷新，这样一来DB的访问量能够忽略不计，团队可根据自身偏好灵活选型。

非阻塞式HTTP服务

管理和监控中心能够根据团队的状况采用本身熟悉的Servlet容器部署，网关核心子系统对性能的要求很是高，考虑采用NIO的网络模型，实现纯HTTP服务便可，不须要实现Servlet容器，推荐Netty框架（设计优雅，大名鼎鼎的Spring Webflux默认都是使用的Netty，更多的优点就不在此详述了），内部测试在相同的机器上分别经过Tomcat和Netty生成UUID，Netty的性能大约有20%的提高，若是后端服务响应耗时较高的话吞吐量还有更大的提高。（补充：Netty4.x的版本便可，不要采用5以上的版本，有严重的缺陷没有解决）

采用Netty做为Http容器首先须要解决的是Http协议的解析和封装，好在Netty自己提供了这样的Handler，具体参考以下代码：

一、构建一个单例的HttpServer，在SpringBoot启动的时候同时加载并启动Netty服务

 

  1. int sobacklog = Integer.parseInt(AppConfigUtil.getValue("netty.sobacklog"));

  2. ServerBootstrap b = new ServerBootstrap();

  3. b.group(bossGroup, workerGroup)

  4.    .channel(NioServerSocketChannel.class)

  5.    .localAddress(new InetSocketAddress(this.portHTTP))

  6.    .option(ChannelOption.SO\_BACKLOG, sobacklog)

  7.    .childHandler(new ChannelHandlerInitializer(null));

  8.  

  9.    // 绑定端口

  10.    ChannelFuture f = b.bind(this.portHTTP).sync();

  11.    logger.info("HttpServer name is " + HttpServer.class.getName() + " started and listen on " + f.channel().localAddress());

二、初始化Handler

 

  1. @Override

  2. protected void initChannel(SocketChannel ch) throws Exception {

  3.    ChannelPipeline p = ch.pipeline();

  4.    p.addLast(new HttpRequestDecoder());

  5.    p.addLast(new HttpResponseEncoder());

  6.    int maxContentLength = 2000;

  7.    try {

  8.        maxContentLength = Integer.parseInt(AppConfigUtil.getValue("netty.maxContentLength"));

  9.    } catch (Exception e) {

  10.        logger.warn("netty.maxContentLength配置异常，系统默认为：2000KB");

  11. }

  12.    p.addLast(new HttpObjectAggregator(maxContentLength * 1024));// HTTP 消息的合并处理

  13.    p.addLast(new HttpServerInboundHandler());

  14.  

  15. }

HttpRequestDecoder和HttpResponseEncoder分别实现Http协议的解析和封装，Http Post内容超过一个数据包大小会自动分组，经过HttpObjectAggregator能够自动将这些数据粘合在一块儿，对于上层收到是一个完整的Http请求。

三、经过HttpServerInboundHandler将网络请求转发给网关执行器

 

  1. @Override

  2. public void channelRead0(ChannelHandlerContext ctx, Object msg) throws Exception {

  3.    try {

  4.        if (msg instanceof HttpRequest && msg instanceof HttpContent) {

  5.            CmptRequest cmptRequest = CmptRequestUtil.convert(ctx, msg);

  6.            CmptResult cmptResult = this.gatewayExecutor.execute(cmptRequest);

  7.            FullHttpResponse response = encapsulateResponse(cmptResult);

  8.            ctx.write(response);

  9.            ctx.flush();

  10.        }

  11.    } catch (Exception e) {

  12.        logger.error("网关入口异常，" + e.getMessage());

  13.        e.printStackTrace();

  14.    }

  15.  

  16. }

设计上建议将Netty接入层代码跟网关核心逻辑代码分离，不要将Netty收到HttpRequest和HttpContent直接给到网关执行器，能够考虑作一层转换封装成本身的Request给到执行器，方便后续能够很容易的将Netty替换成其它Http容器。（如上代码所示，CmptRequest即为自定义的Http请求封装类，CmptResult为网关执行结果类）

组件化及自定义组件支持

组件是网关的核心，大部分功能特性均可以基于组件的形式提供，组件化能够有效提升网关的扩展性。

先来看一个简单的微信认证组件的例子：

以下实现的功能是对API请求传入的Token进行校验，其结果分别是认证经过、Token过时和无效Token，认证经过后再将微信OpenID携带给上游服务系统。

 

  1. /**

  2. * 微信token认证，token格式：

  3. * {appID:'',openID:'',timestamp:132525144172,sessionKey: ''}

  4. */

  5. public class WeixinAuthTokenCmpt extends AbstractCmpt {

  6.    private static Logger logger = LoggerFactory.getLogger(WeixinAuthTokenCmpt.class);

  7.    private final CmptResult SUCCESS_RESULT;

  8.  

  9.    public WeixinAuthTokenCmpt() {

  10.        SUCCESS_RESULT = buildSuccessResult();

  11.    }

  12.  

  13.    @Override

  14.    public CmptResult execute(CmptRequest request, Map<String, FieldDTO> config) {

  15.        if (logger.isDebugEnabled()) {

  16.            logger.debug("WeixinTokenCmpt ......");

  17.        }

  18.        CmptResult cmptResult = null;

  19.  

  20.        //Token认证超时间(传入单位:分)

  21.        long authTokenExpireTime = getAuthTokenExpireTime(config);

  22.        WeixinTokenDTO authTokenDTO = this.getAuthTokenDTO(request);

  23.        logger.debug("Token=" + authTokenDTO);

  24.        AuthTokenState authTokenState = validateToken(authTokenDTO, authTokenExpireTime);

  25.        switch (authTokenState) {

  26.            case ACCESS: {

  27.                cmptResult = SUCCESS_RESULT;

  28.                Map<String, String> header = new HashMap<>();

  29.                header.put(HeaderKeyConstants.HEADER_APP_ID_KEY, authTokenDTO.getAppID());

  30.                header.put(CmptHeaderKeyConstants.HEADER_WEIXIN_OPENID_KEY, authTokenDTO.getOpenID());

  31.                header.put(CmptHeaderKeyConstants.HEADER_WEIXIN_SESSION_KEY, authTokenDTO.getSessionKey());

  32.                cmptResult.setHeader(header);

  33.                break;

  34.            }

  35.            case EXPIRED: {

  36.                cmptResult = buildCmptResult(RespErrCode.AUTH_TOKEN_EXPIRED, "token过时,请从新获取Token！");

  37.                break;

  38.            }

  39.            case INVALID: {

  40.                cmptResult = buildCmptResult(RespErrCode.AUTH_INVALID_TOKEN, "Token无效！");

  41.                break;

  42.            }

  43.        }

  44.        return cmptResult;

  45.    }

  46. ...

  47. }

上面例子看不懂不要紧，接下来会详细阐述组件的设计思路。

一、组件接口定义

 

  1. public interface ICmpt {

  2.    /**

  3.     * 组件执行入口

  4.     *

  5.     * @param request

  6.     * @param config，组件实例的参数配置

  7.     * @return

  8.     */

  9.    CmptResult execute(CmptRequest request, Map<String, FieldDTO> config);

  10.  

  11.    /**

  12.     * 销毁组件持有的特殊资源，好比线程。

  13.     */

  14.    void destroy();

  15. }

execute是组件执行的入口方法，request前面提到过是http请求的封装，config是组件的特殊配置，好比上面例子提到的微信认证组件就有一个自定义配置-Token的有效期，不一样的API使用该组件能够设置不一样的有效期。

FieldDTO定义以下：

 

  1. public class FieldDTO {

  2.  

  3.    private String title;

  4.  

  5.    private String name;

  6.  

  7.    private FieldType fieldType = FieldType.STRING;

  8.  

  9.    private String defaultValue;

  10.  

  11.    private boolean required;

  12.  

  13.    private String regExp;

  14.  

  15.    private String description;

  16.  

  17. }

CmptResult为组件执行后的返回结果，其定义以下：

 

  1. public class CmptResult {

  2.  

  3.    RespErrMsg respErrMsg;//组件返回错误信息

  4.  

  5.    private boolean passed;//组件过滤是否经过

  6.  

  7.    private byte[] data;//组件返回数据

  8.  

  9.    private Map<String, String> header = new HashMap<String, String>();//透传后端服务响应头信息

  10.  

  11.    private MediaType mediaType;//返回响应数据类型

  12.  

  13.    private Integer statusCode = 200;//默认返回状态码为200

  14.  

  15. }

二、组件类型定义

执行器须要根据组件类型和组件执行结果判断是要直接返回客户端仍是继续往下面执行，好比认证类型的组件，若是认证失败是不能继续往下执行的，但缓存类型的组件没有命中才继续往下执行。固然这样设计存在一些缺陷，好比新增组件类型须要执行器配合调整处理逻辑。（Kong也提供了大量的功能组件，没有研究过其网关框架是如何跟组件配合的，是否支持用户自定义组件类型，知道的朋友详细交流下。）

初步定义以下组件类型：

认证、鉴权、流量管控、缓存、路由、日志等。

其中路由类型的组件涵盖了协议转换的功能，其负责调用上游系统提供的服务，能够根据上游系统提供API的协议定制不一样的路由组件，好比：Restful、WebService、Dubbo、EJB等等。

三、组件执行位置和优先级设定

执行位置：Pre、Routing、After，分别表明后端服务调用前、后端服务调用中和后端服务调用完成后，相同位置的组件根据优先级决定执行的前后顺序。

四、组件发布形式

组件打包成标准的Jar包，经过Admin管理界面上传发布。

附-组件可视化选择UI设计

组件热插拔设计和实现

JVM中Class是经过类加载器+全限定名来惟一标识的，上面章节谈到组件是以Jar包的形式发布的，但相同组件的多个版本的入口类名须要保持不变，所以要实现组件的热插拔和多版本并存就须要自定义类加载器来实现。

大体思路以下：

网关接收到API调用请求后根据请求参数从缓存里拿到API配置的组件列表，而后再逐一参数从缓存里获取组件对应的类实例，若是找不到则尝试经过自定义类加载器载入Jar包，并初始化组件实例及缓存。

附-参考示例

 

  1. public static ICmpt newInstance(final CmptDef cmptDef) {

  2.    ICmpt cmpt = null;

  3.    try {

  4.        final String jarPath = getJarPath(cmptDef);

  5.        if (logger.isDebugEnabled()) {

  6.            logger.debug("尝试载入jar包,jar包路径: " + jarPath);

  7.        }

  8.        //加载依赖jar

  9.        CmptClassLoader cmptClassLoader = CmptClassLoaderManager.loadJar(jarPath, true);

  10.        // 建立实例

  11.        if (null != cmptClassLoader) {

  12.            cmpt = LoadClassUtil.newObject(cmptDef.getFullQualifiedName(), ICmpt.class, cmptClassLoader);

  13.        } else {

  14.            logger.error("加载组件jar包失败! jarPath: " + jarPath);

  15.        }

  16.    } catch (Exception e) {

  17.        logger.error("组件类加载失败，请检查类名和版本是否正确。ClassName=" + cmptDef.getFullQualifiedName() + ", Version=" + cmptDef.getVersion());

  18.        e.printStackTrace();

  19.    }

  20.    return cmpt;

  21. }

补充说明：

自定义类加载器可直接须要继承至URLClassLoader，另外必须指定其父类加载器为执行器的加载器，不然组件无法引用网关的其它类。

API故障隔离及超时、熔断处理

在详细阐述设计前先讲个实际的案例，大概12年的时候某公司自研了一款ESB的中间件（企业服务总线跟API网关很相似，当年SOA理念大行其道的时候都推崇的是ESB，侧重服务的编排和异构系统的整合。），刚开始用的还行，但随着接入系统的增多，忽然某天运维发现大量API出现缓慢甚至超时，初步检查发现ESB每一个节点的线程几乎消耗殆尽，起初判断是资源不够，紧急扩容后仍是很快线程占满，最终致使上百个系统瘫痪。

最终找到问题的症结是某个业务系统自身的缘由致使服务不可用，下游业务系统请求大量堆积到ESB中，从而致使大量线程堵塞。

以上案例说明了一个在企业应用架构设计里面的经典原则-故障隔离，因为全部的API请求都要通过网关，必须隔离API之间的相互影响，尤为是个别API故障致使整个网关集群服务中断。

接下来分别介绍故障隔离、超时管控、熔断的实现思路。

一、故障隔离

有两种方式能够实现，一是为每一个API建立一个线程池，每一个线程分配10~20个线程，这也是经常使用的隔离策略，但这种方式有几个明显的缺点：

1）线程数会随着API接入数量递增，1000个API就须要2万个线程，光线程切换对CPU就是不小的开销，而其线程还须要占用必定的内存资源；

2）平均分配线程池大小致使个别访问量较大且响应时间相对较长的API吞吐量上不去；

3）Netty自己就有工做线程池了，再增长API的线程池，致使某些须要ThreadLocal特性的编程变得困难。

二是用信号量隔离，直接复用Netty的工做线程，上面线程池隔离提到的3个缺点均可以基本避免， 建议设置单个API的信号量个数小于等于Netty工做线程池数量的1/3，这样既兼顾了单个API的性能又不至于单个API的问题致使整个网关堵塞。

具体实现能够考虑直接引用成熟的开源框架，推荐Hystrix，能够同时解决超时控制和熔断。

参考配置以下：

 

  1. Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey(groupKey))

  2.    .andCommandKey(HystrixCommandKey.Factory.asKey(commandKey ))

  3.    .andCommandPropertiesDefaults(HystrixCommandProperties.Setter() // 舱壁隔离策略-信号量

  4.       .withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.SEMAPHORE) //设置每组command能够申请的信号量最大数         .withExecutionIsolationSemaphoreMaxConcurrentRequests(CmptInvoker.maxSemaphore)

  5. /*开启超时设置*/

  6. .withExecutionIsolationThreadInterruptOnTimeout(true)

  7. /*超时时间设置*/

  8. .withExecutionIsolationThreadTimeoutInMilliseconds(timeout)

  9. .withCircuitBreakerEnabled(true)//开启熔断

  10. .withCircuitBreakerSleepWindowInMilliseconds(Constants.DEFAULT_CIRCUIT_BREAKER_SLEEP_WINDOW_IN_MILLISECONDS)// 5秒后会尝试闭合回路

二、超时管控

API的超时控制是必需要作的，不然上游服务即使是间歇性响应缓慢也会堵塞大量线程（虽然经过信号量隔离后不会致使整个网关线程堵塞）。

其次，每一个API最好能够单独配置超时时间，但不建议可让用户随意设置，仍是要有个最大阈值。（API网关不适合须要长时间传输数据的场景，好比大文件上传或者下载、DB数据同步等）

实现上能够直接复用开源组件的功能，好比：HttpClient能够直接设置获取链接和Socket响应的超时时间，Hystrix能够对整个调用进行超时控制等。

三、熔断

熔断相似电路中的保险丝，当超过负荷或者电阻被击穿的时候自动断开对设备起到保护做用。在API网关中设置熔断的目的是快速响应请求，避免没必要要的等待，好比某个API后端服务正常状况下1s之内响应，但如今由于各类缘由出现堵塞大部分请求20s才能响应，虽然设置了10s的超时控制，但让请求线程等待10s超时不只没有意义，反而会增长服务提供方的负担。

为此咱们能够设置单位时间内超过多少比例的请求超时或者异常，则直接熔断链路，等待一段时间后再次尝试恢复链路。

实现层面能够直接复用Hystrix。

运行时配置更新机制

前面章节提到过出于性能考虑网关在运行时要尽量减少对DB的访问，设计上能够将API、组件等关键内容进行缓存，这样一来性能是提高了，但也带来了新的问题，好比Admin对API或者组件进行配置调整后如何及时更新到集群的各个网关节点。

解决方案不少，好比引入消息中间件，当Admin调整配置后就往消息中心发布一条消息，各网关节点订阅消息，收到消息后刷新缓存数据。

咱们在具体实现过程当中采用的是Zookeeper集群数据同步机制，其实现原理跟消息中间件很相似，只不过网关在启动的时候就会向ZK节点进行注册，也是被动更新机制。

性能考虑

性能是网关一项很是重要的衡量指标，尤为是响应时间，客户端原本能够直连服务端的，如今增长了一个网关层，对于一个自己耗时几百毫秒的服务接入网关后增长几毫秒，影响却是能够忽略不计；但若是服务自己只须要几毫秒，由于接入网关再增长一倍的延时，用户感觉就会比较明显。

建议在设计上须要遵循以下原则：

一、核心网关子系统必须是无状态的，便于横向扩展。

二、运行时不依赖本地存储，尽可能在内存里面完成服务的处理和中转。

三、减少对线程的依赖，采用非阻塞式IO和异步事件响应机制。

四、后端服务若是是HTTP协议，尽可能采用链接池或者Http2，测试链接复用和不复用性能有几倍的差距。（TCP创建链接成本很高）

附-HttpClient链接池设置

 

  1. PoolingHttpClientConnectionManager cmOfHttp = new

  2. PoolingHttpClientConnectionManager();

  3. cmOfHttp.setMaxTotal(maxConn);

  4. cmOfHttp.setDefaultMaxPerRoute(maxPerRoute);

  5. httpClient = HttpClients.custom()

  6.        .setConnectionManager(cmOfHttp)

  7.        .setConnectionManagerShared(true)

  8.        .build();

说明：httpClient对象能够做为类的成员变量长期驻留内存，这个是链接池复用的前提。

结语

API网关做为企业API服务的汇聚中心，其良好的性能、稳定性和可扩展性是基础，只有这个基础打扎实了，咱们才能在上面扩展更多的特性。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程