基于API服务网关技术的水文数据共享系统的构建

程庆华

（河南省水文水资源局）

1 引言

随着信息化技术的不断推进，水文数据也由以纸质年鉴转化为以国标数据库为主要成果形式。形式的改变，也促进了水文数据的广泛应用。面对各行各业对日益增涨的各种水文数据需求，亟待建立一套完善的水文数据共享系统，有序、安全和高可靠性的解决水文数据共享使用问题。文章采用基于API 网关技术，通过JWT 认证，建立安全高效的水文数据共性系统。

2 问题的提出

在面对各种水文数据使用需求时，采用完全开放的数据形式是不安全的，也是低效的，更遑论开放纸质年鉴查询形式，非常不利于水文数据使用，发挥其重要的国民经济建设作用。因此，要建立水文数据共性系统必须至少满足以下三个条件：一是个性化使用。按照使用者的需求，在水文数据安全范围内按需使用水文数据；二是身份认证。根据不同的使用者，提供不同级别和深度的水文数据，需要由一个完善的身份认证体系；三是满足海量数据需求。水文数据的使用涉及各行各业，任意时刻，因此需要建立一套满足分布式各类用户的数据需求。

3 解决思路

基于API 服务网关的水文数据共享系统就是把各种水文数据需求，按照API 服务模式，以JOSN 提供给数据获取者。API 服务网关通过分布式服务，提供跨域数据安全访问，利用JWT 认证技术提供身份认证，按需给各个数据获取者提供数据服务。构建的模型如图1。

3.1 API服务网关

API服务网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。API 网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP 的访问API。服务端通过API-GW注册和管理服务。

图1 模型图

3.1.1 API服务网关的组成

API 服务网关包括三大部分：API 网关、网关控制台、度量数据采集分析。实际形态各异，可以按需搭建，但肯定少不了API 网关，网关控制台的功能职责可能会放到服务注册等地方而没有单独抽取出来，至于度量数据采集可能会在整个微服务架构中存一个通用的度量数据采集应用以监控所有类型应用。

对于大多数应用程序而言，API 网关的性能和可扩展性通常都非常重要。因此，API 网关将构建在一个支持异步、I/O 非阻塞的平台上。Java 系可以使用一种基于NIO 的框架，比如Netty、Vertx、Spring Reactor ，还可以使用Node.js、NGINX Plus。

3.1.2 API服务网关的优缺点

优点：封装了应用程序的内部结构。客户端只需要同网关交互，而不必调用特定的服务。API 网关为每一类客户端提供了特定的API，从而减少客户端与应用程序间的交互次数，简化客户端代码的处理。

缺点：增加了一个必须开发、部署和维护的高可用组件。还有一个风险是API 网关变成了开发瓶颈。为了暴露每个微服务，开发人员必须更新API 网关。API 网关的更新过程要尽可能地简单，否则为了更新网关，开发人员将不得不排队等待。不过，虽然有这些不足，但对于大多数现实世界的应用程序而言使用API 网关是合理的。

3.2 JWT认证

3.2.1 JWT 的原理

JWT 有三部分组成：JWT 头（header）、有效载荷（payload）和签名哈希（signature）。JWT 的原理是，服务器认证以后，生成一个JSON对象，发回给用户，如下JSON对象

{

"姓名":"张三"，

"角色":"管理员"，

"到期时间":"2018年7月1日0点0分"

}

以后，用户与服务端通信的时候，都要发回这个JSON 对象。服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名。

服务器就不保存任何session 数据了，也就是说，服务器变成无状态了，从而比较容易实现扩展。

3.2.1 JWT的流程

分布式服务离不开用户认证。一般流程是下面这样：①用户向服务器发送用户名和密码。②服务器验证通过后，在当前对话（session）里面保存相关数据，比如：用户角色、登录时间等等。③服务器向用户返回一个session_id，写入用户的Cookie。④用户随后的每一次请求，都会通过Cookie，将session_id 传回服务器。⑤服务器收到session_id，找到前期保存的数据，由此得知用户的身份。

这种模式的问题在于，扩展性（scaling）不好。单机当然没有问题，如果是服务器集群，或者是跨域的服务导向架构，就要求session 数据共享，每台服务器都能够读取session。一种解决方案是session 数据持久化，写入数据库或别的持久层。各种服务收到请求后，都向持久层请求数据。这种方案的优点是架构清晰，缺点是工程量比较大。另外，持久层万一挂了，就会单点失败。另一种方案是服务器索性不保存session 数据了，所有数据都保存在客户端，每次请求都发回服务器。JWT 就是这种方案的一个代表。认证流程如图2。

3.2.3 JWT的优缺点

①JWT 默认不加密，但可以加密。生成原始令牌后，可以使用改令牌再次对其进行加密。②当JWT未加密方法使一些私密数据无法通过JWT 传输。③JWT 不仅可用于认证，还可用于信息交换。善用JWT有助于减少服务器请求数据库的次数。④JWT 的最大缺点是服务器不保存会话状态，所以在使用期间不可能取消令牌或更改令牌的权限。也就是说，一旦JWT 签发，在有效期内将会一直有效。⑤JWT 本身包含认证信息，因此一旦信息泄露，任何人都可以获得令牌的所有权限。为了减少盗用，JWT 的有效期不宜设置太长。对于某些重要操作，用户在使用时应该每次都进行身份验证。⑥为了减少盗用和窃取，JWT 不建议使用HTTP 协议来传输代码，而是使用加密的HTTPS协议进行传输。

图2 认证流程如图

4 水文数据共享系统的构建

4.1 搭建API服务网关

Spring Cloud Gateway 是Spring Cloud 的一个全新项目，该项目是基于Spring 5.0，Spring Boot 2.0 和Project Reactor 等技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的API 路由管理方式。Spring Cloud Gateway 作为Spring Cloud 生态系统中的网关，为了提升网关的性能，Spring Cloud Gateway 是基于Web Flux框架实现的，而Web Flux框架底层则使用了高性能的Reactor 模式通信框架Netty。并且基于Filter链的方式提供了网关基本的功能，例如：安全，监控/指标，和限流。搭建流程如下：一是引入依赖。主要引入Spring Cloud Gateway 相关依赖；在spring-cloud-starter-gateway 依赖中，会引入Web Flux、Reactor、Netty 等等依赖。二是建立配置文件。在配置文件主要添加Spring Cloud Gateway 相关配置；一是设置网关的服务器端口；二是设置路由配置项，对应Route Definition 数组。路由（Route）是Gateway 中最基本的组件之一，由一个ID、URI、一组谓语（Predicate）、过滤器（Filter）组成。一个请求如果满足某个路由的所有谓语，则匹配上该路由。三是创建Gateway Application 类，网关的启动类。

4.2 建立JWT认证服务

首先在Spring Boot 引入依赖，主要引入JWT 依赖；然后编写JWT生成与验证代码，最后封装JWT类。通过POST实现跨域应用，可以满足分布式多种类型用户的请求和响应。

5 结语

基于API 服务网关的水文数据共享系统的建立，高效安全的解决了水文数据多种跨域访问请求，使水文数据不再是“信息孤岛”中的封闭数据，使其服务于各行各业的经济建设。但是在使用过程中，要求API 的封装必须安全可靠，必要时应该经过Postman的测试才可以投入API网关服务中。